3 ms·
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, knowin
by 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.