Incorporate eXtreme programming techniques in SQL Server development

by Arthur Fuller | Oct 09, 2006 7:00:00 AM

Tags: Databases, technique, Arthur Fuller, Microsoft Windows XP, Extreme Programming, Microsoft SQL Server, database, SQL Server Newsletter

Takeaway: Arthur Fuller does not understand why the eXtreme programming (XP) method has not penetrated the database layer of development. Find out why he urges SQL Server developers to try the XP approach.

The central premise underlying eXtreme Programming (XP) is that two minds are better than one. Two programmers sit side-by-side, one coding and the other critiquing, block-by-block and line-by-line. The person at the keyboard is, for obvious reasons, the driver; the adjacent person is the navigator. Neither is the boss—they are equals, with complementary roles. The shocking thing about XP is that the technique actually works.

XP has caught on in front-end development circles because it pays off. It might seem ridiculous to put two expensive developers at one machine, but it turns out that is not so. With XP, most bugs are killed even before they are born; optimizations are spotted as the slow code is written; knowledge is exchanged; and team relationships are born.

In my experience, this phenomenon has not penetrated the database layer of development. I see teams where one person writes the sprocs, another writes the DTS, a third does the architecture, and a fourth documents the middleware interfaces. Each person creates the required objects in isolation, and there is almost no code review. The architect may dictate that Sproc98765 accepts specific parameters and returns a certain result; the other team members then fall into line. In any serious development organization, code review and refactoring are essential parts of a project, but for some strange reason, this doesn't extend to the database.

I don't understand. Perhaps we have collectively hoodwinked the managers into thinking that we have all the answers about databases. Or maybe we price our services so high that the accountants gasp at the costs per week of refactoring and XP.

For instance, in a database comprising 400 tables and 1,600 stored procedures, what are the odds that I'm going to get everything right? Even if that happens on occasion, the next time a department or client demands a new column in a table, I have to revisit numerous procedures and UDFs and views—and that only accounts for changes to table structures.

If at all possible, I encourage you to try the XP approach on a problem you're currently facing with SQL Server. Good candidates for this approach are new development of a complex stored procedure, refactoring a slow procedure, and optimizing a view. Give it a try at least once, and let me know how it works for you.

Additional resources on XP

• Extreme Web resources for the Extreme programmer
• Pick up the pace with extreme programming
• Extreme Programming: Do these 12 practices make perfect?
• A development shop turns to XP to take on the cost of change
• XP success story: CodeFab develops for Noggin
• CIO says XP revolutionized more than the development process
• Maybe XP will work in your shop

Miss a tip?

Check out the SQL Server archive, and catch up on the most recent editions of Arthur Fuller's column.

Print/View all Posts Comments on this article

Misleading JimmyF | 10/10/06

Where the heck is he working? Tony Hopkinson | 10/10/06

Interesting... chapman.tim@... | 10/10/06

Yes, it works! kadsoft | 10/10/06

Transitioning to XP Is Difficult Wayne M. | 10/11/06

Triggers aren't code? chapman.tim@... | 10/11/06

Sorry, Failed Attempt at Humor Wayne M. | 10/12/06

It Can Work duffersingh2000@... | 10/12/06

Why do people keep talking as though DBA is a one man job ? Tony Hopkinson | 10/12/06