views:

650

answers:

12

As software developers we create lots of... well... code. Much of the code we produce can go towards a new feature or an enhancement to an existing feature. When this is the case, how do we know when this feature is done?

What does done mean in the context of a feature? For example, to Company A this may mean many different things like,

  1. Meets customer requirements (which is tricky in itself)
  2. No known bugs
  3. Documentation is written
  4. etc.
  5. etc.

To better help understand what done means to different developers and teams please list up to five (but no more than 10) items. This list would be something you as a developer, or your team, might go through and once all items are checked off, the feature is considered done.

Update

These are some great answers. I'm trying to figure out how to determine the best one as I guess this question is somewhat subjective. I guess I'm still looking for a more complete picture.

+1  A: 

When the user's happy with it.

moobaa
+11  A: 

When the client/user signs off on the UAT (User Acceptance Test) after testing it. That's our official measuring stick.

Of course that doesn't mean anything because invariably there's a version 2.0 of the feature requested a few weeks later, but that's more on their end than ours.

edit - If you want to be really detailed about it, here's how we do it:

  1. Requirements are approved by system analyst and client
  2. Design is approved by lead programmer
  3. Code review is approved by peer programmer
  4. Code is marked as tested in unit testing by QA dept.
  5. UAT is signed by client after personally testing it themselves.
  6. Code is marked as tested in system testing by QA dept.
  7. Code is released.
MattC
Your answer was definitely the most complete and thought out. Thinking about it more, this question is a bit subjective and therefore a difficult one to answer "correctly". You are most in line with my thoughts though.
Scott Saad
A: 

When it ships.

Joseph Daigle
Perfect -- if you build boomerangs.
Adam Liss
+1  A: 

When there is nothing left to take away from it.

Josh
+2  A: 

When it solves the problem it was envisioned for. This carries with it the burden of adequate testing, documentation, usability, etc - not too much, but enough that it does what it needs to.

Allan Mertner
+1  A: 

When there's a fork in it.

  • Code meets the written specification
  • Code passes code review
  • Code has and passes unit and integration tests
  • Code passes QA
  • Package with code is signed off by all stakeholders
Adam Davis
A: 

Your feature is done when all the tests associated with it pass. When requirements change, add more tests and code until THEY pass too.

Big Dave Diode
A: 

I think it depends on the people looking at it. Developers naturally want to take code to the nth level, whereas a customer will have a vision for it..

So,

  • Customers, when they stop asking for changes.
  • Developers, never :)
Rob Cooper
+3  A: 

if you mean "done" in the sense of "we'll never have to touch that again", then the only answer is: when the system is obsolete ;-)

if you mean 'when it is ready to ship' then presumably when all of the agreed-upon unit tests pass, assuming TDD/XP/Agile methods of course.

Steven A. Lowe
Haha! Actually, by done I'm meaning more in the lines of when the feature is "complete" and possibly ready to ship.
Scott Saad
edited to address this
Steven A. Lowe
+1  A: 

For us, a feature is done, meaning we can ship it, when two criteria are met:

  1. a feature passes all of the unit tests and manual tests we wrote at the beginning of the release. This is determined by the QA or developers in the absence of QA.
  2. doing the outstanding change requests/bug fixes to a feature provide less value than the resources (time) needed to complete them. This is determined by the product owner.
Will Read
A: 

Simple answer: When it meets the requirements of the customer (or the people you are implementing the feature for).

Not so simple answer: When it meets all the intrinsic requirements people/the customer expects: hidden quality requirements, extensibility, documentation, stability, ease-of-use, etc.

akr
A: 

Distasteful, politically incorrect, but pragmatic answer: there is (at least) one critical point during the evolution of a feature.

  • Release the feature before this point, and you lose because the customer will not accept the feature. It will cost more to fix--in time, materials, reputation--than it would have cost to "finish" it.

  • Release the feature after this point, and you lose because of opportunity cost. You would profit more by focusing your attention on something else.

The feature is done when it reaches this critical point.

Adam Liss
Note: I don't "like" this answer, but it's the way business is run. The terms "profit" and "cost" include intangibles as well as monetary amounts. I contend that the company that strives to maximize "profit" and minimize "cost" over the LONG TERM is the one that wins.
Adam Liss