Questioning the goal of the project

Re­cent­ly, a friend of mine ap­proached me with a rewrite of a soft­ware prod­uct. A small com­pa­ny where she works has a small piece of desk­top soft­ware writ­ten ten years ago in WinDe­v¹ by an in-house de­vel­op­er left five years ago. The pur­pose of this prod­uct is to make it pos­si­ble for a per­son to fill a name and an ad­dress of a cus­tomer through a form and to print them on an en­ve­lope. There is no pos­si­bil­i­ty to store the filled data for lat­er use. Tech­ni­cal­ly, it's just a form, el­e­men­tary in­put val­i­da­tion, au­to­mat­ic fill­ing of the postal code from the name of the town—no au­to­com­plete, ob­vi­ous­ly; and a com­po­nent which for­mats the ad­dress and prints it to the print­er con­fig­ured as the de­fault one. To get the postal code, the town has to be an ex­act, case-sen­si­tive match of an el­e­ment from the list, hard­cod­ed into the source code, giv­en that many towns are mis­spelled. The postal code couldn't be changed man­u­al­ly through the form.

The soft­ware prod­uct is get­ting old and very dif­fi­cult to use.² There­fore, it was de­cid­ed to redo it, and since cloud com­put­ing buzz­word seems par­tic­u­lar­ly at­trac­tive, the big boss de­cid­ed that it should nec­es­sar­i­ly be web-based (iron­i­cal­ly, the app will be host­ed in-house). It was also de­cid­ed to add a few fea­tures:

• The users would use Win­dows Au­then­ti­ca­tion (through Ac­tive Di­rec­to­ry) in or­der to be able to use the soft­ware. Au­then­ti­ca­tion events and some spe­cif­ic ac­tions would be logged (in a log file on the serv­er).

• The users should be able to change the list of towns and their cor­re­spond­ing postal codes. Any user can do that, and there is no re­vert fea­ture.

• Auto-com­ple­tion is nice for the list of towns.

• The users could pre­view the re­sult be­fore print­ing it.

• The print­er would be spec­i­fied by its name/IP num­ber in the con­fig­u­ra­tion. It should be pos­si­ble to change the name with­out hav­ing to re­com­pile the app.

• If some­thing is wrong with the print­er (out of ink or out of en­velopes), the web app would in­form the user about the is­sue.

A lo­cal soft­ware de­vel­op­ment com­pa­ny was asked to pro­duce a quo­ta­tion for the new sys­tem, and they did, es­ti­mat­ing it at two man-months and ap­prox­i­mate­ly $20 000—that is nine­teen thou­sand dol­lars more than the small com­pa­ny could af­ford, not count­ing the main­te­nance, a term which, here, means solv­ing nu­mer­ous bugs. I was asked by my friend to re­view the quo­ta­tion and find if there is any way to make the soft­ware a bit less ex­pen­sive.

While I quick­ly re­viewed the quo­ta­tion and found that it wasn't the most slop­pi­est one I've seen, it's not the quo­ta­tion which in­ter­est­ed me. I de­cid­ed in­stead to ask a few ques­tions about the way the ap­pli­ca­tion is cur­rent­ly used.

The first point which in­ter­est­ed me was where the ad­dress­es come from. It ap­peared that:

• 50% are stored in an Ex­cel file in a shared di­rec­to­ry. It is used and main­tained by two em­ploy­ees. It is changed rarely, and both em­ploy­ees work in the same of­fice, so there was no cas­es where the changes by one em­ploy­ee were over­writ­ten by an­oth­er.

  The Ex­cel file was us­ing a rather lousy for­mat which made it dif­fi­cult to parse pro­gram­mat­i­cal­ly to ex­tract the dif­fer­ent parts of an ad­dress. First and last name, how­ev­er, were each one in a ded­i­cat­ed col­umn.

• 40% are not­ed by hand—by the same two em­ploy­ees—dur­ing phone calls or, rarely, from print­ed mail.

• 10% are copy-past­ed from e-mails.

The sec­ond ques­tion was the rea­son why a CRM wasn't used with­in the com­pa­ny. It ap­peared that, giv­en the na­ture of the ser­vices, many cus­tomers (prob­a­bly more than 70%) use those ser­vices only on oc­ca­sion (maybe once every three years). More­over, the Ex­cel file ap­peared very con­ve­nient and ful­fills all the ac­tu­al needs while cost­ing noth­ing and be­ing sim­ple to use and main­tain.

The third ques­tion was about the con­tents of the en­velopes, and more pre­cise­ly how those con­tents were gen­er­at­ed, un­less they were hand-writ­ten. It ap­peared that the let­ter was a Word tem­plate, and the em­ploy­ee had only to change a few things, in­clud­ing the name of the per­son (but not the ad­dress). The op­er­a­tion is man­u­al.

This is a good start­ing point. We have es­sen­tial­ly two users who need to print ad­dress­es on en­velopes, giv­en that those ad­dress­es are rarely print­ed more than one time. The name of the re­cip­i­ent is also du­pli­cat­ed on a let­ter with­in the en­ve­lope. There is no CRM with­in the com­pa­ny. The goal of the soft­ware prod­uct is to save time for those two em­ploy­ees by for­mat­ting the ad­dress­es prop­er­ly and print­ing them; do­ing the same for­mat­ting in, say, Mi­crosoft Word, will be time-con­sum­ing and er­ror prone.

