Mark Shuttleworth, father of the de facto linux desktop OS — Ubuntu, recently weighed in on a few different issues. He wanted to address some recent moves towards getting the Gnome and KDE crowd to talk nice to one another. The continual effort to make the linux desktop something that is more stable and recognizable to normal non geek users is something I have to applaud unendingly. If it wasn’t for all his work in that arena I would probably be considering what version of nastiness that is called Vista I would run next year.
He also talked a little bit about Source Control Management(SCM). SCM is just a fancy name for the overall business practice of making sure developer’s develop and collaborate in a way that makes sense. Oh, we screwed up with this idea 3 weeks ago? Well, let’s pull that code out of there. That sounds simple enough, but as it turns out the other thousand employees in your company have continued to write new code from when you started this change 3 weeks ago. So if you just back your change out, it might not work with the code they wrote over the last 3 weeks.
One of the tools used to handle these sort of problems is called a Version Control System(VCS) and there are hundreds if not thousands of these things. You’ll recognize them by names like CVS, Subversion, etc. Apparently Mark is hot to trot for one that’s called Bazaar.
Another tool, and the point of this post, is that you need a testing tool/suite and a methodology. Now I wish Mark had talked about the name of his testing suite, but the more important thing is how he changed the way the code is written. By implementing or creating Testing Driven Development he basically put a stake in the ground and said, “You will not check code back into the repository unless it passes tests.”
That doesn’t sound that revolutionary, but it’s not how code is traditionally written. Most developers write and write and write, checking in code all the while and then they test. Well, frankly that may be a bit of a waste of time. If it turns out that your basic idea sucked, then wouldn’t it be better to figure that out at the starting point? And it also disciplines lazy programmers to correctly code their exit codes and other basic frameworks of good code right at the beginning, rather than trying to put all that “boring stuff” in at the last few days before the release.
His methodology probably feels like he’s slowing down the development process, but in the long run it’s probably as efficient and it also probably makes the prediction of release schedules more accurate.
Finally, how does this apply to me and possibly you? Well, I always swear I’ll set up a testing suite for what I do, but I don’t really do a dev/test/production cycle for WordPress. I think that the next time I actually write a full application I will probably find a VCS and Test Suite combo that will allow me to implement TDD. I’m just as lazy as the next programmer and so having a computer add a little discipline wouldn’t be a bad thing.
For WordPress, I think I’m going to set up some basic monitoring. I already monitor uptime, but page load times I’m not and I’m unhappy with how the ads are bogging my load time down. If I don’t measure that, then I’m sure I’ll never start working on it. Also, the ability to comment on posts is something that I haven’t been monitoring and it’s something that has already broken during one upgrade. Drive space is rarely an issue because Dreamhost sells me so much but it wouldn’t hurt to monitor.
Well, that’s my plan. Do any of you plan on using any of these sorts of development tools?