[noduerme]

I found this interesting:

>> Small decisions have to be made by design/eng based on discovery of product constraints, but communicating this to stakeholders is hard and time consuming and often doesn’t work.

This implies that a great deal of extraneous work and headaches result from the stakeholders not having a clear mental model of what they need software to do, versus what is either secondary or could be disposed of with minor tweaks to some operational flow, usage guidance, or terms of service document. In my experience: Even more valuable than having my own mental model of a large piece of software, is having an interlocutor representing the stakeholders and end users, who understands the business model completely and has the authority to say: (A) We absolutely need to remove this constraint, or (B) If this is going to cost an extra 40 hours of coding, maybe we can find a workflow on our side thet gets around it - or find a shortcut, and shelve this for now so you can move on with the rest of the project.

Clients usually have a poor understanding of where constraints are and why some seemingly easy problems are very hard, or why some problems that seem hard to them are actually quite easy. I find that giving them a clear idea of the effort involved in each part of fulfilling a request often leads to me talking to someone directly who can make a call as to whether it's actually necessary.

[bitwize]

Such an interlocutor was historically known as the systems analyst, but historically we've put programmers in that position, where they tend to do poorly.

https://www.linkedin.com/pulse/tail-wagging-dog-tim-bryce/

Systems analysis is about to make a roaring return, as the need for human programmers wanes thanks to LLMs generating all the code.

[noduerme]

I could definitely see myself moving into that role officially in a lot of places where I already unofficially am responsible for it, but I honestly don't know how I'd approach herding coders who were relying on LLMs to the point of not fully understanding the code-level interreliance of the systems themselves. I'd still find myself doing my current job, but with more cognitive load reading Claude code and trying to understand how these things were stitched together.

There's something to be said for attention, and the window of attention provided by a human who wrote something rather than an LLM that has to guess the intention of it, every time it reboots.

Any coder who understands what they're building could theoretically be a systems analyst for the greater part of what their code is going to be embedded in. This is a weakly referenced argument, but, dropping the lower links in the chain and substituting them with LLMs is exactly where I think communication is bound to break down. Or: You can try to herd cats all day, but if you move up the chain and all you have below you is cats relying on LLMs, you've just shifted the same problem up to your level in the organization.

[colechristensen]

It's almost always more productive for stakeholders to argue about the current solution that exists rather than the hypothetical one you're going to build.

[ozim]

I agree but there are downsides like shallow feedback.

There still going to be loads of explanation because „just a button” can have loads of stuff behind it like staring whole processing pipeline that is not visible for non tech people.