software solutions / project leadership / agile coaching and training

Done means Done

Posted on August 1, 2010

One of the commonly held principles of Agile is that you build software incrementally. I know a lot of you have heard this and think you understand what it means, but are you actually living it out?

Here’s what I mean: as a developer, when you say that a feature that you’re working on is done, are you sure that it meets all of the requirements? Have you accounted for all of the edge cases? Is it production ready code?

If you answered anything other than “yes” for any of those questions, then I would question what the word “done” means to you. “Done” does not mean that you’ve coded it to work in most situations and that you’ll rely on your QA team to find bugs for you to fix.

The problem is that when other people hear you say “done”, they will assume that you really mean done. This is especially true with business people and management. In their world, done means done.

There is really no point in not using the same definition of “done” as business people, because they’re the ones paying for your project. So when you come back to them and say that you need a few weeks to just fix bugs, they’re going to give you weird looks. “Wait, I thought you said that was done.”

Before you even start developing a feature, sit down with your BAs and QAs and define what “done” means for this particular feature. Think of all of the requirements, edge cases, and non-functional requirements (like how fast it should load).

Now you start coding. Write unit tests first that will prove that your code will fulfill the requirements. Then write the code to make the tests pass. Then go through the requirements and manually test it to make sure that you got it all right (you can’t easily write a test to see if you got your CSS right, or if the page loads fast enough). If you have to, refactor your code so that you don’t have any hacks or technical debt. Now you hand it off to your QA team. You should expect that your QA team will find no bugs in your code. Maybe they will find bugs (because you’re not perfect), but that will be the exception instead of the norm. You should think that your code is ready to go to production.

Now you can really say that your feature is done! My definition of “done” is that there is no more work to be done on the feature. That means that not only should it do everything that the requirements say, but there should not be any technical debt added or things that you have to go back and refactor later, because then you’re not really done.

So when you say you’re building software incrementally, make sure that you really are done before you move on. Have high standards! There’s no point in settling for anything less.

3 Comments »

  1. Done means Done…

    You’ve been kicked (a good thing) – Trackback from DotNetKicks.com…

    DotNetKicks.com — August 2, 2010 @ 12:29 pm

  2. [...] This post was mentioned on Twitter by Jon Kruger, Jon Kruger. Jon Kruger said: Blogged: Done means Done http://bit.ly/cChinR [...]

    Tweets that mention Jon Kruger’s Blog » Done means Done -- Topsy.com — August 2, 2010 @ 12:45 pm

  3. Walking on water and developing software from a specification are easy if both are frozen. The hard part is when no one has finished thinking through what done is to them.

    developingchris — August 2, 2010 @ 11:53 pm

Leave a comment





SERVICES
SOFTWARE SOLUTIONS
I have over 10 years of software development experience on several different platforms (mostly Ruby and .NET). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
PROJECT LEADERSHIP
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
AGILE COACHING
I believe that Agile processes and tools should be applied with common sense. I've spent the last 6 years working on Agile projects as a consultant in many different environments, both in leadership roles and as a practitioner doing the work. I can help you find out how Agile can work best in your organization, not just apply a prescriptive process.
TEST DRIVEN DEVELOPMENT TRAINING
TDD Boot Camp is a hands-on, three day, comprehensive training course that will teach you all of the skills, tools, frameworks that you will need to use test-driven development to develop real world .NET applications. If you're not looking for something that intensive, check out the the half-day version.
Have any questions? Contact me for more information.
PRESENTATIONS
The Business of You: 10 Steps For Running Your Career Like a Business
From CONDG 2012, Stir Trek 2014
From Stir Trek 2013, DogFoodCon 2013
From Stir Trek 2012, QA or the Highway 2014
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010