The Old Joel on Software Forum: Part 3 (of 5) - Feature "Feature/Code Freeze"

Feature "Feature/Code Freeze"

Hi,

In the context of a release, every company I have ever worked in has the concept of a coding stage, with a date defining "feature freeze", followed by a 'stablization stage' (read: fixing all the zillion bugs QA has found), which eventually ends with a code freeze, which really means "only fix really bad bugs".

So, I have read about the concept of coding every feature until it is really complete before moving on to the next feature. The idea sounds great... Joel even has an article on "Zero bug" coding, which is similiar.

The main benefits I see are:

1. At any moment, I can cut and release with the completed features I have.

2. It is faster to fix a bug I made last week than it is to fix a bug I made last month.

3. Every bug I leave lying around has an 'undefined' amount of work associated with it.

My question is - can it really work? And if so, how?

Let's say I have 3 teams of developers, and each developer will be coding at least 2 features. Some of the features are going to be coded between two developers, with an integration.

QA expects to get regular builds, at a scheduled time.

So, Dev A and Dev B code Feature "Really Cool Widget", they integrate, unit test, blah blah. They are done on the 5th. The build into QA isn't scheduled until the 7th. QA will take a complete day to do sanity / regression, with a few more days to test stuff. That means the bugs won't really be known until 9th/10th...

Obviously, I don't want Dev A and B to be sitting around playing Halo, so they are already in the middle of developing "Another Really Cool Thingy"....

Do they just drop that, and go back to fixing bugs on "Really Cool Widget"? Does the context switch justify the benefits?

I would loev tp hear from someone who really works this way, and has made successful comercial releases using this method.

Thanks.

Michi
Thursday, December 18, 2003

It appears to me that your current setup is a bit off from where you would need to be to really take advantage of this type of development. If QA takes a full day to do their testing (which one presumes is more testing than could be accomplished with programmed tests which can be automated) then they need to work on your schedule, not the other way around. You should be able to code/test/build/send to qa, and get a result back by that time tomorrow. That reduces your lag to one day instead of three (or more). And immediately turning around after that day of development and squashing those bugs will help future development and hopefully prevent a bug from propogating or affecting other code in unforseen ways.

Lou
Thursday, December 18, 2003

I've never had a QA department to deliver things to, so you might take this advice with a grain of salt. I would recommend that the programmers deliver directly to QA, and work through the day with QA to hammer out any bugs.

The closest that I've come to this is a daily or twice daily meeting with a non-technical tester. He'd find bugs, we'd retreat and fix those bugs before the next scheduled meeting. This was combined with checking milestones, partially because we needed to build a working inventory control system in seven calendar days.

Clay Dowling
Thursday, December 18, 2003

quoting from ' The Joel Test: 12 Steps to Better Code' [1] Joel sums up the approach like this:

"'zero defects' meant that at any given time, the highest priority is to eliminate bugs before writing any new code."

He gives to reasons for taking this approach

1) It is easier to estimate the time that will be taken to write new code than to fix a bug

"If you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate."

2) You're build is ready to ship.

"You can respond much faster to competition. Some programmers think of this as keeping the product ready to ship at all times."

Applying your scenario to Joel's description of the approach doesn't seem to difficult. You just need to nail down what you mean by 'writing new code.'

What is your smallest unit of code? A line, a function or a feature?

In your description it looks like you take feature as the smallest unit. A feature is developed, passed to QA then either integrated into the build or passed back for bug fixing.

If you are taking a feature as your smallest unit of code, then the answer to your question is to finish the current code, but fix all bugs before starting a new unit (the next feature).

Then, when you have returned to a status of Zero defects you can review your schedule. Do you still have time for all of you outstanding issues?

When you are up against the deadline then you will need to decide between the current unit and the unit returned for bug fixing. If there isn't enough time to do both then you have to decide which one is the most important. If it is the current, then finish it. If it is the one returned by QA then abandon the current and fix the bugs.

[1] http://www.joelonsoftware.com/articles/fog0000000043.html

Ged Byrne
Thursday, December 18, 2003

There aren't any absolute rules. You need to use
a cost benifit analysis for you situation.

If you get a data corruption on run 1002 of a test is
that more important than creating a new
revenue generating feature?

And depending on your project, bugs may be found
much later. Some tests can take a very long time
to setup on very costly equipment and take
a long time to run. Should you just do nothing
until these are run?

son of parnas
Thursday, December 18, 2003

My own take is the following. Note that I've spent most
of my career in startups and small companies, and
usually am the one setting up initial engineering processes:

1. QA and development should never be physically far
from each other - at least in the same building, if not
sitting next to each other. Also, they should report to the
same member of the management team, so there is a
minimum of turf friction between the two groups. The
more "bureaucratic" the interaction, the slower
development and bug fixing will be.

2. QA should be permitted to test the development
codebase as early as possible.

3. The "feature freeze/code freeze" paradigm is what I
always go by.

4. To avoid feature creep, have a strong bias toward
telling your marketing guys with new feature requests
to go away. Trade this off with short release cycles
so their features do get out.

5. Even in the tiniest companies, a very simple, but formal,
release process is a good idea.

My own cycle is basically "Market Requirements", to
"Release <NUM> Spec", to "Schedule", to development and
"soft QA", to "hard QA", to release.

6. Unless there's a compelling business reason to do
otherwise, schedules should be the LAST part of the
pre-development process. Starting with a schedule
(except in the most nebulous form, ie "Q2 2004") before
a feature set is agreed to is asking for trouble.

foobarista
Thursday, December 18, 2003

Context switches take between 15 minutes to an hour. So if the QA takes 2 days, that's just peanuts. The real downer is expecting somebody to work on 10 things in the same day.

However, I'd ship an unofficial build off to the testing, if it was 1 day vs. 3 days.

Even with zero bug methodologies, you probably will have a crunch at the end where alpha/beta test folks really start to use it and hammer on it in ways that you don't on a development version, which exposes new bugs. And interface tweaks now that the product is starting to look done. So you still want some sort of feature freeze, followed by a code freeze.

Flamebait Sr.
Tuesday, December 23, 2003