3 ms·
> ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Usually the indivi
by fzeindl 3y ago
> ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done.
Usually the individuals doing the work do understand that, but it is really hard to properly divide work and describe requirements. Why people try do divide it in even smaller tasks which increases this kind of complicated creative-writing work is beyond me.
> We realised that waterfalls that start with months of requirements capture followed by months of BDUF aren’t a great idea.
What we should have realized by now is that we never did waterfall right because it's inventor Winston Royce required it to be done TWICE for each project. Two iterations.
What this world needs is Atlassian hiring a number of work psychologists and theorists and have them streamline JIRA based on their learnings. Not in a UX "I want to create a story"-story sort of way. But in a "How do I deal with 50 tickets that are vastly different in quality?" sort of way.
They should answer questions like: "How can we make it so that the user always immediately knows whether to put this text in JIRA or confluence"?
Then Microsoft needs to hire the same people and improve text creation in outlook.
- namaria 3y ago>What we should have realized by now is that we never did waterfall right because it's inventor Winston Royce required it to be done TWICE for each project. Two iterations. Reading the original waterfall paper was eye opening for me. I saw that we're falling into patterns that are decades old. Someone insightful tries to explain that learning and building are two sides of the same coin, and companies read it as "ok, I need a learning team and a doing team" and run with it in the wrong direction. Taking the conceptual structure of some paper of manifest and applying it cookie-cutter style is missing the point entirely. What Conway and Royce were trying to convey is that the social process that underlies software matters. What people do with it on the field is using the examples employed in the explanation and mistaking them for the solution to their lack of respect for the intricacies of social processes.
- uoaei 3y agoA somewhat related tangent is the idea that "writing is rewriting". Hardly, if ever, is a first draft suitable for publication, not just because it's rough-hewn or unrefined but also because requirements for some chapters change once others are written. The feedback loops between dependent parts of a written piece are dynamic, not static. (Yet another reason why LLMs are so limited: they take their earlier writing as sacred and unchanging as a direct consequence of their autoregressive structure.)
- fzeindl 3y agoYou might like the book "The heretic's guide to best practises".
- namaria 3y agoLooks very interesting, thanks for the tip!
- talideon 3y agoPeople keep saying Royce invented Waterfall, but he didn't. At most, he used it as a straw man. What Royce actually advocated was an iterative model. You're right that his approach recommended at least two iterations, but not that his approach was the Waterfall model.
- datavirtue 3y agoWaterfall also uses an iterative model. Inescapable when building software. The myth needs to die so we can progress. Waterfall, as a typical corporate tech fad, WILL emerge eventually.