4 ms·
> Didn't we start by trying to plan ahead? There's a reason we have moved to agile. "Everything was waterfall and then came agile" is myth, but yes, it looks l
by clarry 7y ago
> Didn't we start by trying to plan ahead? There's a reason we have moved to agile.
"Everything was waterfall and then came agile" is myth, but yes, it looks like it's fashionable to no longer try to plan ahead. I'm not convinced the reasons are good, and I'm not convinced the craft of planning ahead was ever perfected to the point that anyone could say it doesn't work.
Scrum, XP, Agile all date back to the 90s when one server running PHP or Perl (with SQL injections) passed for software and others were still re-inventing basic data structures in C (and then gasp C++ with templates!) from first principles... The methodology, tooling, rigor, and collective experience in software development has taken leaps in the past two to three decades. Likewise, understanding systems and planning ahead has become so much easier. If only people took it seriously and spent as much effort on it as they spend on fad-of-the-year frameworks.
People just stopped trying, and when I look in software projects now, there's hardly ever anything resembling a model of the software that you could use to test new ideas "on paper" to see how they fit the given problem and current application.
People aren't even trying, just like they aren't even trying to achieve correctness: https://news.ycombinator.com/item?id=22224054 https://news.ycombinator.com/item?id=22224054
The less you try, the harder it will be.
> In software if you know what you are doing ahead of time you are not really innovating and you might as well be using an existing system.
I think the vast majority of software is boring and not even meant to be innovative and indeed would be best written using an existing system, but customizing these to the specific needs is just another can of worms. As with bridges, you can't just copy & paste an old bridge to a new location and use it as-it is, you need to design it given the locale and other constraints. It's still probably going to be yet another relatively boring bridge with no innovation.
And indeed a lot of software work is all about using existing systems, but perhaps at a lower level than you posited. Customizing complete off-the-self packages does happen, but it's more common to glue something "new" (but not innovative) using existing frameworks, libraries, services and glue languages.
You still need to design to do it right. But even here people seem to rush ass-first into whatever kit looks fashionable now.
- moron4hire 7y ago"Not trying" is not new. The problems with both Waterfall and Agile is that nobody really ever did them the way they were intended. Waterfall was supposed to include prototyping during requirements gathering, specifically to aid in discovering constraints. Agile was supposed to give equal footing to all team members and not let the project manager spring new constraints on the team without planning for the change. Neither of those things happened very frequently, because our modern business culture treats knowledge workers as interchangeable minions, and management as unassailably perfect. Yes, people don't do their jobs. That's not the fault of the process that they are failing to adhere to. Indeed, no process of any type could ever save them. It's the culture that is wrong. So, in a roundabout way, I agree that Agile isn't the solution. No bottom-up process will ever succeed, because at the end of the day, the failure of the team is always the fault of the leader.
- bostik 7y agoAgile as a named methodology may date to 90s, but the concept of rapid iterations, incremental improvement, and constant feedback cycles has been on the books since at least 1950s. The last time[0] I vented on the subject, I had to dig out the research papers I keep on my desk, because there was more than passing curiosity. Oh yes. I keep these on my desk so I can quote them when needed. Check out this research paper from your nearest sci-hub entry point: - DOI: 10.1109/MC.2003.1204375 ; "Iterative and Incremental Development: A Brief History" --- 0: https://news.ycombinator.com/item?id=20563125 https://news.ycombinator.com/item?id=20563125
- qznc 7y agoFully agree. I wrote myself a summary at some point: http://beza1e1.tuxen.de/waterfall.html http://beza1e1.tuxen.de/waterfall.html
- raiflip 7y agoThe binary thinking in this thread strikes me as odd. Is it bad to try and plan everything 6 months ahead of time? Yes. Is it also bad to fly by the seat of your pants and only plan 1 week ahead? Also yes. Instead, why don't we plan out by some intermediate time period. Say, 3, 4 weeks ahead of time. Or whatever time horizon ends up being the most efficient.
- nradov 7y agoYes there is no single correct planning horizon. The optimal horizon is proportional to requirements stability. At the extreme when requirements flux is extremely high then the best approach can be a Kanban process, planning no more than a day in advance.