Web developers are a tough lot, willing to brave constantly changing technologies, competing “standards,” and tools that are often clumsy and dull. Yet brave as we are, two little words strike fear in the hearts of even the boldest of us, making us consider a change to a less stressful job-air traffic control, perhaps.
Scope creep threatens to undermine all our hard work, causing rewrite after rewrite of carefully crafted markup and code. In short, scope creep is evil. That’s the prevailing wisdom. But consider the results of four studies done over the last five years that show that as little as 20% of corporate software projects are successful. Prevailing, it may be, but is it wisdom?
Maybe what we need is a little heresy. Try this: scope creep is not only inevitable; it’s natural. As with other natural forces, when we resist it, it seems evil to us. It thwarts us, but scope creep is no more evil than gravity. Scope creep is the pejorative name we give to the natural process by which clients discover what they really want.
This puts our attempts at “requirements gathering” in a different light. Most project managers try their best to discover what clients want at the beginning of the project. They use meetings, questionnaires, personal interviews – and still, the most common experience for developers delivering a final product is customer dissatisfaction. It may come as a slap in the face – “this is no good” – or it may be couched in gentler terms – “you know what would be nice” – but the same message is being delivered: we aren’t giving clients what they want.
Maybe that’s natural, too – that failure to give clients what they want, a natural consequence of our failed conventional wisdom. So, let’s augment our heresy with a new claim: clients can’t tell us what they want until they see it. That’s why they don’t tell us what they want up front. They can’t! And if they could, would they really need us?
Are you starting to feel slightly more kindly towards those fumbling clients who can’t put their finger on what they want, although they can tell us quite nicely what they don’t like? These are the people who pay us to do what we love. And they need us. They need us to guide them from the foggy swamps of possibilities to the land of promise.
Hmm…if clients aren’t to blame for the sorry state of software, that puts the blame uncomfortably close to…us. What’s wrong with the current picture is that as developers, we aren’t taking responsibility for successful software deployments. I’m convinced that this is not due to any apathy on our part, but rather a misunderstanding of our role. We are central to software development, no matter what clients think or our pointy-haired bosses say. We must create the system that reliably, predictably turns out software successes.
What system would that be? First, we need to recognize the inevitability – and even the desirability – of scope creep. Now, we must provide a safe environment for scope creep to occur in. A few simple tools can go a long way in providing an answer.
A “wireframe” is a simple, text-only skeletal version of the application. It is used as a sort of “booster rocket” to help us escape the leaden weight of our own assumptions about what clients want. Something magical happens when a client can click on a link. It stimulates their interest and engages their brain. Wireframes that do nothing but tell the client what this page will contain and has links to other pages is ridiculously effective, but wireframes can take lots of time to write and edit.
In the ColdFusion community, a “wireframe tool” is available for free download that takes simple text files that non-programmers can easily write and turns them into clickable wireframes. Setup is extremely simple, requiring only that you have ColdFusion Server running on a machine. There is also a PHP version of the tool freely available. The tool can be downloaded from www.bjork.net.
When I initially wrote the code for the wireframe tool, I only wanted it to help in the discovery phase of a project, but many have found that it is very effective as a sales tool. Because wireframes are fast and easy to create, they can be done in front of a customer. From our point of view, we’re taking the first step in discovering what the client wants; from the client’s point of view, we’re writing the application in front of them! If you do this with a prospect, you will definitely set yourself apart from your competition.
Wireframes, helpful as they are, can only get us so far. Clients have to see the application in all its detail – and that means prototyping. Another tool (also free) can help us with this. The tool, called DevNotes, adds a simple, threaded messaging component to every prototype page. Using DevNotes, clients and developers can communicate with each other during the prototyping phase. Notes are saved into a database and are unique to each page. Here is a sample from a single page, showing how it can be used. (The two-letter abbreviations are user initials.)
HH: Where are we going to get the information on these products?
TC: I think Sue has a spreadsheet of all the product info. Is that right, Sue?
SD: Yes, but I get that from a database from the head office. You might want to use that.
HH: Sue, who could I speak with about getting that?
SD: Matt at X 125 can help.
Some notes we want to remain on the prototype. Others can be safely removed when the underlying issue has been dealt with. For example, if a client writes a note saying, “we’d like to see our logo in the upper left corner of every page,” you can remove that note once the change is made. A nice feature of DevNotes is that any removal only makes the notes disappear from the page; they remain in the database – something that is very useful in reconstructing how a decision was reached.
These two tools and techniques are remarkably effective. At very little cost to the client or us, we can rapidly go through the discovery (a.k.a. scope creep) process, taking successive passes at arriving at a finished prototype – one that looks identical to what the application will look like.
Once we arrive at that point, where both the client and we agree that discovery is complete, we “freeze” the prototype – meaning that no other changes can be made (at least for this version). The DevNotes are removed and the prototype forms the basis for our real application.
There’s an old story told about a little girl who is asked to spell the word, “banana.”
“I know how to spell it,” she explains. “I just don’t know when to stop.”
With these tools and techniques, we know when to start writing markup and code (when the prototype is frozen) and – just as importantly – when to stop (when the prototype “runs”). Thus, we begin to craft a system that will make both client and developer successful.