A bug or a change?

A fea­ture is de­liv­ered to a cus­tomer. The cus­tomer com­plains that some­thing doesn't be­have as ex­pect­ed and cre­ates a tick­et in a bug track­ing sys­tem. Should we clas­si­fy this tick­et as a bug or a change? The ques­tion mat­ters for many soft­ware de­vel­op­ment com­pa­nies. How­ev­er, this is most­ly a dis­tinc­tion with­out a dif­fer­ence.

I of­ten see teams com­plain­ing that the cus­tomer has as­signed as a bug some­thing which should have been a change. They'll start reread­ing—oh, no, sor­ry, I meant read­ing for the first time—the spec, and claim­ing that noth­ing in the spec al­lows one to claim that there is a bug: in­stead, cus­tomer changed his mind, mak­ing it a fea­ture. The cus­tomer will re­spond that one has to be in­sane to be­lieve that the ac­tu­al be­hav­ior could make any sense... This can take hours, some­times days.

In some com­pa­nies, this dis­tinc­tion is par­tic­u­lar­ly im­por­tant in terms of SLAs. If it's a bug, the com­pa­ny will have to pay a fine to the cus­tomer for every hour spent solv­ing the bug. So now, there is a fi­nan­cial in­cen­tive for a cus­tomer to claim that every­thing is a bug, and for a com­pa­ny to claim that noth­ing is, and there is an in­cen­tive for lawyers to spend days draft­ing the con­tract to ex­plain what is a bug and what it isn't. All this time could be used to do things which ac­tu­al­ly mat­ter, such as de­vel­op­ing the prod­uct or un­der­stand­ing the user's needs.

The dis­tinc­tion makes no sense. If you were asked to de­liv­er some­thing to a cus­tomer, and the cus­tomer is not hap­py with the re­sult, there are two pos­si­ble con­se­quences: ei­ther the cus­tomer ac­knowl­edges your skills and your pro­fes­sion­al­ism and sim­ply claims that the de­liv­ered prod­uct doesn't ful­fill the needs well enough, or he con­sid­ers that you're un­pro­fes­sion­al or a sim­ple scam­mer. In the first case, he'll pay ex­tra to change the prod­uct; in the sec­ond case, he'll sue you or sim­ply throw your work away and go look for some­body else to cre­ate the prod­uct.

Ag­ile em­braces this ap­proach quite well. Each it­er­a­tion makes it pos­si­ble for the cus­tomer to read­just the prod­uct: this means both change his mind about the dif­fer­ent as­pects of the prod­uct, and spec­i­fy some as­pects which weren't spec­i­fied well enough or un­der­stood cor­rect­ly by de­vel­op­ers. The changes in both cas­es can ac­tu­al­ly be min­i­mized with pro­to­typ­ing and bet­ter com­mu­ni­ca­tion. Short­er it­er­a­tions help too.

Does it mean that bugs per se don't ex­ist? Of course not, and the dis­tinc­tion that Joel Spol­sky makes in the fifth point of Joel test makes per­fect sense. For those of you who don't re­mem­ber the ex­act for­mu­la­tion, here it is:

5. Do you fix bugs be­fore writ­ing new code?

[...] In gen­er­al, the longer you wait be­fore fix­ing a bug, the cost­lier (in time and mon­ey) it is to fix. [...]

Source: Joel test

It has ab­solute­ly noth­ing to do about the dis­tinc­tion be­tween a bug and a change a cus­tomer may make in a bug track­ing sys­tem af­ter he re­ceives a new fea­ture. In­stead, Joel talks specif­i­cal­ly about is­sues which could have been solved in the ear­ly stages—much be­fore the ac­tu­al de­liv­ery of the fea­ture, and com­pares them to adding new fea­tures. That is a use­ful dis­tinc­tion, which not only makes sense, but is very use­ful: by solv­ing is­sues first, be­fore bloat­ing the prod­uct with new fea­tures, one can de­crease con­sid­er­ably the cost of solv­ing the is­sues in the first place.

Un­for­tu­nate­ly, I've seen some com­pa­nies use Joel test while com­plete­ly mis­un­der­stand­ing it. They would cre­ate a dis­tinc­tion among cus­tomer-opened tick­ets be­tween bugs and changes, and make bugs high­er pri­or­i­ty, or put strict SLAs. And that not only is harm­ful, but could of­ten lead to crazy sit­u­a­tions. Let me il­lus­trate that.

Imag­ine that a cus­tomer re­quest­ed to de­vel­op a fea­ture. By mis­take, he ex­plained a giv­en as­pect of it wrong­ly; since it was writ­ten in the spec and con­firmed by the cus­tomer, there are no doubts on that. Now, the fea­ture was also de­liv­ered with a few mi­nor bugs, most­ly cos­met­ic, but which take at least a whole week to solve: they are un­doubt­ed­ly bugs, since the re­quire­ments clear­ly spec­i­fy how things should have been done. With SLAs, those bugs will have a high­er pri­or­i­ty, in­de­pen­dent­ly of their rel­a­tive ir­rel­e­van­cy for the cus­tomer. No mat­ter how block­ing for the cus­tomer's busi­ness is to have the fea­ture changed as fast as pos­si­ble, de­vel­op­ers will spend a week fix­ing the pseu­do-bugs be­fore start­ing to work on the new, amend­ed re­quire­ments.

In prac­tice, this sit­u­a­tion hap­pens on reg­u­lar ba­sis. When I worked as a pro­ject man­ag­er in one multi­na­tion­al com­pa­ny, it was amaz­ing to see how many sit­u­a­tions there were when the cus­tomer couldn't pri­or­i­tize the tasks prop­er­ly, be­cause of the SLAs the same cus­tomer in­sist­ed to set up. Every­one was un­hap­py, but SLAs re­mained, and was nev­er even ques­tioned, be­cause that's the way it al­ways worked.