The Dangers of Makin' It Up

by Gary K. Evans

We all want to deliver to our customers the software they need, but we should never, ever speculate about their needs, or our project's requirements.

A very capable Project Manager at one of my clients related an episode to me recently. Her team has been adopting agile development. They are sharp, dedicated and knowledgeable. But somewhere along their journey, they yielded to a subtle temptation. It came in the form of a question in their iteration planning meetings: "What if the customer wants...?"

It is a very simple question, but it became a complex and expensive proposition for them.

Sometimes this question is verbalized in a public forum, and can be recognized as a risk on the project. Often it is entertained only privately, then put into action by a Business Analyst (BA), Business System Analyst (BSA), or Developer. Having the question is not a problem, but failing to deal with the mindset leading to the question can be fatal for a project.

BAs and BSAs

BAs and BSAs should never create, invent, or speculate about customer needs, or system features. But they often do. The typical scenario is: IT asks for clarification on a customer need or feature, and the BA/BSA fabricates an explanation that makes sense to him or her. The actual customer is rarely involved. The analyst doing this is injecting risk directly into the project. If the analyst's understanding aligns with the customer's, little downside may occur. But what if the analyst is wrong? The misalignment will be discovered, and probably after delivery of the system to the customer.

Why would a BA make up what the customer needs? Sometimes it is arrogance. Sometimes it is naivety, or fear that he or she may introduce delays into the project if IT's requests are actually presented to the customer. Sometimes the BA wants to project an image of being on top of things, including speaking on behalf of the customer - who is paying for what they want, not what the BA thinks the customer wants. But whatever the rationale, this behavior can place the project, and the software vendor, at severe risk.

Developers

Developers should never presume beyond the requirements delivered to them. And what is the proper response for a developer when no requirements are available? Stop coding and go obtain the requirements. What does a good developer do when no one will provide the requirements? Stop coding until they do. This sounds very anarchisitic, but it is also very wise, and will save your company a bundle of money. Quite often, only one or two requests are unclear. The developers should raise their uncertainty to the proper level, discontinue further analysis or coding on those areas that are unclear, and move their efforts to those requirements that are clear. But sometimes, so many of the project goals or requirements are inadequate or contradictory, that the whole project needs to be stopped until it can be resuscitated.

I consulted with a startup company in which the business people would not provide requirements - literally. But the delivery date for the first release had already been set in stone - by the same people, of course. I discovered that the "requirements" for this system were being conjured up by the most junior programmers only a few months out of college. It was the Indiana Jones School of Software Development at its worst: "I'm makin' it up as I go, kid". I was simply unable to get any business participation from these people, and emails to the CEO brought no change.

So, I sent home everyone on the development team. A couple of days later the CEO asked where my team was. I told him I sent them all home because his business people still refused to give us any requirements - but we were still billing him by the hour. This project started making real progress at exactly that moment, when he called a project status meeting for 8pm that night! But the mindset was too ingrained. The business people did not understand how to provide the vision, and the developers did not understand that they should not write code without a clear view of their target. Both teams were dysfunctional, and that company did not live to see the end of the last millenium.

People who do not develop software do not understand how the minds of developers work. Here is the developer mind in a nutshell: developers live to solve problems, and they will create a solution even if they have not been given a clear problem to solve. I have a colleague who says, "I get worried when the developers get quiet and stop asking questions". When this happens, he knows the developers are makin' it up. Do your Project Managers get worried when developers get quiet? If they understand developers, they will be very worried.

Developers must discipline themselves to never write code that is not backed up by a solid, measurable requirement. To do otherwise is to engage in the time-honored tradition of gold-plating: adding functionality that is neither needed nor asked for - which is called makin' it up.

When developers choose to not write code without clear requirements, every part of the project benefits. Every line of code a developer does not write

• Requires no IT staff
• Requires no requirements
• Requires no documentation
• Requires no end-user training
• Requires no testing
• Has zero bugs
• Requires no rework
• Requires no maintenance
• Does not cause other code to break
• Requires no debugging
• Costs $0 to produce
• Does not take time away from code that does need to be written.

With a liturgy like this, we should all strive ruthlessly to write as little code as possible - and only the code that maps to specific customer or end-user needs.

The Project Manager I mentioned above learned a priceless lesson about makin' it up. First, her team burned up a 3-week iteration trying to invent requirements. Then, they had to throw out that work, and add another 3 week iteration of rework getting the real requirements and recoding. Confidence eroded, and morale tanked, but they recovered. Now, they are exquisitely sensitive to anyone asking "What if the customer wants...?" They know this simple question arises only when they do not have a clear understanding of what the customer does want, and they will no longer indulge makin' it up. In her own words, "If we cannot get a clear 'why?' we can't support the requirement.... Now we escalate it and do not do anything until we have an answer. It doesn't stop all development; it just removes our focus from that issue so we can focus on what we do know."

That's the kind of confidence you can't make up.

    Gary K. Evans