eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
MIT math professor Arthur Mattuck once famously began a lecture by saying, “Suppose we have a 1-by-1 matrix, also known as a number.” I dont believe he had software engineering in mind, but Im going to hijack the thought to argue that systems should be built to handle general cases, unless this means unreasonable extra cost in development effort or resource consumption.
A “general case” is not, of course, merely a “probable worst case.” Allocating fixed-size data structures in applications, attempting to anticipate the largest likely problem that will be solved, is an infamous error.
As I recall, several of the failures in the classic 1990 paper, “An Empirical Study of the Reliability of UNIX Utilities,” were bizarre results that occurred when a utility program was fed an input line of more than 80 characters: the length of a standard terminals input line at a command prompt, and in turn probably a legacy of the original punched card. That paper prompted much discussion in its own time about the pursuit of benchmark performance as a force affecting standards of software integrity: a discussion that continues today.
That study is one of a family of reports on an entire class of software failures, and inspired a recent update that looked at both Unix and Linux utility software: The latter reported the somewhat disheartening result that “Four percent to eleven percent of the utilities we tested failed, either by crashing or by looping infinitely.” Sigh.
Another view of what it means to handle a general case, and to think of a number as more than a simple value, arose in my conversation with Allen Razdow, senior VP of strategic planning at Mathsoft Engineering & Education Inc.–up the street, as it happens, from MIT in Cambridge, Mass. “If you have an XML representation of a yield strength of a certain steel,” Razdow suggested, “you can put in the ASTM number, and the units, and a time stamp, and even a checksum that can verify that nothing in that structure has been changed: When that gets cut and pasted, you wind up with something much more robust than just a number.”
Razdow marveled during our conversation that “the whiteboard in an engineers office probably has a cost justification somewhere in the files, but theres nothing like that kind of audit trail for what gets written on that whiteboard every day–and for the decisions that get made as a result.”
When engineers choose their own calculation tools, Razdow added, “40 percent of them choose spreadsheets.” In most cases, thats all thats there, in addition to the engineers own handheld calculators. Mind you, even calculators can have marvelous facilities for managing units in calculation, so that accidental mixture of (for example) English and metric units is less likely to go unnoticed. But working with units and other attributes of key supply-chain and production data, and preserving audit trails for crucial engineering calculations, is arguably the next frontier in enterprise data management.
Databases, Razdow observed, were once considered too inefficient for everyday use, but within a few years the database administrator was one of the most highly paid IT positions: Could calculation management be next?