Hacker News new | ask | show | jobs
by b33j0r 1105 days ago
Indeed. Tangentially, there is another side to the coin.

The antithesis of this is the contract model, when a client comes to you and asks you to make something specific, rather than describing what they need. In this case they are almost always wrong. They’ll rarely admit it unless you show them some amazing alternative, though.

Requirements = a set of problems to be solved. More often you get handed a diagram of a 12” tall Stonehenge sketched on a napkin with exceeding confidence that it will be 12 feet tall.

Then they yell at you for doing what they said.

4 comments

This happens outside development, too. More often than not in IT, when the business has a need, they start with a solution and approach IT asking them to implement it. I've gotten better over the years (although always room to improve) at steering the conversation around to "what exactly are you trying to accomplish?" Let's start there.
I.e. “If I had asked people what they wanted, they would have said faster horses.”

(Probably not a real quote, and probably not even accurate.)

The quote is alleged to be Henry Ford, and I've always encountered it as "better horse."

In either case, the customers aren't stupid but instead are using the language and paradigm they are familiar with to describe their needs. Ford did indeed provide a faster/better horse, because the horse was the main means of non-human motive force in the US.

The technologist's job is to understand the universal of possible solutions and to understand the customer's needs and goals, which often includes interrogating and parsing the customer's language/worldview, and craft a product that achieves those needs/goals (and doesn't introduce negatives that overwhelm the benefits).

Regardless of the provenance of that quote, it is quite apt wrt IT clients. They always come asking for a faster horse, ie: something they know that is just better in a specific way.

A lot of the times this might be wrong but I think the interesting part is how that request gets handled.

And if I had told them I’d give them something that leads to excess deaths, climate change and urban sprawl they might have stuck to their horses.

/s but maybe only half

The horses were themselves a more immediate sanitation problem; in New York alone there was a million pounds of horse manure every day, plus thousands of horses that dropped dead from overwork. Disposing of all the feces and corpses was a challenge.
And to be fair there was a lot of grumbling about the "horseless carriage" for quite awhile.

What's interesting to me is that the oldest streets (ignoring the Main Street) in the local small town are the widest, because they needed to be able to turn around a team of horses and a carriage/wagon even when other wagons are parked on the side. The newer streets (but still 1940-50s) around are narrower because they didn't have to accommodate that.

It was Ford as I recall
It is frustrating how often I have to tell my non-techy CEO to rewind a step, and tell me the problem he is trying to solve not the half-baked solution he came up with. One bad idea he has had for over a decade, and I have to keep beating it down since it is an extremely stupid method to solve nothing.
There is another side to this coin, too. It is clients that describe their needs, not some specific and wrong solution, and then either get told they did not do their homework, or their needs getting ignored by a dev who thinks he is smarter than the client in the client's own field.

It is correct that "Requirements = a set of problems", and therefore it does not make sense at all to repeatedly ask the client for a technical solution instead of asking for the problems to solve, and then be surprised that the client does not talk about problems anymore.