The Different Kinds of Done
Jan 24, 2009 16:11

In my experience in software development, I've noticed that "Done" can mean different things to different people. "Done" is a popular word on software projects, but it's actually hard to pin down. Real production software in the real world is rarely "Done" in the way that we think of "Done," like a baked cake is "Done" or a manufactured item is "Done". Software is more like a book or an album or a movie - read a writer's blog or listen to a director's DVD commentary, and you'll discover that their work is usually delivered when they just can't stand to edit it anymore, and/or their time and money have run out - and hopefully it's "good enough" to go out into the world.

The trouble is, business people and managers often think of "Done" in the manufactured-like-a-car way, while software developers often see "Done" in the it-works-well-enough-so-kick-it-out-the-door way. This can lead to trouble - especially if, as often happens, a developer agrees to a strict date for their work to be "Done" or - more disastrously - there's a condition like payment or vacation time that depends on the work being "Done".

In software projects, it's good to keep clear the differences between "Feature Complete", "Done", and "Live":

  1. "Feature Complete" means all the big pieces of the project are in place, users can navigate through the site without dead links and perform most if not all actions without bringing up errors. There still may be layout issues, typos, unhandled exceptional cases, performance issues, badly migrated data, etc.

  2. "Done" actually means all of the obvious issues that aren't covered in (1) above have been addressed. Hackers, idiots, testers, and a million monkeys on keyboards shouldn't be able to corrupt the data or break into anything. The workflow and layout is all perfect and all of the pieces are the way that they're supposed to be. Every aspect of the application is covered by automated tests and is thoroughly documented.

  3. "Live" means that the application is actually out in front of the real world and paying customers. It actually runs correctly enough to be worthwhile to support and host.

One of the big issues in software projects is the unexpectedly huge difference between "Feature Complete" and "Done". Progress on a software project is often an "S" curve - slow to get started, rapid progress in the middle, and then slow to finish. "Feature Complete" is at the point where the rapid progress slows down, while "Done" is the top line that may never actually be reached.

Often, programmers consider "Feature Complete" as "Done" - the software does what it's supposed to do. This can lead to frustration with management or customers, since from their point of view the application may have loose ends or missing polish. Programmers see all of the complicated work that went into the core algorithms, the security model, the application logic, and all of that, and often get annoyed when management or customers complain about the wrong shade of green in a banner or type nonsense data into a form and get an error.

Often developers will tell management that the software will have "all of the pieces in place" by a certain date, which means "Feature Complete", while management will think that they mean every last detail will be attended to.

A big headache time for all people involved in a project is the last slow top part of the S curve, where the program seems almost ready but the list of problems or fixes that still need to be addressed seems to just keep getting bigger. The programmers, just having finished pushing hard to get to "Feature Complete" are often exhausted and ready for praise, payment, and maybe a vacation. However, because of the different understandings of "done," this most difficult part of the project hasn't been considered in the budget or time planning, and management is frustrated that everything has slowed down and is taking longer than it should.

In the old days of putting software on a disc and into a box, you had to hit "Done" type 2 (or at least get really close to it) before going live (type 3). Nowadays, with most software hosted on the web and easy to update and fix, applications go "Live" before they're really "Done", since changes are easy to make and getting things in front of the world is a great way to see what works.

Developers need to understand that "Done" often means more than having all of the basic features in place, while those who manage or employ them should know that software is never done.

