Title: A Personal View

When I first started programming Francis used to insist that programming was not something you did at a computer. In the days of paper tape or punched cards this was easy to see because you had to transfer your code to the input medium. If the program failed you then had to work out why and correct the physical representation of your source code. This allowed you to focus on the process of writing code and also made you reluctant to 'try it and see.' The advent of teletypes began to break this down. It began to become possible to debug your code interactively. In my view this was not a step forward.

Availability of desktop machines only aggravated the problem (unless, like Francis, you were having to hand code in hex or octal - his first machine was a cassette driven 380Z and he did not have an assembler). As soon as reasonable compilers and programmers' editors became common it became easy to patch your code and try again. Francis used to insist that all modifications to code were worked out on paper (a print out of the previous version was acceptable). God help you if he found you amending code without a written version beside you. I have always been grateful for this early discipline as it helped focus on programming as an intellectual exercise. Like most, I use a word processor for writing these days but I keep a clear difference in my mind between the process of generating source and the process of compiling and testing it.

So what tools do you use for your coding. If you just use an IDE then you are at about the level of the DIY expert who buys flat-pack kitchen cabinets, assembles them and mounts them on the wall. You can always spot this kind of DIY work because the cabinets never quite line up. Professionals also use flat-pack kits but they know that they should be using a few other tools and skills as well.

Let me start with documentation. It is not enough to use the assembly charts that come with the product, and relying on the help files shipped with your IDE are also only part of what you need. A good reference library is essential. Depending on the level at which you are working you will need anything from a single good language reference to a couple of shelves of books covering everything from design, through platform specifics to books on algorithms and language (probably more than one language). Not only should you have these books but you should have a working knowledge of them. Anything less and you are a hacker.

The woodwork teacher at the school I went to had a rack of pencils on his desk marked 'Word Processors.' He was right. The specific tool is less important than what you do with it. Before you started a woodwork project you had to describe your objective in both words and diagrams. The same should apply to a program project. So you should have tools that will produce diagrams as well as ones to capture words. With these you should produce the project specific documentation. I know many hate doing that, but would you attempt to build or modify a house without any plans? You would? Then you must be a cowboy builder.

Now consider what other tools you should be using. If you were an electrician I hope that you would include a test-meter in your toolbox. Testing wiring should include detection of unconnected earth wires as well as swapped live and neutral wiring. Putting a switch in the neutral wire rather than the live one may appear to work until the day your customer electrocutes themselves on an apparently off socket. In other words an electrician's tools include more than those required to install circuits in your house (or they should). As a programmer, what tools are you using to ensure the correct connections between parts of your program. Do you use Lint or an equivalent? If not why not?

Do you check the parts of the code that are only used when something goes wrong? You don't? When was the last time you checked your smoke alarm or your burglar alarm? Do you think fire extinguishers should just be left gathering dust? It is no good having emergency equipment if you do not know it works. Every time you change a program the relevant 'emergency' code should be tested. Of course this takes time (though, with proper design, most tests can be automated) but not near as much time as will be wasted when an escape route fails.

All engineering involves a certain amount of pragmatism, and given time and cheap resources the ancient Roman method of building aqueducts demonstrably worked but I doubt that the slaves who were killed during the failed attempts would agree that it was a good design mechanism. Things like the Comet disaster (the first commercial jet passenger plane that blew up several times before the designers realised that the problem was metal fatigue not sabotage) will happen but responsible engineers learn from their disasters (the Tacoma Narrows suspension bridge is another example).

Too many software developers are neither professional nor engineers because they do not learn from their mistakes, and usually do not even admit to making them.