[Philip-J-Fry]

I don't agree.

I regularly get pieces of work someone product guy has thought up in an afternoon. They only care about the happy path, and sometimes only part of the happy path. I work for a global company that has to abide by rules and regulations in each country we operate in. The product guy thinks up some feature, we implement the feature, then we're told "actually, we legally aren't allowed to do this in 90% of the markets we operate in". Cool, so we add an ability to disable it in those markets. Then they come back "We can do this in some of those markets if it's implemented with [regulatory bureaucracy], so can you do that please".

Then we have to hack away at the solution because the deadline is right around the corner.

This is not software engineering! None of this is related to the software. The job of a software engineer is to take a list of requirements and figure out the way we accomplish those requirements. Requirements gathering is NOT a software engineering problem. Software is implementation, product is behaviour. That's the split. The behaviour of the thing we're building needs to be known before we even try to seriously build it.

If someone just held back for week and did their due diligence, we would been able to architect a solution that is scaleable, extensible, easy to maintain and can make the future easier.

[nuancebydefault]

> Requirements gathering is NOT a software engineering problem. Software is implementation, product is behaviour. That's the split.

That's a theory but I've never seen this work in practice. A piece of software is unique. If it weren't, we'd just use the cp command.

What usually happens is you get a set of requirements that looks simple. Then you start thinking about a design and see 10 different possibilities, each corresponding to a slightly different interpretation of the requirements set. You iterate a few times reviewing the designs with who set the requirements and a few peers and see more possible variations to the requirements. You need to double check its parent requirements up to the master requirements. Then you need to take time/feature/quality tradeoffs, affecting the fulfillment of requirements.

Once starting to implement, you see dependencies to other software (framework, sdk, drivers, language features,...) and understand that other software is not what you thought, or has bugs. Or you see an issue with performance or see that one particular feature becomes unfeasible.

That's where all the complexity goes. AI doesn't change that, but can make prototyping iterations and bug hunting faster, as long as someone holds it on a leash and understands its decisions.

[marcus_holmes]

I think this was TFA's point about "engineers have been begging to be involved earlier in the process forever". Which is absolutely true.

It has to be someone's job to push back on the Product Guy's stupid idea and answer all the awkward questions about the not-so-happy path with it. Unfortunately, because of the way we've ended up with this process, that person is often the engineer tasked with building it, without any effective political power to challenge the design process.

[alkonaut]

That's a software developer's main job. Saying no. Or in rare cases saying "yes, but".

If there is a "hierachy" where product managers are seen as superiors to software development, i.e. where product managers decide what to and then only delegate the implementation to software developers, that product will invariably fail. Don't do that.

[serallak]

But that it's not really the case in the example above.

It's not the software engineer duty to know about how a given product is legal in what regulatory environment. That is something that must be hashed out upstream, well before tasking somebody to write a program.

Granted, an expert engineer with strong domain knowledge could be aware of those kind of pitfalls, and offer insights during the product development phase. But again, that should be done before committing to a schedule or making implementation decisions.

[gpderetta]

I have only been doing this for the last 20 years, so maybe I don't know, but it seems to me that requirement gathering is trivially software engineering. How can you implement something if you do not know what you need to implement. Figuring out what it need to be built and how to build it are closely linked. A good project manager will help collecting any missing domain knowledge, but ultimately it is on the architect to make sure that all the right questions have been asked.

And it is given that not all requirements will have been discovered before a development start or that they may change during development.

[sarchertech]

You realize that we were making software for decades before Product Managers existed right?

My senior year software engineering class had a whole section on requirements gathering.

[ajam1507]

This seems more like a failure of management and process than a problem inherent to autonomy.