Casper’s seventh rule of enterprise is:
No evidence of a problem is not the same as evidence of no problem.
You'll often hear arguments like "we need to capture the numbers for this problem", with the implicit reasoning being that unless it can be measured, it simply doesn't exist. Or maybe that if problem is not bad enough for people to represent it in a chart, then it can't be much of a problem at all. But sometimes issues in enterprise creep up un you slowly, like boiling a frog.
The premise of the the boiling frog anecdote that if a frog is placed in boiling water, it will jump out, but if it is placed in cold water that is slowly heated, it will not perceive the danger and will be cooked to death.
Technical debt is a good example of something that whose danger is often not apparant. Technical debt has been well documented and studied, and yet it is actually quite hard to perceive in the day to day operation of software development. No one starts work on a Monday to find themselves overwhelmed by technical debt introduced on Friday afternoon. Instead, technical debt is slowly built up over many years, so slowly in fact that it is almost invisible.
The insidious thing about technical debt is that it is so easy to ignore. Does it take a month for new developers to configure their local environment? That’s unfortunate, but no one is productive in their first few weeks anyway. Does every new change require manual end to end testing to sign off? That’s not efficient, but is it really a big deal to click through the app manually every couple of weeks? Is the copied and pasted code littered throughout your codebase making it hard to implement new features? That’s annoying, but it’s only 3 or 4 copies of the same code, so just copy and paste your fix the same way.
Meanwhile, this state of technical indebtedness becomes the new normal.
The problem is that no one spends their time analysing or questioning normal. People don’t react with alarm to normal, and normal is no reason to divert attention away from the more immediate issues that need to be solved.
Unfortunately, normal might actually be a pretty terrible state to be in if you take the time to stop and think about it.
Next time a project is delayed, a feature couldn’t be delivered in full, or time just wasn’t available for proper testing, ask yourself if you are in the process of boiling the frog. You may just find that the water is actually getting a little too hot for comfort.