There was a ton of great feedback on last week’s article, in person and online, and most of the questions were about tools. I like to think those discussions weren’t driven by the thought of me grabbing an electric fence to test it.
- How do you decide when to get a tool? (Hint - pain points)
- How do you know which is the right tool?
- I’m starting out, what tools should I use?
Setting the stage
Farming and software development are lifelong professions that continue to evolve. From the outside, anything new appears to be a massive leap. Working daily in the profession you know these “massive leaps” are the result of compounding incremental improvements. Ideas coalesce, standards evolve, and tooling responds to the changing needs of its users.
True whether we’re talking the farm or software development. For example, the earliest “portable chainsaws” were wheeled and required two men to operate. They evolved with time into the Stihl in your garage today. Hudson began as a Continuous Integration tool and evolved into the Continuous Delivery tool Jenkins. Along the way it developed endless options for control of every aspect of the software delivery process.
There’s nothing more powerful than an idea whose time has come and that is most evident in tooling.
Let’s dive into tooling with an anecdote from Rands in Repose:
Even if you’ve never handled a chainsaw, you’ve probably used a handsaw. It’s a physical, grinding affair. It’s fun for about three minutes and then you start wondering… am I making progress? The brother-in-law had taken it on himself to use a handsaw on one of the trees. In his three minutes he’d sawed off… a branch. When Marty and I showed up, we dropped all five trees, cut up the trunks and branches, and stacked them into disposable piles in an hour. The lesson: the correct tool is exponentially more productive.
When do you need that shiny, new tool?
When you know where it hurts. It’s not the first, second, or even the third time. When you can clearly state the problem and you hear yourself saying again, “There has to be a better way.” There probably is.
Why wait? Why not get all the tools right away?
I wait until the current tooling is painful to use. It encourages a ruthless pragmatism in tool selection because everybody fetishizes tools. When people walk into a hardware store and see all the shiny new tools, they start thinking backwards. “If I had this, I could build anything.” Me too. I love shiny, new tools. I would love to spend half of each day testing every single new static site generator, programming language, or database technology that comes along.
It is tempting to put a primary focus on the tool instead of the problem’s domain.
Tooling for Junior Staff
I was eight when I felled my first tree, using my father’s woodworking handsaw. My younger brother and I took turns until we cut down a tree that was two feet in diameter. After starting a farm I needed fenceposts and timber for building livestock shelters. I began with a cheap yardsale chainsaw that was 40 years old and 40 pounds.
A mastery of process develops via pains and simple tooling. Start with the basics and don’t jump in the deep end until you’re ready.
Begin with a mature, reliable tool. There’s a reason they still make handsaws.
The same approach goes for software. Once you start shipping software, sometimes it breaks for your clients. So you start figure out the problem. Then you decide you want to automate the method you used to find that problem. Find the simplest standard tool in your domain for doing automated testing. Then write a few tests for the highest risk parts of your software.
Don’t start the journey with a Jenkins instance and 60 plugins configured for every eventuality.
Start simple. Once you know the pain points of your tool, you’ll be ready to find a better tool.
Tooling for Senior Staff
After a few years of using that chainsaw, I learned how to tune it up, sharpen it, and had enough experience using it to know there were better tools out there. That first chainsaw was exhausting to use for any length of time. Knowing all its weaknesses, I bought one that was many generations newer. It was lighter, safer, and more reliable. I could now cut wood safely for hours without tiring out. Having a better tool changed my strategy for cutting wood since the tool was no longer a burden.
Along the way I learned the new problem domains. I learned how to maintain complicated mechanical equipment, internal combustion engines, what conditions the machines will and won’t work in, and what things are still best done by hand. The pains of a sub-optimal tool taught me what I needed and gave me new skills along the way.
You know the pain points if you have worked in software for any length of time. You know where the sharp edges of your tools are and how best to avoid them. Remember years ago when you couldn’t commit too much code at once without crashing and recovering the version control system? I’m looking at you Visual Source Safe 6.
These days you have used a lot of tools that encompass a variety of technologies. You have a lot of experience with your tools. You know the pain points. You know when a tool is unfeasible for solving current pains. You dive deeper. Heading into newer and wilder datastores, third party caching and networking layers, or whatever next generation tooling will solve your woes. As you do, you find yourself with a growing knowledge the updated problem domain.
Tooling begins to become an extension of your strategy. Your goals grew with time. You went from “a better way to write this query,” or “stop breaking production” to “Delivering reliable software,” or “GPU accelerated simulation modelling.” Your view of tooling shifted as your goals shifted. Tooling is an element of your strategy.
Armed with the right combination of experience and pain points, you know if that shiny, new tool will solve your problem.
Tooling for Managers
The more wood I could produce, the more wood I needed. I had gotten into making furniture along the way and heating the shop with wood. I had helped friends build barns and houses and spent time working with a friends milling timber. We needed to produce. The tools weren’t the problem. We needed help. People to position logs, stack cut timber and boards, and operate all the machinery surrounding the process. It had become about people and logistics.
Your organization has grown. You could accomplish the same things with any number of tools, but you know that tools are just part of strategy. Since you have gotten so large, you need help to get everything done. Most of your time is spent organizing labor, logistics, shipping, working to make sure everybody has the same definition of quality that you do and continuing to deliver the best product you can.
Good tooling is a side effect of good strategy. Every aspect of your strategy shows in your tooling choices from management style down to coding standards. Each aspect informed by your experience.
As your focus has shifted, you rely more on senior staff for opinions and to clue you in at the first hint of a problem.
One day it happens — two respected senior staff members have different ideas for a solution. What now?
One recommends an older, tried and true technology and the other, an up and coming piece of technology.
We head back to where we began. Pain points. Contingencies. You focus on pain points of the problem and potential pain points in each solution. Once you identify those risks, your team at large can weigh in and and you can make a decision.
Was it the right one? Only time (and quality metrics) will tell.
Pragmatism fueled by a focus on pain points drives our tool choices forward.
Conclusions
Tools are the “how.” But what we create and why we create it matter most of all.
A sharp focus on where you spend your time coupled with strong definitions of success and failure should define your choice in tools. Not the featurelist on this year’s model or the shiny chrome housing.
There was a lot to say on this topic. Enough for a part two at some point.
How do you approach tooling?
- When did you last decide to change tools?
- How does your group decide on tooling?
- What’s the last big pain point your team had that convinced you to re-tool? And how do you manage the risk associated with that change?