An old school friend of mine recently approached me asking for some programming help on an institutional project he was working on. After a few e-mails, I had to come to terms with the fact that I could not help him with the thing he wanted the most - someone to program a web interface front-end to a database he created.
Well, specifically it's not that I couldn't help, just that I have a thing about promising stuff I am not sure I can deliver. The old newspaper editing adage: "when in doubt, leave it out" applies to the list of things you can or cannot do to satisfy requests from potential customers. In other words, if someone asks you to do something, and you are not fully confident you can do it, don't agree to doing it.
This is different if you are writing code for your own project. You would obviously attempt to use unfamiliar technologies, take a lot of risks, do a lot of hacking because you could forgive yourself for failure. Promises to yourself can be broken without consequence.
But when pressed by a customer: "can you do this for me?" and "Not sure, but I can try" (aka "maybe") is not a firm enough ("yes" or "no" type) answer, then you must say "no." The reason is due to the potential for failure, and the possibility of having to deal with the accusation that you promised something you could not deliver.
That being said, another issue crops up, and it's about who manages the process of development. If the customer is in the driver's seat about what he wants, that's fine, as long as he understands and accepts some basic prerequisites of development. The stakeholder can sometimes be the primary domain expert, but not a development expert. If this is the case, he must be educated on the basics before anything is agreed-to.
The basics? Software is a planned, deliberate thing. You intend to produce something. You develop plans. You write code, test against the plans and deploy. There is no ambiguity. The intent is to build a deployable, functioning item that people can use.
Developing software among two or more consenting adults is an act of intent, one has no choice but to consider the state of the deployed article at the time of conception. If you want people to like what you do, you have to plan for it.
This means, before any code is written:
a.) The developer must understand the conceptual domain of the customer.
b.) the developer must build a Requirements Document with the customer.
c.) The developer must build a detailed Functional Specification describing the behavior of all parts of the product.
Even if no code ever gets written, and the project is called off at this point, at least you did not waste money building something you never wanted or were never able to build in the first place.
Even if the current developer is not the person who will ultimately write the code, at least you have working plans to hand to the next developer, which is a huge advantage.
Even if your plans change, you only have to change documents, and will not have to change code too.
If the customer can agree to these things, then the project can move forward. If not, or if the customer waffles, the project cannot move forward.
For example, the first thing a customer might do is trivialize the work needed to complete the project: "All I want is something that just does this or that". If the project is sufficiently trivialized, there would be no need to waste time with engineering pre-requisites, such as planning, management, documentation and expense. Code could just be "whipped-up" without a care.
Often times, this comes in the form of a half-baked request for a complete, but easy-to-make product - a kind of mythical animal that is half-lion, half-mouse. Often the request can be described in terms of contradiction: that of a "working prototype", which doesn't exist in the software business.
Prototypes are to programs as mannequins are to robots. Prototypes are not real programs. They may resemble programs, but are only designed to emulate or "fake" some kind of behavior of the real thing. Prototypes are for display purposes only. Prototypes never get retro-fitted with code and developed into functioning, deployed software.
In the software world, the difference between developing a prototype and a developing working product is one of intent. You either intend to develop a prototype or you intend to develop a software product.
Often, people who do not know what they are doing will attempt to save money by canoodling developers into building a "working prototype", promising it will only be used for the purpose of proof-of-concept. Then, at a later date, they decide to renege on that promise, and treat the prototype as a working product, telling developers to "tweak it" for production.
This leads to disaster. Economic loss, credibility loss and a lot of wasted time. This is the Working Prototype Trap. It looks like a good idea, and with a few misconceived plans, it becomes a real nightmare.
The problem is, some customers don't know that we just don't want to go there. They need to be educated, and have their expectations controlled.
This is not to say that there isn't someone out there who has the talent, experience and enterprise to "whip-up" a quick website that satisfies all the requirements. In fact, if the project is small enough and the expertise of the implementer is great enough, and the knowledge of the domain space is easy enough to acquire, it can be done. It's just a question of locating the right person.
But often this person cannot be easily recruited, and he or she must be able to take the project to the next level since no documentation exists to support other less optimal participants.
No comments:
Post a Comment