Giles Bowkett's RubyFringe presentation
Oct 01, 2008 18:14
Yeah I Use Tables For Layout, So Sue Me
Feb 02, 2009 22:25
Other Blog Posts
My Expanded Twitter Thread about BurgerWeek 2021 This Is Nowhere: The Server Side Building a React Native App Without Tears - Part 3 Building a React Native App Without Tears - Part 2 Building a React Native App Without Tears (Mostly) This Is Nowhere: The Memento Edition This Is Nowhere: Aspects of Accessibility Presentations About NowHere This Is Nowhere: Head-First Into React Native This Is Nowhere: Bloomsday Halifax This Is Nowhere: Why an HTML/JavaScript Single-Page App With GPS Is A Bad Idea This Is Nowhere: GPS and Wayfinding and More UX This Is Nowhere: The Single-Button UX This Is Nowhere: Don’t Just Stand There! This Is Nowhere: Finding My Duck Finding Burgers Fast: My DIY Halifax Burger Week Site "This is Nowhere" at PodCamp Halifax 2018 The Diary Diaries: Fixing Remembary's Facebook Connection Special Leap Day Edition of "Some Weird Things About Time" What's Up With Remembary Can't get pg_dump To Work Now That Heroku Has Upgraded Postgresql to 9.4? The Best Thing I Ever Did To Promote My App If You Build It, They WON'T Come #deployaday, My Big Hairy Plan for 2015 Extracting Plain Text from an NSAttributedString My Year of "Hits" Part 2: Remembary Rolling My Year of "Hits" Part 1: Remembary Rises (and Stumbles) Handy Little Test Method to Check for Translations in Rails Apps My Suddenly Slow-Waking MacBook Air Indie App PR: Keeping Control of Your Tone A Quick Note on 'clone' in Rails 3.2 My eBook Apps 2: iOS, JavaScript, and Ruby My eBook Apps 1: Introduction Quick Tip: No Sound on Mountain Lion My Upcoming Talk at PodcampHFX 2012: My Year of "Hits" Building at the Speed of Funny Screencast Tips Remembary's Cool New Picture Support Indie App PR 2: Keeping On Top Of User Feedback Indie App PR 1: How to Handle an App Disaster Giles Bowkett Diary Project 2 Remembary Video Congratulations! Welcome to Your Nightmare! How My iPad App Remembary Took Off Why You Should Have an App in the App Store (Even If You Probably Won't Make Any Money) PodCampHFX Remembary Presentation - Part 3 How I Used MailChimp Autoresponders to Promote Remembary PodCampHFX Remembary Presentation Part 2 PodCampHFX Remembary Presentation Part 1 Why AdWords Ads Don't Work for iPad Apps Remembary is Sponsoring PodcampHFX Why Can't I Resize my Views in Interface Builder? Momento and Remembary Concerning Remembary iPad-Friendly eBooks of Gracian's Art of Worldly Wisdom Project Report: PTOS2 A Quick Note on Encryption We're all LUsers Thoughts on HAML Friday Afternoon Hack - Getting Beyond the Basics Halifax Friday Hack and Back to Basics Quote from Wil Shipley FutureRuby Make Web Not War Busy Week I: Toronto Ruby Job Fair Employment.nil - the Toronto Ruby Job Fair Code Count: Ruby on Rails vs. C#/ASP.NET A Brief Note on Twitter The Hub Halifax and Mobile Tech for Social Change Deep Thoughts on Microsoft From The Accordion Guy The Two Kinds of Defensive Programming Presentation - Fixing Careerious: From C#/.NET to Ruby on Rails Enterprise! Presenting at Ruby on Rails Project Night - May 7th New Name and New Look for Careerious/Clearfit FutureRuby and More From Unspace Health Tips for Programmers This tables meme won't die Careerious - Ruby and Rails vs. C#/.NET Yeah I Use Tables For Layout, So Sue Me The Different Kinds of Done Giles Bowkett's RubyFringe presentation OfficeTime: Great Time-Tracking App for OS X Back With A New Look Non-DRY Feed torontorb Keeping Your Sanity With The Command Design Pattern shindigital Is All Grown Up! (according to the spambots) Startup Stars? I'm so bored! The Magic Words for RMagick Jennifer from Operations You see? Naming is HARD Business Software as Process Documentation Deployment note: 'execve failed' Steve Jobs on Market Research Why Canada Is Better for Entrepreneurs "Program first and blog second" Toronto Tech Collage The MacBook Air Is A Roadster RubyFringe! Quote of the Week: Steve Yegge Starting Up: Cards Great design tool: Starting Up: The Logo Quotes Of The Day: Hedge Fund Interview TSOT Ruby / Rails Presentation Night - Part 1 Moneyworks: Accounting Software for Canadians on OS X Starting Up: The Name Nice logo, but why is your site so bland? Welcome to