Endless abstraction forms most ambiguous: Requirements gathering in the modern world

At one point in my career, I cut fabric for a living. It’s an odd job, but it’s tangible.

When I started interpreting, the most people could relate to was signing. But, that was the end result of my job, not the entire part. I spent years explaining that I knew more than just the alphabet (Z is really hard) and that it wasn’t just English on the hands (no, really, it has more in common with Arabic than English).

Then, I went into data analysis, data visualization, or the 900 other names people throw at this profession (I’ve lost track). Now, no one really knows what I do.

As work becomes more abstract, it becomes harder to get others to relate to what it is we do. I’ve seen people comment on this on Twitter, usually in the form of ‘how I explain to person X what I do for a living.’

During the industrial revolution, most people made concrete things. They made tires, or car parts, or design specifications for others to craft. They wrote books on philosophy so people like me could read them years later and Google for the Idiot’s version of it. There were a few people who managed it or ran operations – usually soft skills.

As time progressed, work became more abstract. Coding became a real, full time job. People spent not only hours, but years making things that only existed on a screen. Their fingers remained soft and supple versus anyone who has ever done any form of manual labor. It used to be, people worked without computers. Now, I have seen places close for the day when network issues prevented outside access.

We’ve made great strides in technology. But, it comes at a cost: how we talk about what it is we do.

I’ve been reduced to explaining to my clients that it’s a “process” to do my work. For many, I’m sure they see charts and assume that’s the bulk of it. The charts are a small amount of my work. It’s why no two analysts do the same analysis.

As we move to work that exists only in the nether, it becomes harder to explain it all. People attempt to combat this by creating documents – as tangible as we can make this work – usually around requirements.

Requirements gathering is a dark art, if I ever saw one. It deserves its own chapter in Dante’s Inferno. Why? Because we’ve made it impossible to succeed.

Ambiguity creates fear. It’s biological. When we go into the unknown, the vast majority of people will still look back and attempt to measure distance. We push people for plans and do nearly everything we can to mitigate the risk of failure. When it comes to projects around technology, we may as well be gambling over a million dollars.

Technology is ambiguous. It uses code, which is not like parts to an automobile. It’s like painting. Sure, you start with the primary colors, but you can make any color in the world with enough dabs into the paint and some patience. And, without a superb amount of expertise, it’s impossible to recreate the same thing in the same way twice that has any complexity.

And, technology is usually complex. And, so are our needs these days.

In fact, it’s so complex, we don’t usually have good ways to describe it. It’s like describing black holes to pre-schoolers. Sure, they think the idea of an endless vacuum that can eat anything is wicked cool, but physics gets lost.

So, we try to create the solution we want down to a tee. We spell out check boxes or drop downs or chart types or make drawings. I rarely see these succeed. Clients rarely get solutions that truly work for them and the people making it (programmers, analysts, what have you) spend a lot of time going ‘if only…’ Can you imagine spelling out the demands for making the Mona Lisa? I want her to look coy, as if she’s hiding something, but not too coy. I want her to be realistic, but not like a photo. It needs to become a historic piece by which we judge all art going forward. Too many demands creates chaos. Especially when dealing with something that is not manufactured, but an artisanal creation that is unique.

I’ve been on both sides of the fence. I started with making the requirements documents before moving into consulting, where I’m now responsible for bringing it to life.

Here’s what I’ve learned from this:

1. Unless YOU can do it all, there is no perfect solution. Artisanal products require compromise, in part due to limits, cost, or expectations. Mass deployed solutions seek a common denominator, but rarely solve everything. Prioritize most important items to least.
2. Focus less on features and form factor. Instead, focus on function and users, as those items will drive the form.
   • Experts in a particular domain are particular about that domain. They’ll try to advise you out of particular choices for a reason, usually because of failure rates.
   • The more you specify, the more specific the consultant will be at checking those boxes. Those boxes may be at odds with your intent.
3. Describe where this fits into the picture. Make it as tangible as possible. If you had to pick one person where you win it, name that person. Include them in meetings.
4. If you’re creating something new, it will be an evolution. If it’s never existed, you can’t fully predict how it will be used. Margarine was originally created as a low cost alternative to butter. Now, the price for it is all over the place, with what seems to be half of it being more expensive than bare-bones butter. Who knew?
5. If you’re doing waterfall for artisanal solutions, you will be angry, surprised, and pay more more. Trying to define abstract concepts before seeing them bear fruit means all lessons get learned at the end. That list of “If I had known…” will be very long.

Here’s how I’ve seen requirements documents succeed:

1. Co-draft them with the people who will be doing the work. Scary? Absolutely! But you’ll come out ahead because you’ll spot pitfalls during the document process.
2. Think smaller and do parts with a working vision towards a whole. Prove a concept and see what works so you draft better for other parts.
3. Pilot where you can and where it makes sense. If you’re looking to do a massive overhaul, figure out where the largest part or most critical part lives. Pick this first and see what works.
4. Seek options or opinions. Will it be different from what you want? Of course. But you’ll likely end up closer to your overall vision.
5. Find ways to end abstraction. Show things you like without expecting an exact replica.
6. Get the skeleton right and everything else can be adapted easily.