“Developers are profoundly disconnected.”
Those were my exact words in a recent department meeting. I let the statement hang in the air for a moment so that everyone could give it the consideration it deserved. There was dead silence as everyone waited for me to continue. After a few moments, I clarified.
“They are disconnected from the needs that their programs are intended to meet as well as the results that their programs produce. Beyond the code itself, they only know what you tell them. If their program doesn’t do what it’s supposed to, it’s probably because the problem wasn’t explained to them in sufficient detail. They’re not mind-readers. You have to be specific about your needs.”
My little speech went on for awhile longer as I played devil’s advocate with all of the problems the other marketers had been citing. Until that point, it had been a solid round of griping about the development team not delivering what was asked of it. As I picked apart their concerns, it became evident that many of them had not communicated their needs adequately, either before or after the program was written. Instead, they had waited until a problem escalated to become vocal and negative about it.
Ideally, developers are given firm, specific requirements for how their programs should function. There is no question as to what needs to be accomplished. They write the exact program that the client wants, the client is happy, and the work is completed without incident.
In practice, however, requirements are often vague and inadequate. Clients rarely want to put forth the effort to be explicit, or else feel that their requirements are somehow obvious enough that the developers can just pull them out of thin air.
Naturally, this puts developers in a dilemma. Without good requirements, they are unlikely to deliver a program that fills their clients’ needs. If they press for good requirements, however, their clients become irritable and dismissive. I’ve seen it happen many times, and it never turns out well.
The same problem occurs after a software solution is in place. Clients are frustrated that the program doesn’t meet a need that was never identified. Instead of being productive and explicit about the new need, however, clients become belligerent, claiming that the developers did not deliver what was promised. Never mind that the clients got exactly what they asked for; it wasn’t what they wanted, so the developers are to blame.
The point here is that you won’t get any more than you ask for, so it pays to be as explicit as possible. In software development circles, the process for this is referred to as requirements gathering. Before a single line of code is written, clients and developers document all of the program’s functionality down to the smallest detail. Only when the two groups agree on the explicit end state does the actual development begin.
From a business standpoint, the thorough documentation needed for proper requirements gathering is often impractical. The exercise itself, however, is anything but. Walking through the details isn’t just worthwhile; it’s imperative. If you take the time to think it through and spell out exactly what you need, your developers will be able to deliver exactly what you want, without the hassle, headaches, and hurt feelings that might otherwise occur after the fact.