In a recent episode of the advice show “soft skills engineering”, a listener described some of their reasons for hating their job:

developers who need me to Google for them, business people who don’t understand how to provide requirements

I’d like to focus on “business people who don’t understand how to provide requirements”.
That’s an issue that used to frustrate me to no end earlier in my career.
I would receive a work ticket describing functionality to be implemented, complete with a UI design mockup.
I would go into my hole, and emerge a few days / weeks later with everything working as described.
Then, to no-one’s surprise, I would be assigned a new task. “move that button from the bottom of the screen to the top”. Or “limit this set of functionalities to admin users only”. Or “for premium users, the calculation should be different”.
And then, also to no-one’s surprise, I’d get annoyed.

“But you signed off on the mockup that had the button at the bottom!” or “Now I have to completely re-write the permissions mechanism for this!” “What’s changed between when you wrote this spec, and now??! Couldn’t you have thought a bit harder and given me the correct requirements the first time?”

It seems that the question asker and I are kindred spirits.

The first thing podcasts hosts Dave and Jamison said is this: If the question asker were to change jobs, they would find that this is still happening at their new job as well.

Too right, I say! Aren’t those business people stupid, hurr durr…

They also said –

No matter how clearly they document requirements, there’s always some ambiguity.

It’s unreasonable to expect business people to come to you with even somewhat fleshed-out correct requirements

Developers underestimate how extremely challenging it is to translate problems that people observe in the real-world into software requirements that can be implemented

You need to talk to them [people who provide requirements] more. If they give you requirements that you are concerned about, you just talk to them about it and ask them:
Why do they think this is the right thing? how certain they are that the requirements aren’t going to change? what if it takes longer than they expect?

These are all great observations. But I’d like to expand on them a little bit, since this is an important issue that makes life miserable for many developers.

So now, I’m ready to reveal the secret. Something that I’ve learned after many, painful experiences as a software developer. Are you ready?

How to get business people to figure out what they actually want

Before we dive into the answer, let’s try a few thought experiments. These are designed to get us into the head of the business people, and try and think like they think (don’t worry! it’ll only be temporary. You’ll be back to thinking rationally in a minute).

Experiment #1: Have you ever changed your mind about something?

Has it ever happened that you thought that one thing was the best option, but, upon seeing what it actually looks like, you realised it wasn’t? For example –

  • You thought that the big armchair would look best next to the chaise-longue, in the drawing room. But then you realised that it was the most comfortable chair in the house, so it should go in front of the TV.
  • Or, you thought that there is no way that sweet pineapples belong on savory pizza. That’s insanity! But then, when you tasted it this one time, it totally worked!
  • Or, you thought it would be a killer photo if you and your boyfriend pretended to hold the leaning tower of Pisa up between you. But when you posted it on instagram, it got no likes at all.

Do you see where I’m going with this? It’s impossible to know whether something would work for you before actually trying it.
If you’re still not convinced try this one –

Experiment #2: Can you provide the right requirements upfront?

Imagine a software development process consisting of these stages:

  1. Write requirements
  2. Create software design (e.g. classes and modules) based on those requirements
  3. Implement the design

Now imagine that you’re responsible for step 2: Given a set of requirements, you provide a set of classes and functions to satisfy those requirements.
Do you think the resulting implementation in step 3 is going to 100% reflect your design?
Or will you find edge cases, unforeseen complications, wrong assumptions, which would mean that the implementation needs to deviate from the design?

The simple truth is that, like Dave and Jamison hinted, there’s no such thing as “the correct requirements upfront”.

So what can we do?

This is a solved problem

20 years ago, a bunch of smart dudes got together, and wrote a manifesto for better software development. Here it is, in (almost) its entirety:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

How does that help us to get the actual right requirements out of those finicky business people?
Let’s see:

  1. Customer collaboration over contract negotiation: don’t waste your time writing specifications that you know will be inaccurate. Instead, find out who has the answers, and work together with them to find the right solution.
  2. Individuals and interactions over processes and tools: don’t invest time and effort into creating a process for generating and validating requirements.
    Instead – talk to the actual subject matter experts. Get them to explain their problem to you.
    Understand their pain points, and points of view. Raise any questions immediately to them. Get their feedback early and often.
    Get their feedback on –
  3. Working software over comprehensive documentation. Remember – you can’t tell what that Hawaiian pizza tastes like just by reading the recipe. you need to actually try some.
    If you do all that, then you’ll be
  4. Responding to change over following a plan: change is inevitable. Even if you think you like that sofa on that side of the room, you might realise it looks much better on the other side.
    Change will happen. You can choose, like me, to be grumpy and bitter about it. Or, you can accept it, and make sure that it causes you the least amount of disruption and pain.

Some practical tips

Here are some ways I’ve had success putting these principles into practice –

  1. Cut out the middlemen – find out who the actual users / subject matter experts are.
    Hint: They are not your product manager / business analyst.
    Talk directly with the people who personally experience the business problem. Understand what you’re actually trying to solve.
  2. Get the business people engaged – in the first step, you’ve found the people who care most about getting this business problem solved. You’ve listened to them in earnest. Most chances are that they now trust that you care about their problems as well.
    It then hopefully shouldn’t be difficult to get them to commit to engage with you.
    Ask them to be available for reviews, questions, etc. Explain that, this way, you’d be able to build what they need faster and better.
  3. Feedback – get their feedback early and often.
    Invite them to your story refinement / estimation meetings. Have regular demos of (some) working software. Change your upcoming tasks based on what they tell you.
  4. Embrace change – changes will happen. When they do, be thankful that you caught it as early as you did.
    If you have a good understanding of the business problem at hand, you should also understand why that change happened. That should make it a bit easier to stomach.

* for cases where you don’t know your users (e.g. a public-facing product), this process will have to change a bit. You’d still want someone who’s a subject matter expert (this may very well be your product manager). Together, find ways to get users feedback without being able to talk to all the users.
For example – talking to a sample set of users, using A/B tests.

The nice thing about these steps is that anyone can take them. You don’t have to be a manager / lead: All you’re doing is talking to some of your colleagues in other departments.
Unless you work for a very broken organization, nobody would tell you off for simply talking to other people (if they do – consider changing jobs…)

Closing thought: But I’m a developer, why are you asking me to do a PM / BA’s job??

That’s a common misgiving developers have to the approach I presented above.
So, what do you think is a developer’s job? If it’s only about converting requirements into software, then our job description would be something like:

Write code to fulfill given requirements

Maybe that’s what you think your job is. And, for junior developers, it probably is.
I propose, though, that for senior developers, this job description is more accurate:

Provide business value by creating software

How is this different from the previous definition? The replacement of “requirements” with “business value” is subtle, yet profound.

Imagine that you 100% accurately implement the given requirements.
But then, no user is buying that functionality. Or, the internal users still use excel to perform this task, because your solution doesn’t cover all cases.
You have fulfilled all requirements. But have you done your job?
I’d say no. You’ve created software, but that software hasn’t provided much value.

As we progress in our careers, we’re expected to have a larger impact on our company, to justify that larger paycheck we’ve come to expect.
And it’s not only on the ‘how’: less buggy, and more maintainable, software. It’s also on the ‘what’: making sure that the software we create serves the needs of our employer.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s