I now design software according to a simple set of principles:
- Do the simplest thing that could possibly work
- code the test first, then the feature. Stop coding the feature once the test passes
- Take a cold, hard look at the code and remember: Once and ONLY Once. Remove duplication mercilessly and by any means necessary.
- Allow the code to speak to you about it’s design
Inside every application there’s a framework waiting to come out
There are general pieces of code in every application. If you ruthlessly follow the once and only once (OAOO) rule then you should look for duplication from one project to the next not just within one code base.
I love writing code that sits at the upper levels of the opertating system: services and useful framework stuff that allows other people to do their job. “This is going to be so useful” is a common thought in my head. At least it was until I arrived on my latest project. First time I said something about that thought the guy I was pairing with said “YAGNI” in a loud voice. What?
Y-ou
A-int
G-onna
N-eed
I-t
I was mortified! A beautiful abstraction was shot by the cruel farmer just as it was to take flight. My pair reminded me that the customer was paying for my time and the abstraction I was suggesting violated the first of my deign principles: it wasn’t the simplest thing that could possibly work.
A few days later, working on a different story for the user we met another problem. Several pair switches had occured and my ego was feeling a lot less bruised about the YAGNI comment. In fact I’d had the pleasure of yelling “YAGNI” at points and seeing people pull faces as they too realized that they were over complicated the code. My pair and I finished up looking at the problem and realized that we were going to cause duplication by applying the same simplest thing as last time and he set about creating the beautiful abstraction I’d suggested before. Why? In this case both features could share most of the code that solved the problem. In this case we neede to avoid duplication. In this case the abstraction was called for.
It’s called Emergent Design. Some claim that eXtreme Programming is chaotic and undisciplined, that it lacks design and attracts cowboy coders. My experience has been the exact opposite: solid well balanced people with an eye for design patterns, architecture and disciplined work ethic. All of us so far listen to the code and when it calls for an abstraction, we give it one, to satisfy the OAOO rule.
That is the problem that I saw in my old coworker’s code base. He’d abstracted too early, and you had to step to and fro through at least 4 classes and at least one interface to actually do anything. Since it was a single application there was no need, Im not saying there wasnt beauty in the design, but there wasnt a need to apply the abstractions that he had. His complaint about not being able to follow the code screamed to me that the code needed simplifying. I hope he doesnt mind!
Actually, I have them both, but that’s beside the point!