Hacker News Reader

Comment by masklinn | Hacker News Reader

> The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions

I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.

"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff

View on HN

As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable.

In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.

Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.

“Everyone has a plan until they get punched in the mouth.”

The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.

I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.

(this might not apply if you are writing code for moonships)

That's why developers should be the ones taking a step forward to make vague requirements "complete" and "precise". They will satisfy the business goals and there won't be fairy tales.

Well, that's the nature of software.

If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.

The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.

What if one party is incentivized to create said information deficit?

> As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales.

Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.

Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.

Yep it is very unlikely that the business silo has a clue what needs to be built.

Reply on news.ycombinator.com