At one of my first jobs, as part of my introduction to the team, my new boss sat me down and bluntly told me:
Please don’t tell me something is done, unless it is actually done.
A few years later, in a different job, my manager introduced me to the brilliant term ‘done done‘. It’s a term we need in our industry. He would never just ask if something was ‘done’, he would add:
…I mean, is it done done?
In the world of programming thinking you are done, when actually you are not, is a crime we see again and again. I’ve certainly been guilty of it myself.
I once led a team through the integration of several new features into our product. After a few sprints, I noticed our burndown charts were always more or less the same shape.
For the first few days, we would always be ahead of schedule. At our stand-up meeting, members of the team would announce with delight that they were done, and our burn-down line would drop quickly.
As the deadline approached however, we would discover that those tasks we thought were done in fact needed a bit more work. We hadn’t fully tested them, we had seen a result and decided to move on.
As a result, our velocity would slow down and our burn-down line would creep above the ideal projection. And this happened sprint after sprint.
So when exactly are we done, or indeed ‘done done’? And why do we programmers insist on saying we are done, when really we are not?
The definition of ‘done done’ really depends upon your individual circumstances.
If you’re writing a throw-away script to move some data from one place to another, you probably don’t need to consider code quality and integration all that much. It may even be a waste of time. But if you are integrating a complex feature into a production environment, you can’t say it's done just because it seems to be working on your machine.
Has it been adequately tested? Has it been integrated into the build? Have unit tests been added? Have you reviewed and refactored? Does it need to be peer reviewed? What about documentation?
A recurring trade-off in the day-to-day lives of programmers is tedium against professionalism. We often know there is more stuff we should be doing, but it’s just not very exciting. We think we can just worry about that stuff later (when we are left with no other choice). The interesting bit is working towards what we imagine to be the desired result, and then feeling satisfied when we see that result on our screen. After all, the end-user doesn’t care about refactoring, unit testing, or code quality.
But the end-user does care when the system keeps crashing, and it takes forever for bugs to be fixed and new features to be added. What's more, your teammates won’t thank you when they have to understand and clean up your mess.
Another reason why programmers often say they are done too early is pressure. You probably came up with the estimate you are working against, and if your task is taking longer than expected you will naturally be eager to tell your boss that you are finally done. Fear of failure is something we all experience from time to time. If we admit to ourselves that we are not really done in good time after all, we may come to the conclusion that we have failed.
We mustn’t fall into this trap. If things are taking longer than estimated, stay calm. Don’t panic. An estimate is just that – an estimate, no one knows for certain how long something will take. As your experience in the industry increases, your estimating skills improve.
It is important to give yourself the best possible chance of providing a reasonably accurate estimate. When you are caught off guard by someone asking for a ‘ballpark figure’, ask if you can get back to them. Ask for ten minutes, scribble down what you think the subtasks are and then get back to them as promised. And when you are working out that estimate, don’t forget to include the boring stuff.
A useful concept for getting things ‘done done’, is the idea of doing a bit of everything every day. In ‘The Art of Agile Development‘, James Shore advocates this approach:
XP works best when you make a little progress on every aspect of your work every day, rather than reserving the last few days of your iteration for getting stories “done done”.
In this way, we will have a better feel for how far along we are, and we will catch nasty surprises early in the process. TDD and continuous integration are two obvious approaches to help us do this.
In summary, there are a few principles we can keep in mind to avoid falling into the ‘done done’ trap.
- Take your time. Don’t lose sight of the big picture and get excited by your imagined end result. Pay attention to the boring stuff.
- Don’t ignore that nagging feeling that your task isn’t fully complete.
- Hone your estimation skills. More accurate estimates reduce the likelihood of you putting unnecessary pressure on yourself.
- Don’t feel bad if things are taking longer than anticipated. Just focus on doing the best job you can.
- Before you start a task, quickly draw up a ‘done done’ checklist, and don’t say you are done until every item is ticked off.
- Try to do a little bit of everything every day.
…and perhaps most importantly - be honest, both with yourself and with your boss.
The post Done Done appeared first on The Proactive Programmer.
