Permanent prototype

Arseni Mourzenko
Founder and lead developer
November 6, 2014
Tags: management 34

Each pro­ject fol­lows more or less one of the fol­low­ing mod­els, some­times sev­er­al of them com­bined:

The first two ones are well-known.

The first one is the clas­si­cal Wa­ter­fall mod­el. Pri­or to de­vel­op­ment, the pro­ject is de­signed in every pos­si­ble de­tail, so that we have both an over­all view and a de­tailed view of the work to do. Suit­ed for en­vi­ron­ment where for­mal­ism is re­quired, it is also of­ten used by mis­take in pro­jects where no­body knows quite well what the pro­ject is about.

The sec­ond one is the also clas­si­cal Ag­ile. Pro­jects are con­struct­ed through fre­quent (at most a few weeks on a pro­ject with the over­all du­ra­tion of at least a few months) it­er­a­tions, al­low­ing some nice things like ret­ro­spec­tion and ad­just­ment of the process.

That's the bor­ing stuff. The in­ter­est­ing stuff is the last mod­el: per­ma­nent pro­to­type. This one is prac­ti­cal­ly not cov­ered by the lit­er­a­ture, while it helps de­scrib­ing many of the pro­jects built by IT in­dus­try. Of­ten, pro­jects don't have pri­or de­sign, and they are not it­er­a­tive in any way, so the oth­er mod­els can't be ap­plied. The lifes­pan of those pro­jects can be de­scribed like this:

  1. There is an idea. It's not de­scribed, nor un­der­stood by its own­er; nev­er­the­less, it can serve as a start­ing point for a pro­ject.

  2. Some peo­ple work on the task of de­scrib­ing the pro­ject. Since they don't have a good overview of the pro­ject and since no­body knows what it would look like, this de­scrip­tion is not ex­treme­ly use­ful or ex­act, but still can serve to ex­plain the con­cept.

  3. The team is cre­at­ed and starts pro­gram­ming im­me­di­ate­ly. A set of el­e­ments (see be­low) force the qual­i­ty to be par­tic­u­lar­ly low, and this qual­i­ty lev­el is ac­cept­ed by the team who be­lieves that it will be im­proved lat­er in the life­cy­cle.

  4. The pro­ject is con­stant­ly mod­i­fied, in­creas­ing the mess in the ab­sence of Ag­ile.

  5. It is fi­nal­ly can­celled, or maybe re­leased in the wild while be­ing bro­ken.

  6. If re­leased, the pro­ject is then main­tained, year af­ter year, by pro­gram­mers who scream and cry while look­ing at the source. At least, it's a good source for TheDai­lyWTF sto­ries.

There are sev­er­al fac­tors that make low qual­i­ty ac­cept­able at step 3. Time pres­sure is cou­pled with the log­ic “We can make it bet­ter lat­er” and “Sim­ply make this work”. The wrong log­ic I was talk­ing about re­cent­ly that stan­dards can be ap­plied to an ex­is­tent pro­ject is here too. Fi­nal­ly, the il­lu­sion of or­ga­ni­za­tion has its in­flu­ence too: since it is be­lieved that there is some­one, some­where, who have thought about the pro­ject and knows what it will look like in every of its as­pects makes it dif­fi­cult to refuse to go non-Ag­ile.

Such pro­ject is noth­ing oth­er than a pro­to­type: we should re­lease it fast to see some stuff work­ing, and we don't care about qual­i­ty. In a case of a pro­to­type, every­thing is clear: the only thing that mat­ters is func­tion­al­i­ty; qual­i­ty doesn't and shouldn't mat­ter, be­cause it's not the point of a pro­to­type. The point is that a short pro­to­type (or a bunch of pro­to­types) should be fol­lowed by a real pro­ject, with no code reuse. Sim­ply tweak­ing the source of a pro­to­type doesn't mag­i­cal­ly make it a prod­uct.

