Menu

Or, Why freezing is good for popscicles, but not code.

Someone tell me, what does “Feature complete” mean anyway? Furthermore, define “Code Freeze” for me too.

Project managers use these terms like a warm fuzzy blanket to give them security when those cold hard release deadlines are rearing their ugly heads. But my question is, until you actually have a fully releasable product, how can you possibly even pretend to say your product is “Feature complete” or in a “Code Freeze”? Typically, they like to apply these terms as the application is going into a QA code-n-fix stage.

Isn’t the definition of releaseable software, software which has been 100% tested and verified as working?

Can you, as a developer, honestly say that any part of your app is “complete” before it is 100% tested and verified as working? And if you can say your feature is “complete” before it’s 100% tested and verified as working, I for one sure as heck don’t want you working on any of my products or even on anything I’m going to spend my hard earned cash on!

This is simply nonsense! Anyone who uses such terms should be exposed as the software charlatan that they are! If they refuse to relent, they must be beaten. If physical violence is frowned upon in your organization, the fool must be fired. If upper management is goofy enough to use such terms themselves, then run away! This is a company that wants you to lie to them. Be prepared for them to lie to you too.

“But we need some kind of milestone before release to know if we’re going to hit it or not!” I hear you say. Ok, I can accept that. But the problem is that these particular measurements don’t really mean anything. Any number of serious bugs could still be lurking in that code. And any of them could be enough to blow you past your release.

All that said, I would just be blowing a lot of hot air if I didn’t make some sort of recommendation for a better way to do it.

I think the Xp guys are onto something when they measure their software via automated acceptance tests. I believe that software completeness, and ultimately software quality can only be measured as a boolean condition. It either works or it doesn’t. One or Zero. And if it works, then it can be released. Any state other than 100% confirmed working is “not working”-not 99% or 75% – 0%. If you need more granularity than that, you need to ask for less. That means “small releases.”

This is the only way to deliver predictably.