Afterwood
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.
Chris Oldwood
08 July 2019
Chris 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 via gort@cix.co.uk or @chrisoldwood.