“Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.” – Andrew Hunt (The Pragmatic Programmer)
The number of distinct tasks and considerations in software can be overwhelming. Fortunately, there’s software for that. Good programmers are always looking to improve, hate repeating themselves, and can build their own tools. As a result, software has a vast and rich set of tooling.
Tooling is also an easy way to differentiate developers and companies. It’s like putting your money where your mouth is. If good practices are important, then the right tools will be in place to make them easy. Joel Spolsky, StackOverflow co-founder, lists tools as 2 of his 12 measures for a good software company.
This section outlines common tools across the development process, a bit of what they do, and why each is important.
A good company keeps a strong pulse on their work definition, communication, and progress. Fundamental tools in this space include
Bug Tracker: A tool to keep track of all known issues with the system. Often includes assistance for prioritization, discussion, and progress tracking. Helps identify trends and put product quality at the forefront. Ignorance is not bliss with bugs, it’s lost users.
Support / User Feedback: Regular contact with users is critical to project success. Support and feedback mechanisms are the front line. They keep users happy and keep the project in line with their needs.
Backlog / Work Management: Agile, scrum, Kanban, or other. Use a tool to track active and expected work. These tools help create consistent expectations across teams and business segments, normalize process, and record requirements with reasoning.
Design / Build
Development is expensive. Make your developers as productive as possible.
Source control: Source control is the corner stone of collaborative development. It centralizes code, allows control over contributions, keeps a history of changes, and more. It is your primary tool for controlling quality and your safety net when code goes wrong.
Test frameworks: Testing changes how you write code, documents the system, and measures quality. Test has its own post, Test-Centered Development.
Package Management: These manage dependencies of your code in a way that is replicable across environments. They also manage versions, allowing each component to adopt changes at its own pace.
Editor / IDE: Interactive Development Environments (IDEs) bundle your core coding tools. Typically, a debugger, compiler, text editor, and write time assistance are closely integrated. Get to know your IDE well, you’ll be spending a lot of time in it.
Linters: Highlight syntax errors and enforces style to improve readability and address simple errors quickly
Code analysis tools: Automate insights into your code structure or quality. E.g. calculate function complexity, test coverage, or produce dependency diagrams.
Good companies use tools to safely and (in many cases) frequently distribute their software to users.
Automated Build & Release: Enable frequent, consistent, and stable distribution of code by automating the process. Often includes automated testing and quality checks too.
Infrastructure abstraction: These tools hide the underlying hardware from the developer, allowing the software to be deployed flexibly. They also separate the burden of infrastructure updates and scale. E.g. Containers, Platform as a Service
Staged Deployments: The practice of deploying code in multiple phases. E.g. promoting code through testing environments or partial re-direction of user traffic to new code. Allows more accurate testing of code in live environments, leading to safer deployments.
The application isn’t finished when it ships. A good dev shop uses tools to understand quality and usage when the software is in customer hands.
Logging: Usually textual messages providing insight into the software execution. Often used to record exceptions, track usage, or monitor performance.
Health monitors: Regular checks that your software is functioning as expected in a live environment. Typically send an alert when checks fail. E.g. UptimeRobot will call a url regularly and alert if it doesn’t respond.
User Analytics: Track user actions in the application to understand behaviors, usability, and engagement. E.g. Google Analytics
One of the most powerful ways to reduce coding time is to not code at all.
Third party packages are typically more flexible, better tested, and better maintained than anything you’d build in-house.
Most languages have a library of community-provided code packages that are free to use. Even supposing you do have to pay, a few hundred dollars is pretty much a day of dev time. Any more than a day of development or maintenance makes a pre-built solution the frugal decision.
Opensource has also revolutionized third-party code. Anyone can contribute or fork opensource code, which minimizes the risks. If the library loses support, or a critical feature isn’t available, consumers can always choose to do it themselves.
Build Your Own
The applications of software are vast, and pre-built tools won’t cover every need. If you find yourself doing a task more than once, build a tool for it. If the task takes half an hour and the tool takes 4 hours to build, the tool has more than paid for itself by the 8th use. Not only does it make the task easier, it is more accessible to the team, more reliable, and less stressful.
Steve McConnell go so far as to say this is a fundamental part of programming and nearly all large organizations have internal tooling groups (Code Complete, p. 721).
“Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.” – Andy Hunt
Powerful tools make programmers more effective. Use tools to facilitate important tasks through all stages of development.
Buying tools is most effective for common tasks, but don’t shy away from custom tools as needed.
The Joel Test, Joel Spolsky, https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
Code Complete, Steve McConnell, Ch. 30 Programming Tools
The Pragmatic Programmer, Andy Hunt and David Thomas, Ch 3 The Basic Tools
No Silver Bullet, Fred Brooks, Buy vs Build
How to Make Products Users Love, Kevin Hale, https://www.youtube.com/watch?v=12D8zEdOPYo