Soul of an Engineer #2

Requirements and Constraints

The hardest task in software is deciding what to build.

A common practice (still!!) is to “gather requirements” to decide. We often believe users know what they want. Requirements understood that way are not needs. They are expressions of what somebody thinks what they want. The probability of building a good software system with such a list of requirements is low.

In that sense, “gathering requirements” is really an anti-pattern. In software, anti-patterns are common solutions that yield undesirable results.

What would be a pattern antidote to “gathering requirements”?

I am going to start with the idea of Via Negativa. Nassim Taleb writes in his book, Skin in the Game, “Systems learn by removing parts, via negativa.” Via Negativa is a principle that means it is easier for us determine what’s wrong than what’s right in a given situation. Nassim’s footnote in the book goes on to say, “Knowledge grows by subtraction”. It made me wonder - how can this be applied to building software based systems?

There is a different conception of the same idea from Christopher Alexander. Alexander’s proposition is centered on designing “forms” that fit the “context” of real world problems better. I am quoting a couple of short passages of Alexander’s book in full, Notes on Synthesis of Form.

“The concept of good fit, though positive in meaning, seems very largely to feed on negative instances; it is the aspects of our lives which are obsolete, incongruous, or out of tune that catch our attention.”

“I should like to recommend that we should always expect to see the process of achieving good fit between two entities as a negative process of neutralizing the incongruities, or irritants, or forces, which cause misfit.”

I don’t know if Alexander had Via Negativa in mind while writing this. But to me, what he wrote reads like a great bridge that links Via Negativa to the building process.

Related to that, I am reminded of an example from earlier part of my career. I was once tasked to “gather requirements” for a system to match patient cohorts to clinical trials. I started interviewing researchers and data concierge teams. They told me everything about what they were doing. And what they wanted quite animatedly. I got details. In fact I was drowning in them and getting frustrated.

The principal investigator of the trial protocol, perhaps sensing my struggle, sat me down one late afternoon. He drew on paper how he resected samples in a cancer surgery and how they were used in cancer research. He hooked me up for a live tour of their tissue bank. Those people showed me how they bank samples. More importantly, they told me about problems they faced in capturing the attributes of samples they were banking.

Gradually the link between the pains of data concierge teams and researchers on one side and real world data capture on the other side got clearer. I decided to focus on eliminating those constraints one by one. We built a successful system over the next few months. Ten years down the line, it is still providing value to researchers.

I believe this idea of “eliminating constraints” is the actual pattern antidote to the “gathering requirements” anti-pattern. After I read Taleb’s and Alexander’s text, it feels even more intuitive than before. “Eliminating constraints” is same as “neutralizing incongruities, or irritants”, and completely aligned with Via Negativa.

I have started emphasizing this amongst my teams every time we struggle with a deluge of requirements.

“Gathering Requirements” simply doesn’t belong in today’s world. We have to focus on “eliminating constraints” of users as a pattern.

Afterthought: “The good is not as good as the absence of bad.” - Ennius (as quoted by Nassim Taleb in ‘The Skin in the Game’)