April 17, 2017
Do It AnywayIn my previous post, I suggested that developers take the necessary technical authority that managers are often unwilling to give.
If I could summarise my approach to software development - my "method", if you could call it that - it would be Do It AnywayTM.
An example that recently came up in a Twitter conversation about out-of-hours support - something I have mixed feelings about - was how temporary fixes applied at 2am to patch a broken system up often end up being permanent, because the temptation's too great for managers to assign the fixer to seemingly more valuable work the next day.
Think of out-of-hours fixes as being like battlefield surgery. The immediate aim is to stop the patient from dying. The patient is then transported to a proper hospital for proper treatment. If the patient's intestines are being held in with sticky tape, that is not a lasting fix.
We've all seen what happens when the code fills up with quick'n'dirty fixes. It becomes less reliable and less maintainable. The cumulative effect increases failures in production, creates a barrier to useful change, and hastens the system's demise considerably.
My pithy - but entirely serious - advice in that situation is Do It AnywayTM.
There are, of course, obligations implied when we Do It AnywayTM. What we're doing must be in the best interests of stakeholders. Do It AnywayTM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y'know. Like professionals.
And this is where the rubber meets the road; if managers and customers don't trust us to make good decisions on their behalf, they'll try to stop us making decisions. It's a perfectly natural response. And to some extent we brought it on ourselves - as a profession - through decades of being a bit, well, difficult. We don't always do things in the customer's interests. Sometimes - gasp - we do stuff because it benefits us (e.g., adopting a fashionable technology), or because it's all we know to do (e.g., not writing automated tests because we don't know how), or just because it's the new cool thing (and we love new cool things!)
If we can learn to curb our excesses and focus more on the customer's problems instead of our solutions, then maybe managers and customers can learn to trust us to make technical decisions like whether or not a hot fix needs to be done properly later.
Posted 1 week, 3 days ago on April 17, 2017