How would you modify the "Joel Test" to apply to a database development team? Does it need significant changes for database development or is it satisfactory as is?
asked
Modifying the Joel Test to measure a database development team
Some of that is a bit too specific to programming to be applicable to databases. But overall, I'd say it's reasonably close to a good set of questions. I think source control and automated builds are two of the biggest things missed in database development. I think the hallway usability test would be a waste of time on a database.
The one thing I'd add, and I'm not sure how to boil it down to just a few words, but you need to do load testing as a part of development. Unit testing, running all your queries with one row of data, is all well & good, but way too many shortcomings in the code and the structure are brought to light when you have thousands & millions of rows and 5, 10, 20 simultaneous connections.
Other than that, yeah, I think this is applicable.
I think there are a fair few things missing from that actually.
Team unity is important - there's no point having a team of database developers who aren't all pulling in the same direction. It's measurable in terms of the database design through things like having commonality in naming conventions, sensible distribution of data through filegroups and partitions, sensible distribution of objects through schemas etc.
Another thing that I think is critical is 'does the team take an hour each week to keep up with the state of the art'? Discovering new and more efficient ways of achieving the same task can be a really important part of any development (in fact this applies to any team, I would say).
In fact, I could waffle on for hours, because that list is actually pretty lame. I know, it's not trendy to speak out against the cult of Spolsky / Atwood - but that list only covers a small angle, which is control. It kind of misses the point that to have better code, you need to employ people who aren't numpties.
Grant and Matt already provided outstanding answers, but I will add my two cents.
Overall, I think it is quite applicable, but it assumes you are dealing with a semi-large team of programmers working in a compiled language. Some of the steps need to modified if you are working with a small team dealing in an interpreted language, which is much closer to how most SQL teams work.
Obviously numbers 2 and 3 about the build steps makes no sense in an interpreted language like Sql or Python, there isn't one. Even in an interpreted language that can be turned into direct executables, it becomes much less important to worry about doing that until you are in late stage testing.
Also, I agree about having a spec, with a caveat. It does not make much sense to do any major work without one. With that said, I would like to emphasize that frequently, especially in the early stages, it makes sense to have that spec be highly informal and make sure everyone on the team understands it will change. I have never completed anything but the smallest of projects without the end user coming back to me and saying something like "I know this is exactly what I asked for, but what I really want is...." So, especially when you have the luxury of direct and constant feedback from your users, the spec should very much be treated as a living document and not a final statement of design.
And perhaps he considers it too obvious to mention, but when possible have automated testing set ups. This does not always make sense (I have never figured out how to write meaningful automated tests for a GUI), but when it does then having them can save you considerable trouble. I must confess that in the opposite fashion of TDD I often write my tests after I write my first draft. I do this because I often decide to modify the scope of my function, merge functions, or split them while writing them. But whether you write them before or after, I think the value in having them can be tremendous.
Finally, I will second Matt in saying that all members of the team should take some time to keep up with technology, and I know some managers will disagree with me, but I think this should very much be on company time. It benefits the company directly and having your coworkers around to talk to while you are working on it can help a great deal.
I don't know. I'd say successfully deploying a database is about the same thing as a successful build for a coder. You know your structures and code are correct enough. They still need actual testing, but you can build/deploy, which is the first hurdle. Other than that, yeah I agree with this too.
@Grant, I can see your point. I hadn't looked at it as the same thing as a build, but if you see it that way then 2 and 3 are at somewhat more applicable.
I had to bend my brain for most of it anyway since development & database development are so different, I just kept trying to come up with a db equivalent for the concepts.
