Recently, I retweeted an item from Neil Killick and I was surprised to see a response from Tom Gilb, legendary software methodologist. The tweets can be viewed in the picture below (read from bottom up).
Apart from the honor of getting some of his attention, I was a bit concerned with the response. I seemed simplistic and categorical to me. Quite frankly, it sounded like something out of a schoolbook in software engineering from the 80s. I find myself in disagreement with it. To disagree with Tom Gilb is scary so I needed to write down why.
To me, one (wo)man’s “what” is another (wo)man’s “how”. To me, they’re two sides of the same coin. At least in software.
Let me explain.
Our job as software developers is to identify deep needs from users and other stakeholders and, in an iterative process, design and deliver solutions that satisfy those needs. This has been increasingly clear over the last decades with the Agile movement, the User Experience (UX) school, Lean Startup, focus on effectiveness over efficiency, developing the right thing beats developing the thing right, etc. The basic “what” here does not concern features in software but this:
What are our users trying to accomplish?
Software is one way of satisfying that need and there are an infinite number of ways to do it in software. The basic “how” here is this:
“How can we help them reach their goals using software?”.
An infinite number of solutions, no “best way” – only more or less useful, a need for an iterative process are all tell-tale signs that we are in design land. Hence, creating and iteratively adapting a software solution is, at its basic level, a design activity.
Well, what about features then? The most important design decisions concern whether a feature should be included or not. These decisions form the base of the user experience (but only the base). Including, refining and removing features are, or should be, easy to do in software. Being malleable is software’s main characteristic. That’s why it’s called software. One could call this form of design Functional Scope Design and Steve Jobs was the uncrowned king of it.
This breaks with traditional thinking and especially the views of many in the requirements community. I find the mental model of “managing requirements” quite damaging. Very few things in software are truly required. In most projects, there are none. Horrid language expressions like “a should-requirement” is a giveaway that the model doesn’t quite fit. I now believe the whole requirements movement was a step in the wrong direction. The word “requirement” is wrong almost all the time and the typical methods employed are not suitable to the problem.
I don’t know about you, but personally I find it more useful to focus on designing the right solutions for users in their context instead of worrying about what is “required”. Try it! It’s a liberating thought.
That is what I mean when I say that there are no real requirements, just unfulfilled needs and unwritten software for them.