A New Way to Manage Developer Tool Fatigue
A New Way to Manage Developer Tool Fatigue
What is Tool Fatigue?
It impacts everyone from auto mechanics to digital marketers. It probably even impacts heart surgeons. But it especially impacts software developers. What is it? Tool fatigue. Tool fatigue is a common affliction in many software development environments and is characterized by an overwhelming sense of weariness that sets in as more and more tools get added to the developer toolkit. Too many tools, it turns out, can result in developer productivity moving backwards. This, in turn, leads to the #1 contributor to developer unhappiness: lack of productivity, according to a recent Stack Overflow survey. The bottom line: after a certain point, more tools equal less productivity; resulting in unhappy developers and potentially bad code.
But how could more tools result in less productivity? First, it isn’t always the case that adding tools results in less productivity. As development teams begin adding tools to their suites, they generally see an increase in productivity. This makes sense; the reason to add the tools is presumably to address specific, previously unaddressed, development problems.
More tools, less output?
However, with each new tool added to the mix, developers must go through a new learning curve to become proficient, which takes times. Each new tool adds time to workflows; that extra time is worth it because, again, it addresses productivity-sapping development problems. However, because each new tool further dilutes the developer’s most precious commodity, time, the incremental productivity gain resulting from each new tool diminishes. Unsurprisingly, the productivity gain generated by continually adding more tools eventually hits zero. And, if yet more tools are added (“this one is the best I’ve ever seen!”) to the dev’s tool kit, incremental gains can actually turn negative.
The cause of developer unhappiness
This is where developer tool fatigue sets in. Developers are working longer hours less productively. They are unhappy. Work-life balance (which, not coincidentally, is the #2 cause of developer unhappiness according to the aforementioned Stack Overflow survey) suffers. Code quality declines. Bad things happen.
A common response from many dev managers and engineering leaders is, “No more new tools, we need to decrease the number of tools we already have.” While understandable, this mentality may be counterproductive.
It’s not the fault of the tools themselves. Most, presumably, are well-designed and efficiently address specific challenges. The problem is that there are too many and, frequently, tools don’t play well together. Integration is often rudimentary or even non-existent.
Two ways to address tool fatigue
1. Adopt platforms, not tools
By definition, platforms are software entities designed to easily and seamlessly integrate with other software. They’re typically instrumented with advanced APIs and frequently provide out-of-the-box integration with other platforms already in use. Using platforms rather than individual tools to address dev-specific challenges results in cleaner, easier-to-use, and more productivity-enhancing work environments. In many cases, the new “tool” appears to be a new capability in platforms devs already use, like Integrated Development Environments (IDEs).
2. Look for tool-reduction opportunities
As long as there are companies building tools for software developers there will be a temptation to evaluate and adopt some of those tools (and while we need to be vigilant in warding off tool fatigue, the availability of a rich array of innovative tools is not a bad thing). However, where possible, we should bias our evaluation toward tools that can replace one or (better yet) more tools already in our toolkit. Development organizations should ideally be constantly trying out new tools that might replace multiple tools already in use. By doing so, development teams can begin moving up the negative portion of the productivity curve shown above and unwind dreaded tool fatigue.
The CodeLogic Continuous Software Intelligence (CSI) platform
IDE integration
The CodeLogic CSI platform is a groundbreaking new addition to the universe of systems designed to enhance developer productivity. The CodeLogic solution is unique in two dimensions. First, it is a platform designed to work seamlessly with the primary existing IDEs and build pipeline tools that developers already use. This means IntelliJ IDEA, Microsoft Visual Studio, Microsoft VS Code, Maven, Jenkins, Gitlab and others.
Unparalleled visibility
Second, and more importantly, the CodeLogic CSI platform is the first and only platform able peer deeply into post-compile binaries, run time application behaviors, and database interactions in order to produce a complete, accurate, and up-to-date picture of the entire software environment developers are working with. This unparalleled visibility obviates the need for many older tools such as source code scanning and even some APMs.
Reclaim your time
In a development world bursting with a tool for everything, implementing a platform like CodeLogic CSI to the CI/CD workflow provides developers with critical software dependency data on-demand. By freeing up time otherwise spent wrangling too many dev tools to piece this information together—or spent addressing unknown issues downstream—the CodeLogic CSI platform helps developers predict breakage points, identify application vulnerabilities, analyze root-cause, and do what they do best: build.