“I’ll know it when I see it!” Many software specifications should simply make that statement and call it a day. Spending a lot of time at the beginning of a software project trying to precisely define software behavior and appearance is often a waste. Let me tell you a story.
I once reported to the president of a mid-sized firm (about 300 people). He was one of the most driven people I’ve ever met — laser-focused and hard to please. One thing about his style was particularly interesting. He wasn’t very good at clearly describing what he wanted our software to do. However, once he got to see and touch working software, he would quickly tell me what he liked and what I had to change.
We were working on touch-activated devices like touch pads and touch screens. We wanted the control software to work well with standard Windows and Macintosh software not just applications specifically written for touch devices. Given the state of the computer industry in the 1990’s, this proved to be quite a challenge.
It Can Be Stressful
We’d go back and forth, round and round, until he got his hands on something he liked. We produced some great software but it was nerve-racking at times. He found it much easier to judge an actual result — “I like it.” or “I don’t” — than to describe an expected result — “I want it to do this and look like that”.
While this executive’s style may have been a little extreme, his approach is all too common. Many people have a difficult time describing what they want software to do — how they want it to behave. Yet, when they see and touch working software, they almost instantly love it or hate it.
I know from personal experience that defining the behavior of a software system in words and phrases cannot accurately convey the look and feel of the resulting software — then is gets worse. Even in situations where people believe they have a clear vision of what they want, by the time the software is delivered that vision may change — “…that’s what I said, but it’s not what I need now”.
What Should a Development Team Do?
I used to be a big fan of UML modelling — use case diagrams, activity diagrams, class diagrams, etc. Modelling can help the technical team to fully define and comprehend the behaviors of a complex system. Unfortunately, modelling does nothing to help the stakeholders and end users.
We need to deliver working software early and often instead. Get some aspect of the software into the hands of business people or customers as early as possible. It doesn’t have to be feature-complete, visually-elegant or bug-free. It simply needs to do enough to give people a sense of where the software is going and allow them to change its course.
What do you want from your favorite software package? I’ll know exactly what I want as soon as I see it.