5 ms·
> When you devolve power to a lower body, you are doing a form of central planning because you're determining what those lower bodies should be. So wee should d
by caseysoftware 11y ago
> When you devolve power to a lower body, you are doing a form of central planning because you're determining what those lower bodies should be. So wee should do it right. That might mean that states aren't the only body to consider.
In software development, we've moved power from a Big Design Up Front (aka waterfall) planned by a few to a series of teams, each with core specialties, areas of control, and many degrees of freedom but still have interfaces, agreements, and goals to tie them all together.
It's because we know that the waterfall process can't have all the information up front, can't see all the risks and opportunities, and can only be as good as the experience and foresight (sometimes guessing) of the few in charge who also happen to be the furthest from the problem.
Why is it bizarre to consider a similar approach to a much more complex system?
- matthewowen 11y agoI don't think it is bizarre. What makes you think I do? I agree that it's a great idea to delegate powers to lower bodies. But you have to decide what those lower bodies should be. I'm just arguing that the states (as currently formed and defined) might not be the best bodies.
- bsder 11y agoAnd yet our most reliable systems are all effectively Big Design Up Front (aka waterfall). And, in fact, the poster child for "agile" was the Chrysler Comprehensive Compensation which was a gigantic FAILURE precisely because of all the complexity which "agile" never handled. Complexity doesn't magically go away just because you break things into smaller pieces.
- jholman 11y agoC3 was a failure for whom? All of the planners and senior engineers went on to spectacularly successful careers as Agile "thought leaders". Sounds like a rousing success to me. :D I, too, find it funny that people whose main large-project experience is C3 use it as evidence that they should be trusted with anything.
- metasean 11y agoIt depends on what is being built. E.g., > It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors. > The product is only as good as the plan for the product. > Take the upgrade of the software ... a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages. > Don't just fix the mistakes — fix whatever permitted the mistake in the first place. > Ten years ago the ... group was considered world-class. Since then, it has cut its own error rate by 90%. - All from http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff Not every piece of software needs such an obsessive approach - but, there are pieces of software that absolutely do need such an obsessive approach! In other words, there isn't a single binary correct answer for every choice. There are some things that are best decided at the neighborhood level, there are some things that are best decided at the global level, and there are are many things that are best decided at levels in between. It seems to me a national approach, with significant input from the states, seems like a very appropriate level for something like an interstate road system. Particularly given our already successful history with the National Highway System [https://en.wikipedia.org/wiki/Interstate_Highway_System https://en.wikipedia.org/wiki/Interstate_Highway_System]. Why is it bizarre to consider an approach that is logical and has already been demonstrated to be effective?
- gdudeman 11y agoThis is a good analogy, but I think your takeaway is wrong. In software development, we change the team structure if we find that multiple teams do the same thing for the same customers. So, in this case, redraw the state boundaries.
- zhte415 11y agoWithout the end-user involved in the entire development process, with no BA, it is still waterfall aka 'fake agile'. Creating a division in software development creates a gap. Shouldn't even be sitting in a separate office / section of office / in that state of mind. It is not "in software development." It is product development.