The "Dev Complete" Fallacy
Has your manager ever walked over to you and asked when the story you're working on will be "dev complete"? Or have you ever overheard someone ask in a planning meeting "When will the product be dev complete?". Yes, I'm sure it sounds familiar. It's also one of my least favourite managementspeak phrases because it nonsensical.
Let's stop for a moment and consider what's being asked. What is "development complete"?
Many managers are stuck in a waterfall, sequential way of thinking. Requirements are thrown over the Chinese wall to developers, who throw it over the wall to QA and then, somehow, magically, working software appears out of the end. To them "dev complete" usually means ready to pass to QA. However the tacit implication is that it is not expected to come back again….that, well, development is complete…. The problem is that unless it's been tested, who can know whether this is the case? And if it there is a problem, then more development is required, so it's not complete.
So here's my alternative definition for this bizarre phrase:
"Dev Complete" means Done. As in Complete. Finished. Tested. Ready to ship.
Any other definition is simply "Dev incomplete".