All people working in software development experience friction when they try to promote innovation. With innovation, I do not mean introducing fancy AI or blockchain in a web service, but any action that moves the status quo by more than an inch. Even changing a library is problematic sometimes!
Proposals to innovate are often welcomed with sentences like “We always did it the other way” because people prefer predictable mediocre outcomes to a potential gain that comes with a risk. For example, managers who need help can hire companies like Teddy Bear Inc., a startup of five people from Yorkshire, or Megacorp International, a famous company with a solid brand known worldwide. Picking Megacorp is more expensive, but it is easy to defend the choice when the project goes south. “If they can’t deliver, nobody can” right? That is an example of risk aversion, or, as I call it, the “Megacorp syndrome” since its prevalence in large companies (although startups are not immune). Risk aversion is an attitude that applies everywhere at every level for every activity in a company.
When dealing with large changes, I face the dilemma of rewriting vs patching. Both strategies have risks: even the smallest patch can end with ping pong between devs and testers or with production incidents. While rewriting is the scary unknown with high potential, patching is the universal safe option, and nobody is ever blamed for choosing it. The parallel between patching and hiring Megacorp does not end there. The Megacorps cost much more than the Teddy Bears Inc., so, project after project, hiring a Megacorp will drive the costs to the stratosphere just like constantly patching new features will create a monster of technical debt.
Developers mitigate the risk aversion of their managers by incorporating refactoring in the patching strategy. I never saw anyone blinking an eye if an apparently trivial change takes a week. However, developers do not have large margins, and that compensation is insufficient in the long run. Management with risk aversion will inevitably promote a culture that minimises short-term risk at the cost of software becoming a monstrous pile of spaghetti code with meatball-sized problems. Risk aversion is effectively a way to build “risk-debt” in parallel to the tech debt. Since every debt must be repaid, it will be necessary eventually to take the risks all at once to replace what has become a large legacy software.
Regardless of your role, do yourself a favour when you start with a project: discuss its lifecycle with your boss and bring alignment to your reports. It does not make sense to keep the code crystal clear if the plan is to throw it away in a few years, but if no end of life is in sight, risk aversion will only create a giant monster down the line.