Now that the re­quire­ments seem clear, let's think about the most ef­fec­tive way to ful­fill them. How do we im­prove ef­fi­cien­cy of a per­son who needs to en­ter ad­dress­es? Right, au­to­com­plete. And the nice thing is that we don't even have to ac­tu­al­ly im­ple­ment any­thing, since Google al­ready did. Dis­play­ing the ac­tu­al po­si­tion on a map would be nice too, since it could give a hint that the ad­dress was mistyped or auto-com­plet­ed wrong­ly. Equal­ly through Google APIs, we can get in­for­ma­tion such as the name of the street, from a spe­cif­ic ad­dress, but it won't be able to tell any­thing about such things as CEDEX. In oth­er words, the work­flow should start by an ad­dress typed (and auto-com­plet­ed) freely into a textbox, which will fill the spe­cif­ic fields in a form, then fol­low by a man­u­al re­view and edi­tion of the form by the user. This is the most es­sen­tial fea­ture of the new app, and would take a day or two to be de­vel­oped. Ad­di­tion­al time should be need­ed to gen­er­ate API keys, han­dle those keys to the com­pa­ny and ex­plain why should they be kept pri­vate.

Next, a mi­nor fea­ture, the first and last name are grouped in one field. This makes it a bit faster to type, it doesn't mat­ter for an ef­fec­tive de­liv­ery if the first name is put be­fore or af­ter the last name, and fi­nal­ly it makes it pos­si­ble to copy-paste the name into the Word doc­u­ment lat­er.

A sec­ond es­sen­tial part is the pre­view and the print­ing it­self. In­stead of let­ting the print­er do the job and giv­en that user's ma­chines are on the same net­work as the serv­er and the print­er, I sug­gest­ed to let the users print stuff them­selves. Tech­ni­cal­ly, a piece of JavaScript code would for­mat the ad­dress ac­cord­ing to the spe­cif­ic rules and put it into a <div> shown be­low the form. This will make it pos­si­ble to re­view the for­mat­ting while mod­i­fy­ing the con­tents of the form. To print, a sim­ple Ctrl+P is used: the CSS of the page is de­signed in a way that the form and any­thing not re­lat­ed to print­ing will be hid­den, while the ac­tu­al ad­dress will be shown and po­si­tioned ac­cord­ing­ly on the page. This part could take a day, in­clud­ing the han­dling of painful ad­dress for­mat­ting rules and the fine CSS ad­just­ments and cross-brows­er com­pat­i­bil­i­ty.

As you may have no­ticed, there is no serv­er-side pro­gram­ming. This means that host­ing such web­site be­comes ex­treme­ly easy. Since the serv­er doesn't need to ac­cess the print­er, the site can also be host­ed out­side the com­pa­ny, giv­en that HTTPS would then be re­quired. Set­ting up a serv­er shouldn't take more than one day.

Now what about Win­dows Au­then­ti­ca­tion? It ap­peared that the only goal was to pre­vent some unau­tho­rized user from us­ing the print­er. Since now, users print stuff them­selves, their ac­tiv­i­ty is logged by the print­er any­way, which ful­fills the log­ging re­quire­ment.

Two-man months be­come four man-days, giv­en that in­stead of a heavy and dif­fi­cult to main­tain web ap­pli­ca­tion re­ly­ing on serv­er-side code, we now have a sim­ple sta­t­ic web page. In­stead of an app which has du­bi­ous ben­e­fits in terms of ac­tu­al­ly sav­ing time to the users, we have an app which does a great job at help­ing the users to per­form their job fast.

This is a good il­lus­tra­tion where fo­cus­ing straight on a giv­en is­sue with­out con­sid­er­ing the con­text could lead to a waste of time and mon­ey and, not less im­por­tant­ly, to poor­ly de­signed prod­ucts which don't bring much ben­e­fit to their users. Un­for­tu­nate­ly, many soft­ware de­vel­op­ment com­pa­nies use the mod­el of do­ing ex­act­ly what cus­tomer asks, and many cus­tomers ex­pect those com­pa­nies to do what is asked, with­out ques­tion­ing the goal. This is one of the rea­sons Ag­ile method­olo­gies, with their fre­quent com­mu­ni­ca­tion with the users or their rep­re­sen­ta­tives, is so ef­fec­tive.

¹ For the lucky of you who don't know what it is, WinDev is a French de­vel­op­ment ecosys­tem—by the lack of bet­ter term—which claims to make you de­vel­op ten times faster, con­ve­nient­ly ig­nor­ing some­thing Fred Brooks wrote on the sub­ject.

² I've seen screen­shots, and was sur­prised how one could screw up an in­ter­face of a such sim­ple piece of soft­ware! For in­stance, at the bot­tom of the ad­dress form, there are three but­tons: “Can­cel,” “Erase” and “Print”; no­body knows the pur­pose, and more im­por­tant­ly the dif­fer­ence be­tween the two first but­tons.