For many programmers their bread and butter involves slaving over code written in a general purpose language, such as C++, C# or Java. These all require a text editor for modifying the program source code and a compiler for turning that into something the machine can actually use. Those working in the realm of the dynamic languages have a similar toolset, albeit with an interpreter or JIT compiler to turn their masterpiece into boring old machine code.
And for some this is where it ends too. The testing, deployment, documentation & project management fairies all take over now to finish off those other menial tasks. After all, the hard work’s been done, right?
As the software systems we are trying to create get more and more complex, so does the number and type of tools we need to use to get the job done. In some big corporations there are teams dedicated to testing and deployment, but that still leaves an awful lot that we need to cover ourselves. In the smaller shops you’ve got all that along with painting your office once in a while too.
We should always strive to use “the right tool for the job”, but that doesn’t mean that we have to buy an all-singing, all-dancing bug tracking system if our development practices ensure that our bug count remains low – a spreadsheet may well be “the right tool”. At least, it might for now. Later, if the spreadsheet becomes unwieldy (hopefully due a high demand for more useful features, not bugs) we can investigate alternatives then.
The problems we need to solve outside of our core code-writing activity are often varied. After the text editor (nay, IDE) and compiler (which is often chosen for us) the Version Control System probably comes next in the list as we need to manage our code-lines as we checkout, commit, branch, merge and spelunk on a regular basis. From there it’s a short hop to the Continuous Integration server that automates a set of build scripts and ad-hoc tools that even Heath Robinson would be proud of. Deployment is probably a similar affair. Even if “all” you turn out is an .MSI something has to produce that, and you’ll need to track your builds and symbols somewhere just in case a bug shows up in the field.
Oh, yes, and there is testing too. Unit testing forms the basis of many team’s testing strategy, with integration and system scale testing thrown in for good measure. Once you reach the outer layers of the system there are a plethora of tools to help with those really gnarly problems, like testing UI’s and web services. Although you will probably strive to create automated tests where possible, there is still a place for manual testing and that must involve some sort of tooling too, even though you might not think of it that way.
If your product is a system composed of many moving parts, such as for batch processing or a service, you’ve also got the support and monitoring sides to consider. The distinction between an “operator” and “developer” are so blurred now that you might have to do a spot of log trawling and live debugging followed by the creation of a patch that needs to be rolled out post-haste. Getting from “problem discovered” to “fix deployed” could well see the use of a tool chest that would make an electrician feel under-equipped. If it’s really serious there might be some major “glue” required to hold the system together until the correct action can be implemented, tested and rolled-out.
And that’s what this column wants to be about – how people solve the problems that allow us to do the other thing we actually think we’re being paid to do. Any discussion of text editors is clearly out of scope on the basis that it’s only mildly less contentious than discussing tabs and spaces. Similarly it’s not an excuse to rope in 3rd parties to write some “Advertorials” either. It’s a chance for jobbing programmers to open up their own tool boxes and let the C Vu readership know what kinds of cool stuff they have in there and how they use it.
The good thing about metaphorical tool boxes is that they are TARDIS like in nature and so can contain everything from the svelte and simple TR through to the powerful and mind-bending GIT. Yes, we can all read the manual on how TR and GIT might be used, but what’s more important is how do you use it? Why do you use it? What are some of the trade-offs that caused you to choose, say, the monkey wrench over the spanner? The aim is to try and convert some of that Unconscious Incompetence into Conscious Incompetence [1], or better yet into Conscious Competence by exposing new tools, or just reminding some of us about the old ones that are collecting dust because we’ve forgotten about them. Better yet how have you managed to make up for the shortfall in one tool’s feature set by using another?
Clearly the classic UNIX commands such as SED and AWK provide a huge source of inspiration, but I’m also hoping we can look further a field to the less obvious. For instance, have you ever treated .csv files and Excel spreadsheets as database tables to aid in testing? Or, how do you generate a unique build number? What about the kinds of information you put on a dashboard for your support team?
Sadly the one-way communication of these
pages will likely only wet your appetite and so you’ll need somewhere else to
go to delve into the finer points of how, what, why, when and where. For that
there is always “
So, pop open that tool box have a rummage around and see what interesting stuff you can find.
[1] http://chrisoldwood.blogspot.co.uk/2010/04/turning-unconscious-incompetence-to.html
Chris Oldwood
29 January 2013
Bio
Chris started out as a bedroom coder in the 80s, writing assembler on 8-bit micros. These days it’s C++ and C# on Windows in big plush corporate offices. He is also the commentator for the Godmanchester Gala Day Duck Race and can be contacted via gort@cix.co.uk or @chrisoldwood.