Reply to Message

The problem is....

Jeff Dickey 11th Feb 2009

...that dozens of thousands of us have spent the last 30+ years (IT has been around longer than that, but bear with me) making the business-culture change that "obsoleted" our jobs practical (in the opinion of non-technical business management). The non-labor major costs - reliable, high-speed networking; CPU power well in excess of most orgs' actual needs; and dirt-cheap storage (RAM, disk and "cloud") have let vendors with strong vested interests point to labor as "a bunch of untrainable old-timers who can't possibly understand the New Whiz-Bang Marketed-to-the-Skies Thing(R)(TM)(LSMFT)". So a craft that has been taking fitful starts towards becoming a true engineering discipline (engineering, n: the practice of taking known materials and through the use of known and verifiable methods producing a result knowable in advance, by practitioners with sufficient initial and continuing demonstrated capability that they can take professional and legal responsibility for their artifacts.") and turned it into a toy. This "toy" is expected to simultaneously be subject to cost and schedule constraints imposed by individuals proud of their ignorance of the craft, to be created using a labor pool of individuals by and large grossly inexperienced in their craft, and yet becoming the most ubiquitous actor upon lifestyle, healthcare and all significant economic activity. The cost of producing artifacts under such conditions is never admitted to up front, but added on later in the cycle as "debugging" and "maintenance". This is more than just about outsourcing and offshoring, although those practices have highlighted the problem: if the customer does not understand the system sufficiently well to document it completely, clearly and unambiguously, then Bad Things will happen.

Thirty years ago, it was well-known in the industry that most projects "failed"; failure being defined as 100%+ over budget, 100%+ over schedule, and/or delivering less than 50% of the required capability. (See, for instance, Fred Brooks' The Mythical Man-Month, and The Decline and Fall of the American Programmer.) The feeling then was that, if we could continue to document, share and expand knowledge of what worked and what didn't, we could eventually get to a point where we would have a true, continuously-improving engineering discipline.

It was felt then that this could be accomplished in twenty to 30 years' time. Now, three decades later, we're still at least that far from seeing it. It takes about ten years for any professional to master his or her profession's body of knowledge and gain sufficient experience to be able to fully accept responsibility for his work; see for example law, medicine and commercial aircraft pilots. Yet software (and Web) development are unique in self-styled "professional" disciplines in that anybody with more than three to five years of experience is considered over-qualified for almost any position. Only the young and cheap need apply. We as a society wouldn't accept that attitude from hospitals hiring surgeons; why do we so blithely take it as "normal" for those developing the software that controls the tools that surgeon uses to assist, analyze and provide information necessary to his work?

The sooner we as a society recognise this, and slap down the bean-counters who think a kid with a mimeographed cert from who-knows-where is the functional equivalent of a broadly and deeply experienced practitioner, the sooner we can put the certainty of software-induced failures in business and public policy and practice behind us. One doesn't call a botched medical procedure a "glitch"; no professional architectural firm would let non-professional outsiders dictate acceptance of a failure-in-the-making that the professional architect refuses to sign off on (that phrase, in fact, came about as a symbol of professional responsibility). Nobody bats an eye if software fails. (If you really want to keep yourself awake at night, Google "medical software failure" and read through the first couple pages).

We've had indisputable evidence the last year or two that the 1980's "greed is good" mentality has done real harm to our economy and our society. Steps are being taken in many countries to attempt to address this. One of the knock-on effects of this attitude has been the current business attitude towards software, its development and maintenance. Steps should be taken to address that, too.