What's wrong with pro­jects which can be mod­eled as per­ma­nent pro­to­type is the mis­un­der­stand­ing, the lack of com­mu­ni­ca­tion be­tween the stake­hold­ers and the team. It should be clear to the stake­hold­ers that what is ac­tu­al­ly built right now is only a pro­to­type, not a fi­nal prod­uct. Be­ing a pro­to­type, it doesn't cre­ate tech­ni­cal debt; in oth­er words, be­ing low qual­i­ty is not a flaw, but a ben­e­fit: in­stead of putting ac­cent on point­less—in this con­text—el­e­ments such as read­abil­i­ty of code, the team can put all the ef­fort in go­ing from noth­ing to wow in a tiny amount of time. Where mis­un­der­stand­ing be­comes clear is at the mo­ment where stake­hold­ers tell that the pro­to­type which was built will now be used in pro­duc­tion, as well as main­tained. At this very point, tech­ni­cal debt grows from zero to ex­treme—some­thing which is of­ten omit­ted by stake­hold­ers, and not ex­plained to them by IT peo­ple.

To es­cape per­ma­nent pro­to­type mod­el, there are two so­lu­tions:

Let's take an ex­am­ple of a pro­ject which has two parts: one is pret­ty clear, and an­oth­er one, the es­sen­tial one, is high­ly un­pre­dictable.

  1. Start by cre­at­ing a pro­to­type for the un­pre­dictable part. While not know­ing on which plat­form the fi­nal prod­uct will be host­ed, let's pick C# for the pro­to­type. This will guar­an­tee that we'll throw all the code when mov­ing to a pro­gram­ming lan­guage which has en­ter­prise-lev­el sup­port on Lin­ux servers.

  2. The pro­to­type turns well, but there are also a few points which are not clear in the sec­ond part of the pro­ject. Let's cre­ate a few pro­to­types for those dark spots too.

  3. Af­ter writ­ing the pro­to­types for this sec­ond part, it ap­pears that we got the first part wrong. Let's redo the orig­i­nal pro­to­type un­til it match­es our new vi­sion. Note that the stake­hold­ers are con­stant­ly in­volved and giv­ing their feed­back, which helps in get­ting pro­to­types right. The stake­hold­ers know what pro­to­type is, so they pro­vide feed­back only on the over­all con­cept, not the dif­fer­ent bugs they may en­counter.

  4. Now that we have a clear over­all vi­sion of the pro­ject, we can start the pro­ject it­self. We won't look at source code of the pro­to­types, but we de­fin­i­tive­ly will reuse the con­cepts and ideas they demon­strate.

  5. The pro­ject it­self is be­ing built and uses short it­er­a­tions with con­stant feed­back from the stake­hold­ers.

  6. At some point, stake­hold­ers no­tice that there is a huge prob­lem, un­fore­seen un­til now. It's now time to cre­ate an ad­di­tion­al pro­to­type. It al­lows go­ing very fast, while keep­ing the code base clean and avoid­ing tech­ni­cal debt growth.

  7. The pro­to­type ap­pears to rep­re­sent suc­cess­ful­ly the new vi­sion of stake­hold­ers. The code base is pro­gres­sive­ly and care­ful­ly refac­tored to fit the new vi­sion. The stake­hold­ers are con­stant­ly in­volved and have a clear view of cur­rent progress.

  8. While do­ing refac­tor­ing, busi­ness­peo­ple de­cide to hold the pro­ject, be­cause IT per­son­nel is need­ed for a more im­por­tant one. It's not a prob­lem, since the pro­ject is up and run­ning and the last ver­sion cre­at­ed a hour ago through con­tin­u­ous de­liv­ery works cor­rect­ly.

  9. Six months lat­er, the pro­ject is re­sumed. Since the tech­ni­cal debt is low, the new team can start work­ing ASAP on the pro­ject, with­out fear­ing to break stuff.