Have you heard about the DRY (Don’t Repeat Yourself) principle? This is the book that introduced it and has the original explanation and motivation for the concept. To be a book about software it is remarkable timeless. Most of the tips are as relevant today as they were 10 years ago when the book was written. Source control is now much more widespread than it was back then, but Tip 23: Always use source code control still applies. Believe it or not, there are projects out there without it.
Tip 4: Don’t Live with Broken Windows
With a metaphor from research in the field of crime and urban decay the authors talks about the importance of fixing defects. If a real fix is not possible, at least board it up as a temporary fix. Don’t leave it broken without doing anything. It sounds obvious, but to be honest it’s hard to always live up to that standard. Being a consultant with constant managerial and customer pressure to be efficient and do more in less hours it is of course tempting to ignore the broken window, but each time I do I’m slicing off a bit of my professionalism.
Tip 11: DRY – Don’t Repeat Yourself
The DRY principle is often mentioned as a coding principle, to guard against copy-past programming. The reasoning in the book goes not only one, but several steps further treating duplication of knowledge in separate programming languages and in the documentation. To anyone coding on the web the issue should be well known, with user input validation done both in client JavaScript and server C#/Java/PHP code.
Tip 29: Write Code that Writes Code
Andy and David are really fond of writing helper scripts for anything that can be automated, including writing code. It might look like an overwhelming task to write a code generator, but it doesn’t have to be very complicated to work. The book makes a clear distinction between active and passive code generators, where the former are one-shot generators while the latter are meant to be re-run when code is updated. In the Code Generation – Blessing or Curse? post I’ve written about the double-edged sword of code generation.
Tip 44: Don’t Program by Coincidence
You’ve written a bunch of code, trying different alternatives until it passes you’re tests. Are you finished?
No, you’re probably not until you’ve went back and checked that code and made sure that you understand it. It should not be a coincidence that your program (appears to) work. When code reviewing I’m sometimes asking for an explanation of a perfectly looking piece of code. I want to make sure that the person who wrote it knows why it works and has not just programmed by coincidence.
Tip 61: Don’t Use Manual Procedures
This tip is from the chapter on ubiquitous automation. This is where the book really raises the bar. Everything that can be automated should. If you’re doing a task repeatedly, such as checking out code, compiling and deploying to a server, the entire sequence should be automated into one command. Reaching that is really high standards. Are you there? I’m not (yet).
The Other 64 Tips
I’ve mentioned 6 tips here, there are 64 more in the book. To be honest, there are some parts of the book that are a bit outdated, when it comes to details about architecture. Sometimes (e.g. design by contract) I also think that the authors go a bit too far, beyond what is practically possible to implement.
Nevertheless the overall impression remains. The book is well written and as time less as a book on software development can possibly get.
If you haven’t read it before, order yourself a copy
The links to Amazon in this post are sponsored.