Thanks again for the newsletter which I find entertaining and extremely valuable. One of the features I've found most useful are the tool recommendations. Through them I've discovered several tools I've come to rely upon such as Ed Sutter's excellent uCon HyperTerminal replacement. Ed is very responsive to questions not covered in his comprehensive documentation and has also proven open to reasonable feature requests.

I'd like to recommend a couple software tools for inclusion in the list.

ack! - a Perl script which functions like a project aware recursive grep for programmers. It can be configured to search in only file types and/or directories of your choosing. This capability allows me to pinpoint search results of interest without having to wade through pages of matches which aren't really interesting. It is aware of typical file extensions for many programming languages but can be customized to support new ones as well. I use its support of parameters within environment variables to be able to limit searches to platform specific portions of our code base.

Hex to ASCII text converter - Like most programmers, I have an unreasonable hatred of repetitive and tedious tasks like converting hexadecimal byte values in memory dumps to their ASCII equivalents. This web based tool allows me to paste a group of hex bytes, words, or longwords and see their ASCII equivalents immediately.

I couldn't agree more with your perspective on programmers. Programming or coding is an element of software development. The entire design process covers a lot more than that. Saying the software development is just programming is like saying engineering is just drafting or PCB layout.

However I think the author of the quote might actually be on your wavelength, just expressing it differently.

One way to think of this is that software is indeed too important to be considered just programming.

The other element of this is that software is also just a component of a system. We develop embedded systems which consist of custom computing hardware platforms, the software that runs on those (sometimes multiple pieces of software that form a system between them), Internet based support systems and the ecosystem they live in such a computer or mobile device applications and utilities. The design of the entire system is important and not just one element of it on its own. We make decisions about what is achieved using either hardware or software and what could be done either way and then decide on the best approach to take. Each decision has benefits and ramifications.

So it is way more than just programming.

Interesting piece inspired by the quote. However, I think that software engineering may actually be much older than anyone realises. True we have not had programmable electronic computers for very long in human history but if you look back even before Ada Lovelace was born (acknowledged as the first person to use stored programming in a computational machine). The forerunner of the Jaquard Loom was a loom by Basille Bouchan (1725) which used punched card as the pattern store. However automata, in general, have been with us for a lot longer and probably appeared in the times of Greek mythology. Somewhere in between automata that could do a number of tasks dependent on the selected programme of actions would indicate that, even though it was not called such, software engineering has been around a very long time.

This will raise the question why we still have software that is buggy.

A lot of it is the current attitudes pervading society. The need for the quick fix, want it now mentality that has been growing more prevalent.

The well practised craft of applying sound engineering processes and procedures and being imaginative enough to foresee where problems might be posed, for some design paths, should all culminate in selecting and building the right and robust solutions to any need.

As I always had drilled into me. Proper Planning Prevents Poor Performance. I also aim to have requirements that meet the criteria of being Clear, Concise, Coherent, Correct Complete and Confirmable with sufficient documentation to support a provably valid solution and lack of unwarranted risk. Sadly, most software that I see presented to me often lacks sound documentation, containing instead plenty of ambiguous statements that often conflict with other information in the same package. That sort of software has a "hacking feel" to it and is not worthy of the "engineered" accolade.

My process and methods have also been proven over time as one robotic software system handling highly hazardous material is still in operation since 1985 and is now being called to operate until 2030.
None of my products come back needing software maintenance as my techniques strive for longevity. Right first time every time should be the delivery mantra of every engineer whatever discipline they practice.

"Software is too important to be left to programmers."

Engineers like to speak in analogies. Consider this: Programming is to software engineering as drafting is to mechanical engineering or board layout is to electrical engineering. Engineering, whether electrical, mechanical or software, is about design. A mechanical engineer represents his design by means of a drawing which is then handed off to a machinist to be built. An electrical engineer represents her design as a schematic which is then handed off to a technician to be laid out and fabricated. The unique characteristic of software engineering is that we are able to build our own designs through programming without the necessity of representing the design in a human-readable fashion to be handed off to a separate person for fabrication. That is a mixed blessing. There is a great temptation to start programming before the design is finished (in some cases even before it is started) and often without an implementation-independent representation. Discipline is required to avoid premature programming which inevitably leads to poor code. Managers often exacerbate this temptation by asking "How many lines of code have you written?" Instead they should ask "Is the software design document completed (and reviewed)?"

Don't document the code; code the document!

I read with interest your writings (and readers' replies) about craftsmanship. The good-tools/good-craftsman points are well covered by you and other commenters - I accept the premises, and agree with most.

An aspect of our work that I consider part of craftsmanship (perhaps a better term is workmanship) that doesn't appear to me to have been mentioned so far is consistency in coding. This is not the same as style of coding - coding style itself is not nearly as relevant as is selection (or definition) of a coding style and adherence to it tat is conscientious, consistent, and predictable.

When reading someone else's code, I find nothing as distracting and deleterious to readability and comprehensibility as sloppy, inconsistent coding. To me, it says a lot about the writer's attention to detail. In the same way that big blobs of solder all over the place make me wonder what dead shorts lurk in a circuit, shoddy coding makes me wonder what dangling pointers, off-by-ones, or race conditions lie in nearby shadows.

One could argue that this problem is easily solved, or at least contained, with beautifier tools, but hosing down ugly code with such a tool isn't necessarily a good idea, either: it discourages that ever-important attention to detail, and may destroy important information encoded in careful, consistent, albeit unorthodox indenting, for instance.

Some languages encourage consistency better than others, I suppose, but I don't believe language choice has much bearing on it, either. One can write clear, consistent C with roughly the same effort as for assembly, FORTRAN, Haskell, or PHP.

Furthermore, it's a hollow argument, to me, that being a "neatnik" with the source code is a distraction. Perfection to the point of diminishing returns is possible in any pursuit, but it takes roughly the same effort to check in well-laid-out, readable code as it does to grunt out eleven hundred lines of crap, and it's a huge favor to oneself, or anyone tasked with reading the code.

You might also make much of the fact that "A bad craftsman blames his tools", when you understand that the craftsman, as part of his apprenticeship had MADE his own tools.

I think that the software craftsman who puts up with crap software tools should write his own.....