The Craft of Code
Andrew Todd sent a lengthy essay on a key difference between engineering fields:
...Electricals and Mechanicals build movable objects by mass production. Civil engineers, on the other hand, build "one-offs" on site...Construction is the last medieval industry.
In the mass-production industries, federal regulation supersedes state professional regulation...state licensing practically goes hand-in-hand with state patronage.
An interesting aspect of Article 145 of the NYS Education Law Section 7211.1.d Mandatory continuing education for professional engineers (www.op.nysed.gov/article145.htm) bolsters his argument:
Professional engineers directly employed on a full-time basis by the state of New York, its agencies, public authorities, public benefit corporations, or local governmental units prior to January first, two thousand four and who are represented by a collective bargaining unit, at all times when so employed shall be deemed to have satisfied the continuing education requirements of this section.
So, oddly, the NY Professional Engineers who design structures used by the public are exempt from the state's continuing education requirement, while PEs who design privately owned buildings must stay up to date. Should you think licensing software developers will produce greater safety, pay careful attention to how well-intentioned rules play out in practice.
Software combines medieval craftsmanship with mass production in a peculiar mix: Individual practitioners hammer out much of the code, using nothing more complex than a text editor, while duplicating the finished product incurs essentially no additional expense. The overall process, however, lacks much of the design rigor taken for granted by engineers.
For example, one of my uncles (yes, a PE) drew up the plans for his church's renovation and expansion. The excavation contractor asked him for permission to raise the project's grade by six inches to balance the cuts and fills, thus eliminating earth haulage. Translated, that meant they could avoid trucking dirt to or from the project by simply raising the overall ground level by half a foot. He readily agreed.
Imagine a programming contractor proposing that increasing average interrupt latency by 10 ms would reduce the module size by 5 percent and improve the error rate by 3 percent. When was the last time you saw precise numeric relations between various aspects of a programming project, before the coding began, that actually worked out as intended?
While we can observe relationships among timing, code size, error rate, and so forth after the fact, that data has essentially no predictive value for future projects. Worst of all, there's no way to quantify the effect of a small change in one part of the project on any global property: The smallest changes can (and, alas, often do) have catastrophic consequences.
In both the real and programming worlds, the sum of many small changes need not be equivalent to one large change. What's different with programming is the inability to anticipate the effect of a small change, because everything is deeply connected. Simply updating a project's compiler to a new minor version can convert unchanged source code into dysfunctional rubble, roughly the equivalent of discovering that installing new bolts on a bulldozer blade renders it unable to move earth.
Andrew's observations suggest that programming is ripe for both state licensing and federal regulation. I fear the worst of both worlds: Various states will require programmers to pass irrelevant licensing exams, coupled with overall federal requirements for code quality and performance that simply cannot be met by any software project management tools at our command. Hope, however, springs eternal.
