Once upon a time there was a software development methodology called waterfall. People disliked it for many different reasons, but today I will only mention one in particular – that it was hard to see anything working, before it was too late.
So, people turned to agile development, delivering business value in increments, during complete project life-cycle, after every iteration. Although Agile Manifesto says quite few things, most of sales guys and PO’s remember only single one: there will be a demo every week or two: and then you hear them saying: oh, yes, yes, finally!!!! Even better, we can finally show something to the customer, get a feedback, bring it back to the development and in the next iteration show the new stuff again… Fantastic, great, beautiful. And it really is. But… there is a catch. Mr Hyde is coming….
What often happens is that agile teams are too focused on development around demos, since this is the only way they are getting evaluated outside of engineering. Obviously, more you show every iteration, assumption is that this team is more productive. Finally, rather than keeping eye on all aspects of software development, team might start making too many shortcuts, leaving dirty hacks and famous //TODO comments all over the place (if they still feel like doing it).
Just as a test, try this in your project, go to the root of your source directory and try this one liner: find . *java | grep -v todo | wc -l
First time I typed this command on my project and saw the number, I almost dropped the coffee on the floor. At first I was surprised, then felt angry, and then betrayed. After all, all these guys who left these traces behind were my good friends and colleagues, and they were excellent coders, just brilliant. So, how was that possible I wondered? Why would someone add reminder and never come back? Was this a message to himself, or to the next guy, like if you go to the toilet and read graffiti on the wall, or was it some kind of subconscious mea culpa sign?
And then I realized – it was me, it was mainly my fault. It was me who always pushed to the limits, who was too much into demo thing… And this is what happened:
Every day, Dr Jekyll would come into to the office and write something fast and dirty, and since he read the book “Clean Code”, would leave the trace behind him, as a reminder to come back later and clean the stuff. At the end of the iteration, Mr Hyde would suddenly arrive, show a demo, write down the feedback, erase the memory of Mr Jekyll that there was something still //TODO and move on again.
So, you may wonder how it all finished for us? Well, we were quite experienced group and we knew when something was really bad. If we couldn’t stand the code smell any more, or if it looked impossible to add a new feature without having a brain damage from trying to figure out how actually existing stuff worked, we would go back to PO and announce that we had to do “big re-factoring thing”. And most of the times it worked out, but unfortunately, sometimes it was too late – we rushed too much.
And finally, this post would not be complete, if I didn’t have 7 rules of how to avoid DDD (Demo Driven Development), so here we go:
- Be fast, but not crazy
- Review the code – always
- Have time to come back, some things are never 100% done (life is never perfect, so it is with some “done features”)
- Avoid re-factoring tasks, ask folks to refactor while coding
- Not everything can be done between demo’s – some features just need more focus and different planning – more about that in another post
- Never ever design API/SDK/NBI in increments
- Never add a feature that is half right (notice, I am an optimist, I didn’t say half wrong). Half right is always wrong.