Don't ask writing good code

What a sur­prise. Af­ter be­ing asked for months to sim­ply write code as fast as pos­si­ble, with no think­ing or test­ing, man­age­ment sud­den­ly crit­i­cized one of the col­leagues, be­cause the code of a new, un­sta­ble fea­ture im­ple­ment­ed to­day con­tains long (more than 50 LOC) meth­ods, sug­gest­ing to write short­er meth­ods in fu­ture.

At first sight, it's a good sign. What would be bet­ter than to en­cour­age the team to im­prove their code qual­i­ty? But af­ter a thought, it may be not so ob­vi­ous. Def­i­nite­ly, man­age­ment is wrong, and by wrong, I mean plain­ly, to­tal­ly wrong; no reser­va­tions.

First­ly, you don't start writ­ing good code over thou­sands and thou­sands of lines of bad code. It's sim­ply not work­ing this way. Not only be­cause the nat­ur­al evo­lu­tion is con­tin­u­ous de­cay, not im­prove­ment, but also be­cause pro­ject cul­ture is forged through time, and can­not be changed im­me­di­ate­ly at will. Pro­ject cul­ture—an ob­vi­ous­ly un­clear term—deal with the at­ti­tude of the team to­wards code, to­wards their col­leagues or to­wards man­age­ment, the pro­ject val­ues, the ex­pec­ta­tions, the in­ter­est, etc. Pro­ject cul­ture may change over time un­der the in­flu­ence of a per­son, but can­not sim­ply be thrown away. If man­age­ment told de­vel­op­ers that style doesn't mat­ter (why would man­age­ment care about such things is a dif­fer­ent ques­tion), and one day would de­cide to en­force a sin­gle style, chances are con­cerned peo­ple won't wel­come the de­ci­sion, or the sud­den way it is done.

Sec­ond­ly, con­text mat­ters. Not all code is the same. In the case I de­scribe, ask­ing to write qual­i­ty code makes no sense what­so­ev­er, be­cause the code con­cerns a new, un­sta­ble fea­ture be­ing im­ple­ment­ed right now: this is not pro­duc­tion code, this is a pro­to­type. The fact that source code for a pro­to­type finds its way in the code base in­di­cates a deep mis­un­der­stand­ing with­in the man­age­ment peo­ple. This of­ten leads to the “per­ma­nent pro­to­type” syn­drome I dis­cussed ear­li­er.

It's not sur­pris­ing that de­vel­op­ers are un­will­ing to put an ef­fort in pol­ish­ing code which will live for a few hours or most­ly days, and then be re­placed by some­thing else. Then, when the code ends it­self in code base in or­der to re­main there for years, there is no fron­tier be­tween pro­to­type code and pro­duc­tion code to en­cour­age de­vel­op­ers to start refac­tor­ing.

Third­ly, if de­vel­op­ers are writ­ing bad code, it means that some­thing goes wrong at a larg­er scale with­in the com­pa­ny. Sim­ply telling de­vel­op­ers they should write good code from now doesn't solve the root cause, so in­stead, one should search the ori­gin of the prob­lem.

• Is qual­i­ty val­ued with­in the pro­ject? If de­vel­op­ers are asked to ship fea­tures as fast as pos­si­ble, only a fool would be sur­prised to see low work qual­i­ty.

• Are there prop­er mea­sures to en­cour­age good code qual­i­ty? This may in­clude pos­i­tive re­in­force­ment, au­to­mat­ed check­ing such as PEP 8 com­pli­ance checks on com­mit, etc.

• Do the de­vel­op­ers have prop­er tools? Can they eas­i­ly mea­sure main­te­nance in­dex or spot, through sta­t­ic analy­sis, the prob­lem­at­ic parts?

• Is code re­view reg­u­lar enough? Is it done in a way peo­ple con­sid­er­ing it as a mean to im­prove their code, or do they take it per­son­al­ly?

• Is ret­ro­spec­tion em­pha­siz­ing enough on code qual­i­ty? Are the pro­pos­als giv­en dur­ing ret­ro­spec­tion fol­lowed?

• Is team com­mu­ni­ca­tion es­tab­lished cor­rect­ly? Are de­vel­op­ers dis­cussing code qual­i­ty, con­struc­tive­ly crit­i­ciz­ing oth­ers and ac­cept­ing cri­tique from oth­ers? Are they hi­er­ar­chi­cal­ly equal enough? Do they have time talk­ing about code qual­i­ty?

• Are de­vel­op­ers skill­ful enough? If not, the hir­ing process may be bro­ken (and it usu­al­ly is). Or maybe de­vel­op­ers are hired cor­rect­ly, but are rapid­ly los­ing their skills when work­ing in the com­pa­ny? Are they trained enough?

When code base starts to rot, search for the root cause. Sim­ply de­cid­ing that de­vel­op­ers will write bet­ter code won't help. By clear­ly sep­a­rat­ing pro­duc­tion code from pro­to­type code and by find­ing and solv­ing the root prob­lem, one can in­deed in­flu­ence pro­ject cul­ture and start to see the im­prove­ment in the qual­i­ty of the code base.