We have a number of rules, with long abbreviations like YAGNI, DTSTTCPW and OAOO.
YAGNI, or You Aren’t Going to Need It, is an amazing concept. It tells us not to bother trying to predict the future, because we’re crap at it. We don’t build anything that doesn’t help the current test pass, and we don’t write a test unless we have to in order to implement the "story" -- our name for a type of requirement -- we’re working on.
Even then we write one test at a time, and only write code to make that one test pass.
In a classical project this wouldn’t work. With the support the rest of the XP practices gives to us we can thrive on this. The technique is simple – imagine that your customer is going to march into the room any moment and demand that the latest build be sent to an important customer immediately.
You want to ensure that the software you’ll release provides the maximum amount of business value. If you’ve wasted the entire project to date building a breathtaking architecture, the client will get nothing. If you’ve evolved your architecture in line with functionality, the client will get functionality. If the customer chose the functionality you’ve implemented in order of business value, then you’ve got the highest level of functionality that it was possible to build in the time allotted.
YAGNI also means that you’re focusing on solving the current task. You’re not adding extra complexity to the system that you don’t currently need. So, if you solve each problem in the simplest possible way, you’ll have the simplest possible solution to the current set of problems.
DTSTTCPW, or Do The Simplest Thing That Could Possibly Work, states that we should start simple, and if that doesn’t work then we can try the next simplest. This is the principle of simplicity, expressed as a rule. Note that this doesn’t mean that you take the quickest solution, or the easiest, or the first one you find – it means take time, and find the simplest. The investment of extra time pays dividends, rather quickly, when changing the system. And remember, the next engineering task qualifies as a change.
OAOO, or Once and Only Once, states that there must be absolutely no duplication in the code. This is a lofty design principle that can be achieved through diligence and refactoring. Duplication is the root of all evil – it costs a fortune, increases risk and reduces quality. It is directly responsible for the cost of the millennium bug.
Imagine if each system only had one place to manipulate dates. How expensive would the millennium bug have been then? Quite expensive? Perhaps. Unprecedented? Unlikely.
Breaking out of the acronym-laden rules we find that the coding standard is one of the most important things we have in an XP project. You all already know that coding standards are important, but a lot of you ignore them. This isn’t allowed on an XP project. Because our programmers work in pairs – did I mention that? – they must be able to understand each other’s code. Because we practice collective ownership – did I mention that too? – each developer must be able to rapidly understand the work of others. Basically, because we’re working as a team, and we all own and use all of the code, it must be homogeneous, otherwise we’ll be spending ages reformatting the code, rather than adding to it, and that will play havoc with the diff and build tools.
Our coding standards are, like everything we do, quite light. If everyone does the same thing, we won’t even bother to write them down. It’s even better if your development environment enforces your coding standards.
I thought that I’d just clarify this, just in case you missed it before. All production code is written by a pair of developers, on one machine, at the same time. Paradoxically, this leads to massive increases in productivity and quality.
There’s no more waiting two weeks for Sally to get back from her holiday and make those changes to the DooLally class to support your much needed architectural magic. Now you just make the changes yourself. This is good for refactoring, which quickly passes ownership boundaries on a classical project. It’s also good for the team, because it lets them be a team. It does mean that you have no auditing and therefore no one to blame if things go wrong, which is again a good thing -- team responsibility.
Alignment of authority and responsibility
This is perhaps the biggest change from classical projects to XP projects. Management gurus have been telling you for years to do this, but have you? Not in software development you haven’t. If a developer is going to get the blame for not meeting a deadline, first have him have input on the variables “time” and “scope”. Secondly, give him the authority to do the job however he sees fit. He’s a good employee, and more highly educated than the rest of your staff put together – trust him.
Next column I’ll have a Software Developers Conference rundown from Wellington, reporting what Jim Highsmith and Martin Fowler have to say about agile methods and refactoring.