Along with TDD, which I’ve ranted about previously, one of the more misunderstood development practices of XP is the approach towards simplicity. Doing the simplest thing that could possibly work is not the easiest, laziest or most stupid thing that could work. However, as it turns out, this is a relatively difficult concept to communicate as well as a fairly difficult approach to put into practise.
This blog entry has been inspired by one of the Bill Venners interviews with Ward Cunningham titled The Simplest Thing that Could Possibly Work. Bill talks to Ward about how Ward and Kent came up with this principle of doing development focusing on simplicity. However, while this is a great article, I went away thinking, “well, Ward talks about simple, but he really doesn’t help me, or others, understand how to do that”.
So, I sat and thought for a while about what simplicity means to me and how I aim for it during design and development.
For me, simplicity of implementation is closely aligned to the principles described by Mary Poppendieck in her book Lean Software Development. These are related to minimisation of waste, and delaying of decisions to the last responsible moment. Minimisation of waste in code is making sure that at any point in time, we’ve got the code only implementing the functionality that we’re promising to deliver for that iteration (or release) and no more. Delaying of decisions also assists in keeping the code and environment to a minimum. In retrospect, how many times could the software have been developed, or delivered without the database, without the “important framework”, without the application server ? Certainly I know of many occasions the choices made in those matters have meant a more complicated environment that I’ve had to keep up to date for the entirety of the project. This just adds to my “inventory” of code and contributes to waste.
I can explain to people about how excess code means more maintenance and requires more attention. I can explain to people about how implementing a database and an application server early on in the development cycle requires more care and feeding during the course of the project.
I hear the cry “But what if I’d needed those”. In hindsight (a beautiful thing) in most occasions I could have implemented them later in the project with an absolute minimum of fuss.
Now, the process that I use to keep my code simple is as follows:
- Write a test that would help prove that my code meets the acceptance criteria
- Implement just enough code to make the test pass
- Search my code for duplication and/or things that look yukky and when I find it, I modify it to make it less so
- I now think of any other tests that need writing
- Go to step 1
Yes, I write my code in a TDD fashion. It’s not the only way, but I have found that it’s the easiest way for me to keep my code implemented in the simplest way. It’s a hard approach to take, because at every stage I have to fight the urge to introduce more code “just in case I need it”, but as each of the steps I take is fairly small, and I can focus on just making a single test pass I find I can keep control and keep my code simple.