Don't ask writing good code

Arseni Mourzenko
Founder and lead developer
November 6, 2014
Tags: management 33 quality 35 short 50

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.

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.