Questioning the goal of the project
Recently, a friend of mine approached me with a rewrite of a software product. A small company where she works has a small piece of desktop software written ten years ago in WinDev¹ by an in-house developer left five years ago. The purpose of this product is to make it possible for a person to fill a name and an address of a customer through a form and to print them on an envelope. There is no possibility to store the filled data for later use. Technically, it's just a form, elementary input validation, automatic filling of the postal code from the name of the town—no autocomplete, obviously; and a component which formats the address and prints it to the printer configured as the default one. To get the postal code, the town has to be an exact, case-sensitive match of an element from the list, hardcoded into the source code, given that many towns are misspelled. The postal code couldn't be changed manually through the form.
The software product is getting old and very difficult to use.² Therefore, it was decided to redo it, and since cloud computing buzzword seems particularly attractive, the big boss decided that it should necessarily be web-based (ironically, the app will be hosted in-house). It was also decided to add a few features:
The users would use Windows Authentication (through Active Directory) in order to be able to use the software. Authentication events and some specific actions would be logged (in a log file on the server).
The users should be able to change the list of towns and their corresponding postal codes. Any user can do that, and there is no revert feature.
Auto-completion is nice for the list of towns.
The users could preview the result before printing it.
The printer would be specified by its name/IP number in the configuration. It should be possible to change the name without having to recompile the app.
If something is wrong with the printer (out of ink or out of envelopes), the web app would inform the user about the issue.
A local software development company was asked to produce a quotation for the new system, and they did, estimating it at two man-months and approximately $20 000—that is nineteen thousand dollars more than the small company could afford, not counting the maintenance, a term which, here, means solving numerous bugs. I was asked by my friend to review the quotation and find if there is any way to make the software a bit less expensive.
While I quickly reviewed the quotation and found that it wasn't the most sloppiest one I've seen, it's not the quotation which interested me. I decided instead to ask a few questions about the way the application is currently used.
The first point which interested me was where the addresses come from. It appeared that:
50% are stored in an Excel file in a shared directory. It is used and maintained by two employees. It is changed rarely, and both employees work in the same office, so there was no cases where the changes by one employee were overwritten by another.
The Excel file was using a rather lousy format which made it difficult to parse programmatically to extract the different parts of an address. First and last name, however, were each one in a dedicated column.
40% are noted by hand—by the same two employees—during phone calls or, rarely, from printed mail.
10% are copy-pasted from e-mails.
The second question was the reason why a CRM wasn't used within the company. It appeared that, given the nature of the services, many customers (probably more than 70%) use those services only on occasion (maybe once every three years). Moreover, the Excel file appeared very convenient and fulfills all the actual needs while costing nothing and being simple to use and maintain.
The third question was about the contents of the envelopes, and more precisely how those contents were generated, unless they were hand-written. It appeared that the letter was a Word template, and the employee had only to change a few things, including the name of the person (but not the address). The operation is manual.
This is a good starting point. We have essentially two users who need to print addresses on envelopes, given that those addresses are rarely printed more than one time. The name of the recipient is also duplicated on a letter within the envelope. There is no CRM within the company. The goal of the software product is to save time for those two employees by formatting the addresses properly and printing them; doing the same formatting in, say, Microsoft Word, will be time-consuming and error prone.
Now that the requirements seem clear, let's think about the most effective way to fulfill them. How do we improve efficiency of a person who needs to enter addresses? Right, autocomplete. And the nice thing is that we don't even have to actually implement anything, since Google already did. Displaying the actual position on a map would be nice too, since it could give a hint that the address was mistyped or auto-completed wrongly. Equally through Google APIs, we can get information such as the name of the street, from a specific address, but it won't be able to tell anything about such things as CEDEX. In other words, the workflow should start by an address typed (and auto-completed) freely into a textbox, which will fill the specific fields in a form, then follow by a manual review and edition of the form by the user. This is the most essential feature of the new app, and would take a day or two to be developed. Additional time should be needed to generate API keys, handle those keys to the company and explain why should they be kept private.
Next, a minor feature, the first and last name are grouped in one field. This makes it a bit faster to type, it doesn't matter for an effective delivery if the first name is put before or after the last name, and finally it makes it possible to copy-paste the name into the Word document later.
<div> shown below the form. This will make it possible to review the formatting while modifying the contents of the form. To print, a simple Ctrl+P is used: the CSS of the page is designed in a way that the form and anything not related to printing will be hidden, while the actual address will be shown and positioned accordingly on the page. This part could take a day, including the handling of painful address formatting rules and the fine CSS adjustments and cross-browser compatibility.
As you may have noticed, there is no server-side programming. This means that hosting such website becomes extremely easy. Since the server doesn't need to access the printer, the site can also be hosted outside the company, given that HTTPS would then be required. Setting up a server shouldn't take more than one day.
Now what about Windows Authentication? It appeared that the only goal was to prevent some unauthorized user from using the printer. Since now, users print stuff themselves, their activity is logged by the printer anyway, which fulfills the logging requirement.
Two-man months become four man-days, given that instead of a heavy and difficult to maintain web application relying on server-side code, we now have a simple static web page. Instead of an app which has dubious benefits in terms of actually saving time to the users, we have an app which does a great job at helping the users to perform their job fast.
This is a good illustration where focusing straight on a given issue without considering the context could lead to a waste of time and money and, not less importantly, to poorly designed products which don't bring much benefit to their users. Unfortunately, many software development companies use the model of doing exactly what customer asks, and many customers expect those companies to do what is asked, without questioning the goal. This is one of the reasons Agile methodologies, with their frequent communication with the users or their representatives, is so effective.