3 ms·

I disagree. The problem started when people doing the flows and storyboards weren't informed or didn't understand the tech side. When waterfall was detailed pla

by JakeAl 3y ago

I disagree. The problem started when people doing the flows and storyboards weren't informed or didn't understand the tech side. When waterfall was detailed plans written by people in the know, it was great, but only as long as the engineers (programmers) actually read the design doc. But they stopped doing that and insisted on making it up themselves as they went instead. Good product developers can establish proper blueprints, but a good product developer needs to understand both what the user does AND what the programmer does. Then they can articulate a vision and proper information architecture and functional specifications that make doing the work as simple as following a blueprint/design document. Meanwhile, Agile has become this bloated mess with dedicated roles for everything that a producer or project manager used to do, and the project manager has been reduced to someone just tracking progress instead of informed architects beholden to programmers who refuse to read the well thought out and planned design doc. Before there was agile, there was managing complex design projects by Dubberly. https://www.dubberly.com/articles/managing-complex-design-projects.html https://www.dubberly.com/articles/managing-complex-design-pr... Such a process made sure all the appropriate questions were answered up front most important, what's the actual problem you're trying to solve, not what do you THINK the problem is you're trying to solve. In part I think programmers wanted to be more than just programmers. It's like a construction worker deciding the architect doesn't know what they're doing so they have to be the ones designing the house as they build it. Which may be true if the architect is an artist and not an engineer.

chasd00 3y ago
it takes a lot of professionalism to be an expert in a field and yield to experts in other fields. I think many software devs think they know everything and people are just worn down trying to work with them so you get all these different methodologies. Look at the disdain found on HN for marketing, sales, executives, any part of an organization that is not writing code. In reality, writing the code is maybe 20% of the overall effort in producing a successful software product.
psadri 3y ago
This may have come off the wrong way as a criticism of the people involved vs the process. My point is that iterative design processes tend to work better than waterfall (for new software projects). Architect / construction worker - sure. It is hard to iterate on a building - it has to be more less built as designed and therefore there is a huge onus on the architect to get it right the first time. Software is more malleable, at least at the start.

by JakeAl 3y ago

chasd00 3y ago

it takes a lot of professionalism to be an expert in a field and yield to experts in other fields. I think many software devs think they know everything and people are just worn down trying to work with them so you get all these different methodologies. Look at the disdain found on HN for marketing, sales, executives, any part of an organization that is not writing code. In reality, writing the code is maybe 20% of the overall effort in producing a successful software product.

psadri 3y ago

This may have come off the wrong way as a criticism of the people involved vs the process. My point is that iterative design processes tend to work better than waterfall (for new software projects). Architect / construction worker - sure. It is hard to iterate on a building - it has to be more less built as designed and therefore there is a huge onus on the architect to get it right the first time. Software is more malleable, at least at the start.