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
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:
or now on iTunes!
- Windows Media Podcast - 33.4MB WMV
- iPod Video Podcast - 25MB MP4
- MP3 Audio Podcast - 5.0MB
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.
