We recently repaired a fence in our back yard. Not very exciting, but it provides a good case study in how to think about getting the right tools for the job. Or not getting the right tools. And the trade-offs inherent in improving the tools vs just getting a job done with what you have at hand. Which is something all software developers should have sympathy with.
The Job
The job we did was nothing major. We dismounted some old boards that were starting to rot. We bought some new boards that required sawing to length and shape. They had to be painted and mounted in place of the old ones. The critical tasks for tool support were the sawing and screwing.
As it happened, we used an old manual miter saw and manual screwdrivers. Clearly, the better tools would have been an electric screwdriver and a power saw.
But we didn’t have those available at the time. When we have done major jobs in the past we always borrowed them from family, and since it happened fairly infrequently, there seemed to be no immediate need to buy tools ourselves.
Which got me thinking that this is rather analogous to some situations I have seen in the software and technology world. Both on side of selling tools, and observing engineering departments adopting (or not adopting, as it were) tools and flows.
Spending Time to Save Time
The fundamental question is one of having to spend to save. Time and money. I guess everyone has seen the cartoon where a couple of stone-age guys are pushing a cart with square wheels, and another guy stands on the side showing a couple of round wheels… and the square wheels guys say “no thanks, we are too busy.”
The point is that improvement takes some effort and investment, and that not improving is stupid. However, rarely is the real world that simple. The time required to get a return on investment might be significant.
To take our case, how much time does it take to use the tool we already have and some muscle power, compared to going to the shop to buy a power tool and apply it? More significantly, how much time does it take to decide just what buy?
Determining just what is needed takes time. Doing product research on the available options takes time. Weighing costs and benefits takes time. And in the end there is a cost as well.
Buying a randomly tool in the right category might work, but it might also turn out to result in annoyance and misery. Getting stuck with something bad just because the process was quick is not necessarily a win.
Doing it right is better long term, but it also increases the transaction cost. In the end, it was easier to just use whatever was at hand. Maybe we will go buy some power tools the next time we need them.
Compared to Software
The comparison to software tooling and automation is obvious.
Standard wisdom is that everything that can be automated should be automated. Automated processes are good processes. And if there is a tool that can solve a problem, it should be obtained and applied. Doing things manually is bad. Tools are good.
But automating things requires selection of technologies, coding the automation, fixing the errors that occur, etc. Which takes time. As XKCD #1319 illustrates, as a counterpart to the square wheels cartoon.
The investment needed to acquire a tool or automate some process might outweigh the benefits even in a professional setting. This is well-known to anyone selling software tools – the dreaded return-on-investment calculus. It is not enough to have a good solution to a real problem, it must also actually come out as a benefit after factoring license costs and integration time.
Another reason that automation and tools do not get applied can simply be a matter of analysis paralysis. It is clear something would benefit from automation or better tools, but it turns out to be very hard to actually make the decision to select one option.
Of course, we do have the square wheels case. Everyone has seen teams get stuck in delivery mode, with no time to do process improvements. They do the job with what they have at hand, and trying to have a discussion about how things could be done better is just annoying them and wasting time that is needed to do the job. What they have might even seem good. Getting out of that is a management and leadership problem, not an engineering problem.
Give engineers a chance to build automation and apply better tools, and they will invariably take it. Tools are fun. Improvements are fun.
However, if you do something only rarely, it is rational to do it manually and with poor tools. The time it takes to improve outweighs the time saved. I can use a manual saw for a few boards, it is not a big deal. It might not look very impressive and is definitely unsophisticated. But it gets the job done here and now with minimal mental and monetary overhead.