Why Bother With Automation
a) Be constructively lazy. b) Repetitive tasks are boring and crap and invite screw ups. c) You will eventually screw it up. You’ve probably screwed up today. d) I want to computer to tell me I screwed up before anyone else notices it and while I still remember what I did. e) I want to easily be able to undo my screw up - and go back to what worked.
In more detail: I’d rather spend time to save time later, or keystrokes, or the amount of thought needed for a regular task. I’d rather a developer is thinking about the feature they are delivering and its quality, than a 20-something build step process for delivery. I’d rather building a release was an automation that ran easily almost daily, than a thing of fear and loathing done twice a year. It’s better to know it is broken right now, than 3 months away during deadline week when you are already panicking.
This relates to the cost of fixing things - and how this is amplified as the problem gets older and deeper - also known as the cost of rework. Doing it twice is bad, doing it once, and then having to spend months working around it before undoing then redoing it is even worse.
Software development is about delivering changes - and anything that makes that process less fraught, less error-prone, and stops the developer loosing focus on the actual feature is worth doing.
Remember that context switching is a mind killer for developers - every large cumbersome process causes one, and the longer and deeper it is, the more destructive it is.
blog comments powered by Disqus