August 11
Shuttleworth on Project Management
Mark Shuttleworth, of Thawte fortune and Ubuntu fame, has some (IMHO) neat ideas on how to manage software development efforts that may be interesting to spend a few human processing cycles considering.
http://lwn.net/Articles/292031
Despite the article being written for Free Software and Linux, I think it’s incredibly relevant to all development efforts – read it as if he’s talking about Molecular projects, and not Linux distributions.
Here are two key paragraphs:
One of the key requirements that Shuttleworth sees is the need to “keep the trunk pristine”, by doing integration on the trunk and feature development on branches. Along with this is the need for more and better tests. While not necessarily believing in test-driven development, he certainly leans that way. In any case, all the tests should pass before committing to the trunk.
Many projects do not yet have an extensive test suite, but this needs to change. He quoted a Chinese proverb that “the best time to plant a tree is 20 years ago, the second best time is today”. He mentioned that he is working on a robot that controls the trunk of a development tree. Developers will request it to merge from a branch, so the robot merges the branch and runs all the tests. If the tests pass, it commits, otherwise it gets kicked back to the developer.
This approach sounds pretty good to me.
The Shuttleworth on Project Management by Molecular Voices, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 Unported License.
Shuttleworth on Project Management said on August 11th, 2008
Adam Stachelek said on August 12th, 2008
I’ve been working with a client (I’m a contractor) that subscribes to this principle fairly rigorously. Though I don’t have full visibility as to how it’s working, in my experience, they’ve spent more time in unit tests than they have in adding functionality, which isn’t necessarily a bad thing. They aim for 80% coverage which is in line with the 70% standard you emailed about before and I think that is a very good idea, since, in their case, they use unit tests not only for coverage and regression, but as a method of communicating API changes. You won’t really get an email or notification about an API change (unless you sit there watching SVN commits religiously) until your code breaks with the latest svn update. It’s an interesting approach, and can be a bit harsh, but if you have good code coverage, it’ll ensure that all your interactions with that API are updated.
Now automated UI testing is another animal all together. I think it’s hard to maintain automated scripts when a UI is constantly in flux, but the concept of code coverage to highlight incompatibility with a changing API could be applied for some basic automated UI testing to the same effect that a business layer might make use of such test.
Craig Andrews said on August 13th, 2008
I’ve never been a big fan of UI testing – it seems to be a huge time sync with minimal return in the case of most of the projects that Molecular does where the UI is constantly in flux.
I usually don’t see unit testing as a form of “documentation” for API changes, but I suppose that is another really useful way to look at it – and I’ll definitely be bringing that up in future conversations.
Adam Stachelek said on August 13th, 2008
Jim Lamoureaux said on September 25th, 2008
Project Management said on August 10th, 2009