Deliver first, develop later

No mat­ter which work­flow is cho­sen by a team, there is one com­mon flaw: the prod­uct is shipped only when it’s done.

In this con­text, it is not sur­pris­ing that many prod­ucts fail to be de­liv­ered on time. The de­liv­ery process is both com­pli­cat­ed and ran­dom, like any oth­er process which is not au­to­mat­ed. By post­pon­ing the de­liv­ery un­til the end of the de­vel­op­ment, de­vel­op­ers pass over the risk re­lat­ed to the de­liv­ery process and the time it takes to do it right. In or­der to mit­i­gate the risk of not de­liv­er­ing on time, one should de­liv­er straight from the be­gin­ning, be­fore even start­ing to de­vel­op the prod­uct it­self.

When I work on pro­jects of web ap­pli­ca­tions, I of­ten see cus­tomers giv­ing an ac­cess to the pro­duc­tion serv­er only at the late stages of the de­vel­op­ment. Some­times, it hap­pens like this:

De­vel­op­er: I fin­ished the pro­ject.
Cus­tomer: OK. Can you pub­lish it now on our serv­er, please? I’ll send you the cre­den­tials this evening, and I need the web­site to work flaw­less­ly to­mor­row morn­ing.

Re­cent­ly, I was work­ing on a pro­ject of an ASP.NET MVC 3 web­site. While stag­ing en­vi­ron­ment was miss­ing, I was able to do the first de­liv­ery a few months be­fore fin­ish­ing the pro­ject. The process was smooth, but it still took me one day to:

• Con­fig­ure the serv­er; cre­ate the ap­pro­pri­ate ac­counts, etc. I still don’t un­der­stand why, by de­fault, the host­ing provider tries to do what­ev­er pos­si­ble to make it the least se­cure pos­si­ble, nor why every cus­tomer is con­vinced that us­ing the ad­min­is­tra­tors’ ac­count and giv­ing its pass­word to every­one is the most ex­cit­ing thing in the world.

• In­stall the most re­cent up­dates for the first time. Thanks to Mi­crosoft, this task alone takes a few hours and re­quires con­stant re­boots and hu­man pres­ence. Of course, the host­ing provider (which is by the way the most pop­u­lar one in France) has no idea about snap­shots. I’m won­der­ing if they still in­stall Win­dows Serv­er by hand and nev­er heard about AIK.

• Set­up, con­fig­ure and de­ploy the data­base.

• Con­fig­ure the abil­i­ty to pub­lish the pro­ject from with­in Vi­su­al Stu­dio.

• Try to make it work, giv­en that the pro­ject has a lot of de­pen­den­cies, and that the fresh­ly in­stalled ASP.NET MVC 3 on the serv­er is not the same as the fresh­ly in­stalled ASP.NET MVC 3 on a lo­cal VM. What a pain.

While I spent one day do­ing all this stuff, an ex­pe­ri­enced sys­tem ad­min­is­tra­tor could par­tial­ly au­to­mate all this, but would still waste a few hours.

Once done, the pro­ject should it­self needs to be mod­i­fied. It ap­peared that there were a few bugs with the ap­pli­ca­tion which ex­ist­ed only on the serv­er, but nev­er oc­curred on my own ma­chine. Mov­ing from En­ti­ty Frame­work 4 I have on my ma­chine to EF3 was sur­pris­ing too, since I hit a bug which was solved in the newest ver­sion of EF, but still ex­ist­ed in the pre­vi­ous one. Fi­nal­ly, some mi­nor dis­crep­an­cies were high­ly dis­turb­ing as well, such as the Serv­er Er­ror page sent un­der a form of a bunch of ran­dom sym­bols, prob­a­bly GZip with a wrong Con­tent-En­cod­ing re­sponse head­er.

The is­sue is not ex­clu­sive to Mi­crosoft’s world. Every time I had to pub­lish to a pro­duc­tion serv­er a web­site writ­ten in PHP, I en­coun­tered at least one is­sue due to the con­fig­u­ra­tion be­ing dif­fer­ent or the serv­er us­ing the ver­sion of PHP pub­lished four years ago.

By post­pon­ing the de­liv­ery, you post­pone both the is­sues which will arise dur­ing the de­liv­ery and the work re­quired to con­fig­ure the serv­er. If you’re giv­en the cre­den­tials to the serv­er this evening and the web­site should be run­ning to­mor­row morn­ing, you (or your cus­tomer) should take a course on risk mit­i­ga­tion.

While serv­er en­vi­ron­ment could eas­i­ly be con­trolled and du­pli­cat­ed (in or­der to cre­ate the stag­ing en­vi­ron­ment), the case is dif­fer­ent for desk­top or mo­bile soft­ware prod­ucts. When re­leased in the wild for the first time, those prod­ucts will be con­front­ed to the pletho­ra of op­er­at­ing sys­tems, user’s set­tings, bad con­fig­u­ra­tion, di­verse hard­ware, sand­box­es and en­vi­ron­ments with re­strict­ed per­mis­sions, hacks, virus­es and hu­man stu­pid­i­ty. Ei­ther it’s sol­id and ready to fight, or it’s not.

De­liv­er now

You should and you can de­liv­er im­me­di­ate­ly. All you need is to cre­ate an emp­ty pro­ject or a hel­lo world, ready for de­liv­ery. It will make the cus­tomer hap­py, and it will pre­pare the seam­less de­liv­ery process. Ide­al­ly, you’re us­ing some ag­ile work­flow to de­liv­er on reg­u­lar ba­sis, so that the cus­tomer is up to date on the de­vel­op­ment progress.

Some peo­ple be­lieve that the cus­tomers will ac­cept neg­a­tive­ly such ear­ly de­liv­ery. Non­sense. Every per­son is hap­py to see that her pro­ject is fi­nal­ly start­ed, and that what was pri­ma­ry on pa­per starts to be trans­posed into a live web­site, or a live ap­pli­ca­tion which can be down­loaded, in­stalled, touched. You can see and feel it, and that’s great.

Func­tion­al­i­ty doesn’t mat­ter so much. Fea­tures change all the time dur­ing the de­vel­op­ment of the pro­ject, in all cas­es.

The most ba­sic Hel­lo World for iPhone is much more valu­able com­pared to hun­dreds of pages of pa­per­work de­scrib­ing the ar­chi­tec­ture and the de­sign of the app, or to the promise “We are work­ing on your app in­ter­nal­ly and will de­liv­er soon”. Re­mem­ber that un­til you de­liv­er, all your work is fic­tion for the cus­tomer, who doesn’t even know if you ac­tu­al­ly start­ed the job or are still pro­cras­ti­nat­ing and in­vent­ing some fan­cy rea­sons to now show your work.

This is what is cur­rent­ly done for the Omega pro­ject, since the de­liv­ery was done first, be­fore the first page was im­ple­ment­ed. This al­lows us to show the progress near­ly con­stant­ly, while be­ing sure that there will be no ma­jor is­sues when de­ploy­ing the next re­vi­sion of the ap­pli­ca­tion, and at the same time be en­cour­aged: since there is al­ready some­thing on the serv­er, it means that we are work­ing on a con­crete prod­uct which al­ready ex­ists, not some­thing fic­tion­al which may nev­er reach our pro­duc­tion en­vi­ron­ment.