PDF
Software Development Tools: Cautionary Tales
I am writing to express very positive feedback on the software development tools issue (Queue 1(6), September 2003). In particular, David J. Brown’s interview with Wayne Rosling, Google’s vice president of engineering, and Michael Donat’s “Debugging in an Asynchronous World” were incredibly well written and insightful.
Your magazine provides concise explanations of important technical details in a language that is clear enough for all engineers to understand.
Matt Elberson
I loved the recent software development issue (Queue 1(6), September 2003), which included submissions by Queue readers on their favorite debugging practices. Although I was hoping that some people out there use more cutting-edge tools than I do, my meager homemade tools seem approximately state of the art.
A future survey could target developers whose methods are way beyond the current state of practice to see how they debug big steaming piles of code. For instance, it would be good to hear from those who use tools or techniques that others have not heard of, and to also find out about lighter-weight tools that developers can take up and use in a short time. For instance, CRC (Class Responsibility Collaborator) cards rather than UML (Unified Modeling Language), Quality Function Deployment (QFD) for needs analysis, invariants, Tony Hoare’s logic for partial correctness, and so forth.
Kurt Guntheroth
The most helpful tool that a programmer can use, whether for initial development, debugging, or maintenance, is a well-designed programming language. Unfortunately, most programmers (or their managers) choose poorly designed languages while ignoring aids that have been around for decades.
A good language has strong, mostly static, typing. Nearly all of the really ugly bugs can be detected as soon as something goes wrong, if not earlier, with such a “type-safe” language. For example, the majority of the steady flow of newly discovered, root-exploit security holes are described as “buffer overruns.” With a type-safe language, every one of these would be detected at the point of the overrun—before access has been gained. Although type-safety is at least 32 years old to this day, it remains little used.
A good language is simple enough for the average programmer to understand. Although the most popular languages require 300 to 400 pages to define, well-designed languages are described in 35 to 50 pages—and even then they’re a challenge to understand. From many years of personal experience as a “language lawyer,” especially in industry but also in academia, I can tell you that the majority of programmers don’t come close to knowing the details of their programming language.
The notion that they don’t need to is naive. It’s true, one can write a large amount of code with only a vague, tutorial-level familiarity with the language. Before long, however, programmers who work this way run afoul of one of those arcane details, usually inadvertently. And when this happens, a single incident can consume more time than hundreds of lines’ worth of routine coding.
A good language is defined. Poorly designed languages have large spaces of “code” that will neither cause an error message nor behave in a predictable way. This is just as dangerous as—and more insidious than— excess complexity, because it is impossible for mere mortal programmers to avoid straying into undefined territory by accident.
For reasons I don’t understand (in some cases, I would even expect the opposite), good languages breed programmers with good habits. Programmers who primarily experience bad languages consistently show the lowest level of the very discipline required to cope with those languages. There are very few exceptions.
Rodney M. Bates
Coding for Readability
I read Diomidis Spinellis’ “Reading, Writing, and Code” (Queue 1(7), October 2003) with great enthusiasm. The topics are very relevant as I have written lots of software over the past 20 years—and have read even more software.
I hope to read more about this in Queue.
Donald E. Amby
Originally published in Queue vol. 1, no. 9—
Comment on this article in the ACM Digital Library
© ACM, Inc. All Rights Reserved.