Ascending and descending representations of quality

There are many pro­jects which start with very low ex­pec­ta­tions of the qual­i­ty of the source code and pro­ject or­ga­ni­za­tion. The idea is to get some­thing which sim­ply works, start to sell it, and then, ei­ther con­tin­u­ous­ly or in one bru­tal step, refac­tor the code to achieve bet­ter qual­i­ty and re­or­ga­nize what should be re­or­ga­nized at pro­ject lev­el. In prac­tice, this doesn't re­al­ly work like this.

Code bases tend to de­grade over time. It ap­plies to a code base of a prod­uct writ­ten by a team of in­ex­pe­ri­enced pro­gram­mers who don't care about the prod­uct; it ap­plies as well to a code base main­tained by ex­pe­ri­enced team work­ing in Ag­ile en­vi­ron­ment in a con­text where strict stan­dards are re­quired and en­forced near­ly in real time. What dif­fer­en­ti­ates those two ex­am­ples is that in the first one, the qual­i­ty, be­ing al­ready much low­er at the be­gin­ning, will de­grade much faster.

There are mul­ti­ple fac­tors which ac­cel­er­ate or slow down the de­cay. Some, such as cod­ing stan­dards en­forced at com­mit, or such as re­gres­sion test­ing, help at slow­ing down the de­cay con­tin­u­ous­ly. Oth­ers, such as code re­views or refac­tor­ing in­crease the qual­i­ty at a pre­cise mo­ment of time, giv­ing some mar­gin for the fur­ther degra­da­tion.

Im­prov­ing an al­ready bad pro­ject is ex­treme­ly com­pli­cate.

First­ly, the re­sis­tance against change may come from sev­er­al places:

• De­vel­op­ers them­selves. Chang­ing any habit, good or bad, is hard. When you're ac­cus­tomed at see­ing a pro­ject as some­thing which doesn't de­serve care, much should be done to con­vince you that from this mo­ment on, the qual­i­ty is the first pri­or­i­ty of the pro­ject.

• Busi­ness peo­ple. A team re­leased a prod­uct. It works, and it brings mon­ey to the com­pa­ny. Would it be more in­ter­est­ing to work on new ex­cit­ing fea­tures, or to spend months rewrit­ing what al­ready works?

• Cus­tomers. They want the prod­uct to work cor­rect­ly. They want new fea­tures. They don't care about code cov­er­age or about Con­tin­u­ous in­te­gra­tion, nor they care about the price it costs to the com­pa­ny to fix some­thing which was orig­i­nal­ly built bro­ken.

Sec­ond­ly, in­tro­duct­ing means in­tend­ed to lead to high­er qual­i­ty in the mid­dle of the pro­ject may be painful. At Pel­i­can De­sign & De­vel­op­ment, it is im­pos­si­ble to com­mit Python code which is not PEP 8 com­pli­ant. When do­ing ex­ten­sive changes, it is not un­usu­al to see five - ten er­rors dur­ing com­mit. It hurts, es­pe­cial­ly when the com­mit is done late at night and all you want is to go to bed. While it hurts, it's still rel­a­tive­ly easy to cor­rect even ten er­rors, most be­ing sim­ply re­lat­ed to iden­ta­tion white­space in emp­ty lines. By com­par­i­son, I have a pro­ject I've writ­ten in C# four years ago. When work­ing on it, I was un­aware about Style­Cop. To­day, do­ing Style­Cop scan stops at 1 000 warn­ings: that's the lim­it used by de­fault. Com­ming back now and fix­ing all those cod­ing stan­dard er­rors would be not only time con­sum­ing, but also risky: such mo­not­o­nous work eas­i­ly leads to hu­man er­rors, and hav­ing to solve new­ly in­tro­duced bugs on a lega­cy pro­ject is out of ques­tion.

Imag­ine one in­tro­duces cod­ing stan­dards in the mid­dle of the pro­ject. Are they en­forced at com­mit?

• If yes, this leads to a se­ri­ous prob­lem. With thou­sands and thou­sands of er­rors, the team should stop work­ing, and spend days solv­ing those er­rors. Then days solv­ing the new­ly in­tro­duced er­rors.

• If no, no­body would care. There is a rule: any­thing which de­mands an ef­fort and which is nei­ther mea­sured, nor en­forced, won't be done. No­body cares about tabs vs. spaces, un­less you can't com­mit a piece of source code which uses tabs. No­body cares about in­den­ta­tion, un­less the IDE deals au­to­mat­i­cal­ly with it. And no­body cares about com­ments, un­less code which is not com­ment­ed enough is re­ject­ed dur­ing code re­view.

  About that, I re­cent­ly had a case where there was an SQL script which con­tained some data to in­sert. This SQL script was used by a Pow­er­Shell script dur­ing de­ploy­ment. It was es­sen­tial to keep it read­able, and align­ing val­ues to form some sort of vi­su­al columns im­proved read­abil­i­ty greate­ly. The aligne­ment was done with spaces, but giv­en that the file was mod­i­fied by sev­er­al per­sons us­ing dif­fer­ent ed­i­tors, tabs quick­ly ap­peared, cre­at­ing a mess.

  There was one ef­fec­tive way to pre­vent tabs. I added a con­trol in Pow­er­Shell script which, if tabs were found, stopped and alert­ed the user that there is a tab on a giv­en line. The first days, there were ques­tions such as:

  — The Pow­er­Shell script doesn't work!
  — What's the prob­lem with it?
  — It shows an er­ror.
  — Which er­ror?
  — That there is a... wait, I think I can fix it my­self.

Then, the prob­lem dis­ap­peared for­ev­er, and every­thing in the SQL script was al­ways aligned per­fect­ly well since then.

Con­clu­sion: start with the high­est pos­si­ble ex­pec­ta­tions; if you don't do it right now, you won't do it lat­er. Then, stick with them as long as pos­si­ble, us­ing au­to­mat­ed en­force­ment when pos­si­ble.