ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinA Good Craftsman Knows His Tools

Overload Journal #91 - June 2009 + Journal Editorial   Author: Ric Parkin
Are you using the right ones? Ric Parkin looks in his toolbox...

At the highly enjoyable ACCU conference this year, I took part in a patterns hatching workshop. This took the form of a brainstorming round where people came up with names of possible patterns (and not just design patterns - organisational ones were also prominent), followed by further rounds where other people tried to fill in the details, for example what problem it solves, what sort of circumstance it applies in, and the consequences of the solution, both positive and negative (always good to remind people that a pattern is not a silver bullet and always has effects which lead to further problems to solve).

But one stuck in my mind as being oddly unsatisfactory: 'Use Tools'. We really struggled to fill in the details for this one. Initially it sounds uncontroversial: who wouldn't use tools after all! But in a way that's its weakness - if it's universally applicable, then it's not actually a very interesting pattern. Also, we couldn't really find anything much to say about the details - what sort of tools, what problem do they solve etc., as we could think of so many different possible things, but they were all to do with more specific ideas. I eventually came to the conclusion that it is just too broad a idea to encapsulate in a single pattern form, although there are lots of patterns within it.

Man is a tool-making animal - Benjamin Frankin

But it did get me thinking about tools. Until relatively recently it was considered that a defining trait of Humans was to be the use of tools. But recent discoveries that not only many primates [BBC] but many other species use tools [Species] , and even some crows are true tool makers including passing on new uses culturally [Crow] . But it is the sheer scale of tool use amongst humans that still impresses. Combine this with the ability to communicate, which helps to spread new ideas quickly, and it is easy to understand how an otherwise unremarkable species can dominate its environment.

So what is a tool? A useful definition is that they are something used intentionally to magnify our ability to do something. It could be as simple as using a picked up stone to break another in two, or using a branch as a lever to move a bigger rock than you could otherwise handle. More advanced is to deliberately shape objects to work as better tools, such as chipping a stone to create a sharp edge to be used when butchering, or sharpening the branch to become a spear. Increasing our strength is one possible improvement - better accuracy and repeatability are others, and all help to make best use of otherwise limited resources.

So what sort of tools do we use in the world of software development? We could start with the hardware - a modern computer is a general purpose computing tool. The really clever and important part is in fact the software that turns it into a specialized computing tool. A quick look at the history of computing shows that some of the really momentous breakthroughs were moving away from custom built to general purpose tools, which could be more easily built and then customised as needed. A prime early example was the Jacquard Loom [Jacquard] , which made making complex textiles easier and more flexible, because instead of having a different machine for each pattern (or relying on a slow error-prone human) it was a general machine that allowed the pattern made to be programmed and changed easily. A similar significant step was the creation at Bletchley Park of Colossus which was the first true programmable computer [CodesAndCiphers] . Before that, the machines used to crack codes were hardwired for a particular code - if the rotors on an Enigma machine changed, you had to physically rebuild your machines.

But Colossus and similar early machines were still pretty hard to program, using technologies such as a plug-board and cables to wire up your program. A real step forward was to create tools that helped you write programs. There are many different types, but we'll start with a major one that is the very bedrock of a computer - the Operating System. This provides the platform upon which every other tool rests, and so it influences hugely your choice of further tools. This could be a major restriction until you consider cross-platform development - with that you can choose a development platform distinct from the target platform your project will eventually run on. This is essential where the target platform isn't itself capable of hosting your development tools, which will be true of many embedded devices, mobile platforms, and games consoles. There can still be some lock in: if a vendor only produces the tools to run on a particular operating system, then you don't have much choice.

The operating system will often come with many simple utilities, which can be useful as a box of Lego bricks to build custom tools. Unix systems are notably rich in command shells that run script languages, and for small, specialised programs that take input, process it in some way, and pipe it on to the next program, which can make it easy to write the small utilities that ease day to day tasks. As an example, a few years ago I wrote a simple Integration Build Server. It was a simple bash script that kept an eye on the source code repository; if it saw the root time stamp change it would wait a until it hadn't changed again for 10 minutes (this was to allow people to check in a series of changes one by one); it then checked out the latest code, ran the build script (which itself tied together many different tools), captured the output and mailed the results to the development team. The script was only around a hundred lines long, and ran on both Unix and Windows (using a port of the unix utilities), but saved the team a lot of pain from broken builds and reliability.

The next obvious category of tools would be the platform for the actual product itself. This could be the major infrastructure such as database, web server, or content management system. These will often be tightly aligned to the choice of operating system, and often the choice is imposed on us by business or client needs.

The choice of programming language is another major choice, although one we can more often influence to some extent. It could be an interpreted language such as python, a web toolkit such as Ruby On Rails, or a traditional compiled language such as C++, or more commonly a combination of several different technologies. The choice will often be constrained by non-technical influences such as fashion for the latest cool thing, prejudice for or against certain tools, and the existing areas of expertise of the deciding team, and the ability to hire developers with knowledge in that area.

Then there are the tools that help you craft your product. The text editors, code browsers, unit test systems, debuggers, profilers, graphics editors, dialog layout tools and so on.

And finally there are the various ancillary tools that help you manage your team and the development processes - email, messaging tools, meeting calendars, UML editors, the humble word processor for documentation, source code repository tools.

All these tools come together to help you build your product, which is itself likely to be a tool for your clients to do their own work.

If the only tool you have is a hammer, you tend to see every problem as a nail - Abraham Maslow

We all come with a variety of experiences and history of using various tools. But beware: this can lead us into the trap of only considering the tools we are already familiar with for our next project, and rejecting those we have no knowledge of, or only poor experiences whether or not it was the fault of the tool itself. While choosing the unfamiliar is itself a risk, being closed to other options could lead us to use completely inappropriate tools, which can vastly increase our development costs and risks.

References

[A.P.R.I.L.F.O-O.L] http://accu.org/var/uploads/journals/overload90.pdf - contents

[Bickerstaff] http://en.wikipedia.org/wiki/Isaac_Bickerstaff

[BBC] http://news.bbc.co.uk/1/hi/sci/tech/4296606.stm

[CodesAndCiphers] http://www.codesandciphers.org.uk/lorenz/colossus.htm

[Crow] http://en.wikipedia.org/wiki/New_Caledonian_Crow

[Jacquard] http://en.wikipedia.org/wiki/Jacquard_loom

[Species] http://en.wikipedia.org/wiki/Category:Tool-using_species

[Tool] http://en.wikipedia.org/wiki/Tool

Corrections and Clarifications

Readers of Overload 90 may have noticed that an article - 'Array Problems: Range Iteration Logic for Object-Oriented Languages' [A.P.R.I.L.F.O-O.L] was advertised as on page 37 of a 36 page magazine. We have Swiftly apologised to the author [Bickerstaff] for this one-past-the-end error, and will endeavour to avoid a repeat during the next 12 months.

Overload Journal #91 - June 2009 + Journal Editorial