Why companies struggle with recalcitrant IT
IT IS SUPPOSED to be the “Tesla killer”. Volkswagen’s new ID.3 is the firm’s first mass-produced all-electric car—and the first step in the German carmaker’s attempts to reinvent itself for an electrified world. That makes it perhaps the most important model since the original Golf, launched in 1976. The ID.3 is also late. Mechanically, the car is hunky-dory. But some software widgets that are a big selling point these days—rumoured to include smartphone connectivity and augmented-reality parking assistance—may be missing at first, only to be added later. Originally set for this summer, the launch has been pushed back until at least September.
VW is not the only big company struggling to make its computers work. Last year British banks were hauled over the coals by regulators for online outages and botched IT upgrades that left millions of customers unable to make or receive payments. Some problems are much more serious. Boeing’s 737 MAX aircraft were grounded in 2019 after two fatal crashes caused partly by a software flaw. Investigators have since found lesser bugs. Airlines are, for instance, now advised to turn the plane off and on again every 51 days, to stop its computers displaying false data in mid-flight. A similar problem found in 2017 in some aeroplanes made by Airbus, Boeing’s European rival, prompted the European Union Aviation Safety Agency to require that such aircraft be rebooted at least every 149 hours.
Blame for companies’IT woes often ends up in the boardroom. Sometimes that is fair; Dennis Muilenberg was rightly forced to resign as Boeing’s CEO after the tragic 737 max disasters. But not always. For software is hard—and hard to keep up with. And the employees expected to produce it are often the products of a discipline that is in many ways oddly premodern. When software is “eating the world”—Silicon Valley speak for a situation where most firms are to a greater or lesser extent software companies—that matters.
对企业IT弊病的指责最终往往会落到董事会头上。有时这很公道：737 MAX的惨痛灾难发生后，丹尼斯·米伦伯格（Dennis Muilenberg）理所应当地被迫辞去了波音CEO一职。但有时这也有失公允，因为软件很难做，要跟上软件发展的步伐也很难。而培养软件开发人员的学科在许多方面往往又莫名地很“前现代”。在软件正在“蚕食世界”的当下——正如硅谷所示，大多数公司或多或少都是软件公司——这是个紧要的问题。
Start with the computer code itself. Programming requires a mix of hyper-literalness and creativity. Tiny errors, like a misplaced punctuation mark, can completely change how a system behaves. An industry rule of thumb is that, depending on how carefully they work, programmers make between 0.5 and 50 errors in every 1,000 lines of code they write. Because cars and aircraft contain tens of millions of lines, the chances of an error-free system are in effect zero. Even when bugs do not lead to catastrophe, they put a constant drag on a firm’s productivity. A survey commissioned by Stripe, a digital-payments processor, suggested the average developer spends 21 hours a week fixing old or bad code.
The inherent difficulty of programming is made worse by the shortcomings of software engineering as a profession. These are laid out in a book, “The Problem With Software: Why Smart Engineers Write Bad Code”. The author, Adam Barr, spent 20 years as a developer for Microsoft, a software giant. Many coders, he notes, are at least partly self-taught. That leads to bad habits, which software-engineering courses fail to correct. There is too little communication between academia and industry, and no real agreement on what to teach or what habits to instil. The result, argues Mr Barr, is a field in which folklore and fads too often take the place of professional standards.
软件工程这个职业的弊病更是让编程固有的麻烦雪上加霜。这些都在《软件困局：为什么聪明的程序员会写出糟糕的代码》（The Problem With Software: Why Smart Engineers Write Bad Code）一书中得到了阐释。作者亚当·巴尔（Adam Barr）在软件巨头微软做了20年的开发员。他指出，许多程序员至少在一定程度上是自学的。这导致他们养成了各种坏习惯，而软件工程课程又未能纠正他们。学术界和业界交流太少，在应该教什么或培养什么习惯上也没达成真正的共识。巴尔认为，结果就是在这个领域里专业标准总是被坊间习俗和一时的风潮取代。
To illustrate the field’s shaky foundations, Mr Barr points to the practice, popular with technology firms like Google or Apple, of giving job candidates a programming problem to solve on a whiteboard. Few other fields behave that way, because they assume that, by dint of having graduated, applicants have already achieved a basic level of competence. Doctors do not expect anatomy quizzes before being hired. Mechanical engineers are not required to jot down Newton’s laws of motion to prove their bona fides.
All those problems are compounded by software engineering’s breathless rate of change. Even when a system works, it rapidly becomes obsolete. The woes of British banks are largely the result of trying to maintain such “legacy” systems, written by long-departed programmers (often outsourced) in half-forgotten computer languages to satisfy criteria no one can quite remember. Coders under pressure to add nifty new features often cut corners, storing up problems for the (ever less distant) future.
The result, says one expert with decades of experience, is that shiny new IT systems can rapidly devolve into rickety, half-understood contraptions held together with gaffer tape and a prayer. Eventually the costs become too great to ignore, and companies must upgrade their systems. But that is the moment of maximum danger, for the new software must do everything that the half-understood old one does, and more. It is, to repeat a common but apposite analogy, like rebuilding an aircraft in flight.
A bug’s life
VW is doing its best to iron out the kinks with the ID.3’s snazzy features. The firm wants to bring most software development back in-house, and has spent €7bn ($8bn) on a shiny new “digital unit”. That is probably a good idea. However, as Mr Barr argues, the structural problems with writing software mean that spending money on it does not, by itself, guarantee success. One great advantage possessed by startups like Tesla or Monzo, a newish online bank in Britain, is that their programmers are handed a blank sheet of paper. With no legacy systems to maintain, and fewer old bugs to root out, their software is more robust and developers can spend more time on features that customers want.
If that is cold comfort for older companies that have no easy way of starting afresh, computing greybeards offer reassurance—after a fashion. The startups’ advantages will, they predict, prove temporary. Bugs will creep in. Bodge jobs will go unfixed. Developers will leave, taking knowledge with them. Today’s feisty usurpers will become tomorrow’s clumsy incumbents, held back by their antiquated, unreliable IT—and ripe for disruption in turn. ■