Ascending and descending representations of quality

Arseni Mourzenko
Founder and lead developer
177
articles
November 6, 2014
Tags: management 34 quality 36 short 50

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:

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?

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.