3 ms·

Are good ideas just destined to be corrupted? Some examples: Royce: "These are the flaws in the 'Waterfall model'" -> everybody looks at his diagram and uses i

• Zababa 5y ago
  Are these really good ideas if they can't survive the collision with the real world? While I don't doubt that there are lots of smart people behind them, knowing what you should ideally do and knowing what would be the best compromise, in reality, are two very different sets of skills. For example, agile was never going to work according to the rules, because "individuals and interactions over processes and tools" are not how most companies work. There's probably a parallel to draw with programming languages. A few people will use Haskell or Lisp or Idris and be at the bleeding edge, but most people are satisfied with Java that sometimes cherrypicks good features. Both of those seem to be rooted in aversion to risk, or (inclusive) managers making most of the decisions. I'd say that's because developers tend to have different values from other people, often valuing stability a bit less and "the right solution" a bit more.
  • damagednoob 5y ago
    > I'd say that's because developers tend to have different values from other people, often valuing stability a bit less and "the right solution" a bit more. You're hinting at what the original DevOps idea was trying to solve. The traditional view is that Developers value shipping features while Ops engineers value stability/uptime. It should be easy to see why these differing values cause friction between these two groups. The way DevOps was trying to solve this was getting _management_ to assign incentives/values/goals that would apply to _ both_ groups. An example might be increasing user engagement. Aligning these two groups should be the main takeaway. The reason why The Phoenix Project book was so successful was it perfectly described this adversarial relationship. I'd certainly seen the same thing playing out at several companies I'd worked for.
• Jtsummers 5y ago
  Yep. It happens over and over again. You can add Lean and Theory of Constraints to the list. One of the most egregious abuses of Lean I saw completely failed at one of the things that Lean (in theory) does best: Empowering employees. Instead of letting employees (the ones actually doing the work, in this case in a manufacturing setting) discuss with themselves, engineers, and management the issues and work towards solutions the managers (exclusively, they did not consult the engineers) would observe what happened in the production areas and "Lean" the process (identify waste) then they'd direct the workers on how to do their job better. This was really Scientific Management with a Lean skin. And it failed for all the expected reasons (worker rebellion, in effect). Theory of Constraints has, though with a reduced emphasis but it's still there, the same idea of empowering the actual workers (the ones who can see what's happening) to bring ideas up (if not effect them themselves). Every ToC implementation I've seen has been like the Lean one above, management (primarily) insisting on setting up complex observation techniques (because we need all the data!) and then issuing directives on what to change. Instead of, you know, actually observing themselves and encouraging workers to observe and improve. And like the Lean example at that old office, there was no incentive for the workers to participate. There was only punishment to be doled out if they failed to comply. Great way to win people over. With regard to the others, I think it's worth noting what they brought to the table and where they ended up failing. Royce's paper was presenting a kind of assembly line (the "strawman" waterfall model) that people wanted to apply to large scale software development. He then went on to elaborate on the issues with it. Some of the same issues, as it happens, that face real production assembly lines: late feedback, limited feedback, gross potential for producing the wrong thing or building it incorrectly and only discovering it at the end, forcing rework. Management and people like clean presentations. We like to think that we can have a nice and tidy flow and things will work correctly. Royce's elaboration on the model shows how to introduce the feedback needed to actually respond to when things go wrong. But like you said, people saw the diagram and ran with it instead of considering the rest. Offices still publish Waterfall-based development processes today, I know, I've had to talk them out of it. It's pretty and tidy but a failure in the real world, and a failure of planning. Plans are worthless, but planning is everything. - Eisenhower Making a pretty and useless plan is a kind of managerial masturbation. Temporarily satisfying, but produces nothing. Effort has to go into making real plans, even if they fail when they hit reality, because they'll prepare you for that reality. Agile was similarly corrupted. See Scrum and XP. XP was cargo culted into, it seemed, nearly every software shop in the 00s. No understanding of why the techniques worked (for some people), only an insistence that they must be done. If the people foisting it on the workers had bothered to ask, "Do you want to try pair programming?" they may have gotten some yeses, probably a lot of noes, and a few ehs. Some of the workers may have tried it and loved it, others hated it, and in the end the teams would settle into the practices that worked for them. Which was, you know, the point of Agile (now lost). And yeah, SAFe can die a fiery death. I'll bring the gasoline. It is an abomination, and a blight on our industry. Like with Waterfall, it's more about creating an inflexible plan than planning and responding. The antithesis of the intent of Agile. It will (and in my experience does, even when done "right" per the consultants) provide a boost initially (new processes always seem to) and then devolve quickly into meeting hell. DevOps has been, to me, one of the more tragic corruptions. Perhaps because it happened so quickly. TPP very quickly led to companies listing "DevOps" openings, which demonstrated a complete and utter failure to understand (assuming they read) the book. But it's also tragic because the idea is so fundamentally simple that corrupting it is almost like having everyone insist that 2+2=5. Rather notable that the Wikipedia page on DevOps manages to not even mention The Three Ways, which are literally the foundation of the idea. Instead it's primarily focused on techniques.
• cwp 5y ago
  Yeah, pretty much. But don't despair, this is how the industry progresses. First, elite practitioners identify flaws in the standard practices of some corner of the industry and figure out a way to ameliorate them. They give it a name so they can talk about it, write about it, organize conferences etc. They're mainly interested in disseminating this good idea. The idea becomes popular, and a cottage industry springs up. Some of the original proponents become consultants, but there are others who were early adopters, and many more who are jumping on the trend. You also get an ecosystem of open source and commercial tools. This starts to warp the original ideas, as they stop being about purely about improving results and incorporate a bias for generating more consulting or tool revenue. This drives wider adoption. Companies start looking for people with experience in the new thing, and people start putting it on their resume. It gets applied in situations it wasn't meant for, sometimes on purpose and sometimes by accident. You start to see "no true Scotsman" discussions where detractors claim they tried the thing and it didn't work and proponents claim they weren't doing it right. There's also cargo culting, where people who don't really understand the ideas try to implement the practices with varying degrees of success. Eventually things get watered down to the point where the terminology starts to just mean "good" or "cool". The actual practitioners stop using it because it's no longer useful for communication and it falls out of favour. But. All is not lost! The original ideas were good, and they've been widely disseminated. They get taught to young people joining the industry, and they start to be part of "how we do things." They don't need special names to distinguish them from "mainstream" practices because they are the mainstream. In fact, young people sneer at them because duh, without knowing what they were a reaction to. You can see this with Agile, Lean and DevOps. On the business side, "disruption". The cycles are slower and maybe less intense in more CS and pure coding domains, but you find it there too with scripting languages, object oriented languages, TDD. Functional programming is leaving the consulting phase and seeing wider adoption. This is probably not how we'd like to think things work. But they do work.