[li4ick]

Yeah, this reads like cope. So, all software engineering? Then you must have a pretty narrow view of the problem space. Quite a lot of problems have a pretty well defined set of requirements that can fit on one page. It's the technical excellence that delivers on those requirements.

[matwood]

> Then you must have a pretty narrow view of the problem space. Quite a lot of problems have a pretty well defined set of requirements that can fit on one page.

If this is true, then these problems are already solved. And, given the nature of software, they do not need to be solved again. The reality is that every single piece of software ends up being unique at the edges. It's what makes software great, but also so challenging. It's also these edges that take your 1 page of requirements and turn them into an ambiguous, conflicting set of 50 pages.

[wongarsu]

> If this is true, then these problems are already solved

There's a lot of induced demand in software development. We have spent the last 70 years on incredible productivity improvements through better tooling, language design, frameworks, etc. But all that has done is create more demand, both for functionality and usability. Now that animations are cheap to add to UIs, people want to have them. Automating tasks that can be done quite cheaply by humans is becoming cost effective in ever more fields. Software of complexity that would be unimaginable in the 50s is used for purposes as mundane as many-to-many short messages.

Lots of software is unique, but at the same time there's also lots of software or software features that just recently became cheap enough to implement to be worth doing. And those can sometimes be quite simple in their requirements.

[yuvadam]

Can you give an example of a non-trivial problem with a well defined set of requirements that you can fit on one page?

[sclarisse]

To support our next-gen machine learning system, we need a 10 exabyte storage array. It should host a system accessible over TCP/IP or Infiniband that can stream random-access 1MB blocks of data to 65,536 different computers, at continuous loads of 64 GB/second each computer, using a protocol of your choice or design. Correct for all data corruption and do not lose a single bit during the next 1,000 years of operation.

Yes, we can add more specs but these alone should be pretty daunting.

[dylan604]

What does this have to do with building software? This is something submitted on a form for hardware for a capex

[sclarisse]

If you think you’re gonna organize that many bits and not lose them for centuries at a time, you’re seriously underestimating the need for data replication and error correction algorithms, first of all.

[dylan604]

Again, that's a hardware storage solution's problem. Adjust the parity level in the filesystem. Unless you're writing the requirements for building the software for a storage platform.

[sclarisse]

… yes, that is in fact the point

[ubercore]

There are money, operations, and delivery time requirements, just off the top of my head, not expressed in that requirement that vastly changes the solution.

[DevFem666]

And the client is all over you/the company.

[whynotmaybe]

As a usual bore, I'd like to point out that trivial/non-trivial is highly subjective.

Is making an app to connect in Bluetooth to an infrared camera trivial?

Is making a 55Gib fizzbuzz non-trivial?

[mattkrause]

The specs for speedy FizzBuzz are relatively clear, even if the implementation is challenging.

For the camera, there are tons of unspecified behaviors and baked-in assumptions. Is the user configuring the camera, or are we discovering any/all cameras of a certain type? Authentication? What should happen when the connection fails? What if the bandwidth isn’t sufficient (e.g., due to distance or congestion) to deliver the full take from the camera in realtime? How will camera malfunctions be detected, handled, and reported?

A hobby project or prototype can ignore most of this, and insist that you turn it off-and-on if anything looks odd; a fancy turnkey security system should carefully consider all of this and more!

[troupo]

No plan survives contact with reality.

[intelVISA]

Ambiguous requirements are more symptomatic of a problem space that is poorly defined e.g. useless SaaS

If you're building to solve real problems(tm) you don't need a PM to pad out tickets with filler.

[kiawe_fire]

It is due to a problem space that’s poorly defined, but that’s not always indicative of ticket padding or a useless product.

I’ve dealt many times with real people, who present me with a real problem, but no single concrete solution.

If the PM doesn’t take the proper time to understand the problem (and try to find the real, underlying problem that often exists) — Or rushes into a solution without proper evaluation — Or just generally wants to quickly churn user asks into tickets — then the result is the same.

I generally agree that, in my experience, a good senior software engineer is well suited to teasing out “the real problem” and getting to a properly detailed solution even without a PM.

However, that doesn’t mean I don’t think there’s potential value in a PM that can set a broader vision of the product and help prioritize tasks. But the good ones do so by working with and deferring often to his or her software dev team, and NOT by working “top down”.

[EddieJLSH]

Can you share one problems defined set of requirements that fit on a single page?