A Hacker News discussion of software requirements

Also a lot of dark humor. The upshot is that “stakeholders,” i.e. the people who want software and will pay for it, usually have only the vaguest idea what they want; and when they have forceful and specific ideas, those are usually entirely wrong. That makes it just slightly difficult to deliver something stakeholders will be happy to have purchased. Success depends on working with them to clarify their purposes, which they commonly resist with all their might.

I drew on this discussion in writing about software purposes, why the merely rational “requirements analysis” approach fails, and a better, meta-rational approach. I’ve also referenced it in “Meta-rational software development: Readings.”

Since the discussion is lengthy and of varied quality, I’ve re-posted some choice bits as a separate page here. (The discussion itself begins as commentary on a blog post that is fine but not especially recommendable.) I have edited some of the comments for concision, clarity, and typo correction.

Is this really a requirement, or a vague “maybe something like that could be useful”?

… a bunch of sentences that really don’t describe what the product should do, but rather only contain a high-level vision of what some users might like to do in a science fiction version of the world.

The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okay-ish requirements to good ones is high. You need to take into account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.

Much of my job is saying no to things which have demonstrable value, because there are many other things which have demonstrably higher value. Stakeholders see the world through their departmental lens, and expanding their vision takes a lot of effort. Often it doesn’t work at all. This makes me the bad guy.

On the flip side, I’ve worn many hats and it feels like one of the most impactful places to be in a business. I get to shape what we build, and see it to completion. Very satisfying, but not easy.

… can end badly if this leads to the PM [product manager] chasing whatever thing their latest customer / prospect interaction mentioned, rather than sticking to plans for long enough to get things to stabilize. Additionally, some times they can end up promising features and fixes on a schedule that isn’t sustainable for engineering

Requirements aren’t gathered. They’re invented. A collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.

Designers need to know the problem space, the materials, etc. The requirements part can’t be separated from those, which is exactly what the concept of “requirements analysis” promotes.

The spec [specification of requirements] does not exist. It isn’t buried in your customers’ brain, or your CEO’s. It isn’t mined. It is invented, one way or another, by those making the damned thing.

The “requirement” for a spaceship is “must travel to the moon.” What software requirement mining tries to do is mine Kennedy’s mind for the design of the bathroom.

The stakeholders don’t really have requirements, they don’t know them; and when they think they know them, often those are not the “real requirements,” but some proxies which may even need to be violated to get a good product. They may think that a significant requirement is to ensure that some thingamajig is very reliable and has many redundant duplicates/backups, but a better solution is a design that removes that thingamajig altogether.

The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I’m not talking about making the detailed spec, I’m talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.

Requirements are, however, not simply a collection. They depend on each other. And when this dependence is missing or not communicated, the engineer will invent it to compensate for the lack of it. Every engineer. In their own way.

If people want some undefinable thing and they know it when they see it and they get mad when they don’t get it, you’re going to get engineers asking for the “perfect spec”—because that’s what they are effectively held accountable to.

Need to specify just as much what it won’t do as what it needs to do.

For example, “customer wants to query for names” is a shitty requirement. Of course they do, we all want search engines for everything, but that’s not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like “quoted”), do they want “starts with” or “contains” searches, wildcard characters?

Getting to Version 1.0 means not building the wrong or extraneous things, just as much as building the right things. Only a handful of people bear responsibility for distinguishing between those sets.

You get asked to make a faster horse instead of inventing the car.

…can be summarized as “this thing over there needs to be better, or maybe pink.”

I try to learn to think like the user, at least a bit. I even had to learn the basics of coal mining once. You could say it was a waste of time for a programmer to learn coal mining. But, it saved countless hours of misunderstanding and wasted time.

Building the thing right - takes just a few years of experience.
Building the right thing - that’s the real challenge :-)

Customers don’t have requirements, they have problems they need solved.

[Customer doesn’t know what they want because they have no clue how their own business works:] It really amazes me at how many large companies just fly by the seat of their pants with virtually no idea of what they’re actually doing, no documentation, and little ability to explain their actions.

Let’s get something in front of the users asap, because they don’t know what they want (after all, they gave us vague requirements!) This lets us iterate more accurately.

You’ve both explained why the Product Manager / Product Owner job is so hard, and hard to fill. A competent candidate must speak both “business” and “tech” fluently, even though not expert in one of them. In my long years I’ve found some people speak business very well, and they’re promoted. Some people speak tech very well, and they’re promoted. It is demanding and difficult to find someone who speaks both languages well and wants to spend their lives translating between two camps which often don’t even want to understand the other side. We often end up taking all the heat with misunderstandings, requirement conflicts, capacity constraints, and priorities. A potential candidate for the job is usually earning as much or more as just a business or tech person, and with less stress.

Find out what people need. Not what people want.

Most of the time users will come and say what they want. They basically describe what their “perfect” implementation should look like. But almost never do they describe what needs they have. Or what they really wanna solve with that suggested implementation.