Many people are risk-averse. Chris Oldwood considers this position – in verse.
Don’t change the specification! We made a plan, we should follow it to the letter, so what if customer feedback can make the product better. The schedule’s secured and the team’s been chosen, from here on in the deadline’s frozen.
Don’t refactor the code! The code isn’t broken, there’s nothing to fix, so what if the author used incomprehensible tricks. If it was hard to write it will be hard to read, a 10x developer doesn’t come cheap.
Don’t upgrade the libraries! We already use all the features we require switching versions is tantamount to playing with fire. We can save on testing when things stay the same, minimizing QA is the name of the game.
Don’t switch compilers! We know how the tool works, we’ve got the build stable, so what if compliance makes the code more maintainable We’re here to add features not become a language fanatic, idealism needs tempering; look to favour pragmatic.
Don’t alter the configuration! The support team have a play-book, it covers all cases, tinkering with settings from now only leads to red faces. The set-up has hardened it took weeks to achieve, now is the time to demand a system-wide freeze.
Don’t change the platform! The architecture’s formalized and infrastructure’s mature, we have an enterprise contract which is there to ensure that there’s someone on call when things go awry while we’re paying good money it’s not going to die.
But change is inevitable! Heraclitus said: everything changes and nothing stands still, for some it’s an assertion to swallow, a bitter-tasting pill. You can’t mitigate risk by instilling fear, instead embrace it, and make change something the team will revere.
is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it’s enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race and can be easily distracted.
