SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Building an API

By Steve Jones,

I was reading recently about the new FogBugz 7.0 at Joel On Software, and thought it was great that Fog Creek is sharing the internal thoughts  and documents that helped them develop the new version of their software. I think that this is one of those insights into a successful software company that could be adopted by other companies. I wish there were more details and specifics about why features or changes were included or left out so that others could get a better idea of how to apply this to their own process, but I understand that they might not want to provide that level of detail. I do appreciate the disclosure they have provided.

In reading through this, there was one very interesting part of their document. In the "customization" section they talk about building an API to allow plug-ins to work with their product. They say that it's better than having the source code, which is something I completely agree with.

I've purchased source code before, and in fact SQLServerCentral has the source code to our forum software, but that isn't a great solution. As the vendor makes changes, and adds things like Twitter accounts, it's hard for us to apply those changes to our site because we've touched the code in places for enhancements. So simple service packs become major coding projects to "re-apply" all our changes to the new version of their software, test it, re-factor things that don't work the same, and more.

An API is a much better abstraction layer, and it's one that I've tried to apply as a DBA as well. If a software developer takes my tables, my views, and then starts to embed queries in an application, he's not using my API. He's digging into the source of the database and cannot easily handle future enhancements, like schema changes.

If the developer uses a stored procedure API, then as long as I continue to support that API, I can easily make changes without disrupting the application. These can be schema changes to meet new requirements or tuning efforts to speed up response time. Or even distribution changes to handle scale. And most of the time they're things that can make the developer look better down the road, not worse.

I like the idea of building more modular software, where things can plug in to each other, being coupled, but loosely. I think it makes for better, more stable, easier to maintain software.

Steve Jones

The Voice of the DBA Podcasts

Everyday Jones

The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

You can also follow Steve Jones on Twitter:

Overall RSS Feed: or now on iTunes!

Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.

Total article views: 212 | Views in the last 30 days: 2
Related Articles

Building Better Software

Why is it so hard to build better software? Steve Jones looks at recent problem in iOS that seems si...


Rogue Software Changes

Today Steve Jones wonders if software developers would make changes to software on their own, withou...


Building Better Software

Steve Jones discusses the idea of building software better, and why that's a challenge for many of u...



A new video setup is on the way!!!! Actually I'll do a couple podcasts on podcasting over the hol...


Grown Up Software

We all want to write better software, but do we really want to write grown up software? Steve Jones ...