Month: March 2013

The ABC of software engineering

by

Lack of a precise context can render discussions of software engineering and particularly of software quality meaningless. Take for example the (usually absurd) statement “We cannot expect that programmers will equip their programs with contracts”. Whom do you mean? A physicist who writes 50 lines of Matlab code to produce a graph illustrating his latest experiment? A member of the maintenance team for Microsoft Word? A programmer on the team for a flight control system? These are completely different constituencies, and the answer is also different. In the last case, the answer is probably that we do not care what the programmers like and do not like. When you buy an electrical device that malfunctions, would you accept from the manufacturer the excuse that differential equations are, really, you see, too hard for our electrical engineers?

In discussing the evolution of software methods and tools we must first specify what and whom we are talking about. The following ABC characterization is sufficient for most cases.

C is for Casual. Programs in that category do all kinds of useful things, and like anything else they should work properly, but if they are not ideal in software engineering terms of reliability, reusability, extendibility and so on — if sometimes they crash, sometimes produce not-quite-right results,  cannot be easily understood or maintained by anyone other than their original developers, target just one platform, run too slowly, eat up too much memory, are not easy to change, include duplicated code — it is not the end of the world. I do not have any scientific figures, but I suspect that most of the world’s software is actually in that category, from JavaScript or Python code that runs web sites to spreadsheet macros. Obviously it has to be good enough to serve its needs, but “good enough” is good enough.

B is for Business. Programs in that category run key processes in the organization. While often far from impeccable, they must satisfy strict quality constraints; if they do not, the organization will suffer significantly.

A is for Acute. This is life-critical software: if it does not work — more precisely, if it does not work exactly right — someone will get killed, someone will lose huge amounts of money, or something else will go terribly wrong. We are talking transportation systems, software embedded in critical devices, make-or-break processes of an organization.

Even in a professional setting, and even within a single company, the three categories usually coexist. Take for example a large engineering or scientific organization.  Some programs are developed to support experiments or provide an answer to a specific technical question. Some programs run the organization, both on the information systems side (enterprise management) and on the technical side (large scientific simulations, experiment set-up). And some programs play a critical role in making strategy decisions, or run the organization’s products.

The ABC classification is independent of the traditional division between enterprise and technical computing. Organizations often handle these two categories separately, whereas in fact they raise issues of similar difficulty and are subject to solutions of a similar nature. It is more important to assess the criticality of each software projects, along the ABC scale.

It is surprising that few organizations make that scale explicit.  It is partly a consequence of that neglect that many software quality initiatives and company-wide software engineering policies are ineffective: they lump everything together, and since they tend to be driven by A-grade applications, for which the risk of bad quality is highest, they create a burden that can be too high for C- and even B-grade developments. People resent the constraints where they are not justified, and as a consequence ignore them where they would be critical. Whether your goal for the most demanding projects is to achieve CMMI qualification or to establish an effective agile process, you cannot impose the same rules on everyone. Sometimes the stakes are high; and sometimes a program is just a program.

The first step in establishing a successful software policy is to separate levels of criticality, and require every development to position itself along the resulting scale. The same observation qualifies just about any discussion of software methodology. Acute, Business or Casual: you must know your ABC.

Apocalypse no! (part 1)

by

 

Recycled(Originally published in the CACM blog. Part 1 of a two-part article. See [2] for part 2.)

On a cold morning of February 2012, Mr. S woke up early. Even though his sleep was always deep, he did not resent having to interrupt it since he had set up his iPhone’s alarm to a favorite tune from Götterdämmerung, downloaded from a free-MP3 site. He liked his breakfast eggs made in a very specific way, and got them exactly right since he had programmed his microwave oven to the exact combination of heat and cooking time.

He had left his car to his daughter on the previous night; even though the roads were icy, he did not worry too much for her, since he knew the automatic braking system was good at silently correcting the mistakes of a still somewhat novice driver; and with the car’s built-in navigation system she would be advised away from any impracticable street.

As for himself he decided to take public transportation, something he did only rarely. He had forgotten the schedule, but found it on the Web and saw that he had a few minutes before the next bus. The extra time meant that he could quickly check his email. He noticed that he had received, as a PDF attachment, the pay slip for his last consulting gig; as an Agile consultant, Mr. S was in high demand. He knew his accountant’s system would automatically receive and check the information, but still made a cursory pass to convince himself that the figures looked right, with social security contributions and tax deductions properly computed.

He went out and hopped onto the bus, all the way to the client’s office continuing to check his email on his phone, even finding the time to confirm the online flight reservation for his next consulting assignment, while monitoring the hanging displays to check the bus’s progress (it was all dark outside and he was not that familiar with the route). Unlike some mornings, he had remembered to take his id card, so he was able to slide it into the slot at the building’s entrance and again into the elevator, gaining access to the right floor. Before heading to his office he walked to the beverage machine for his morning coffee, a particular but programmable combination of two-shot expresso, a bit of hot water, and just a touch of milk.

Sitting down at his computer, he brought it up from hibernation, for some reason remembering — Mr. S was fond of such trivia — that Windows 7 was estimated to consist of 50 million lines of code, and reflecting that the system now kind of did what he wanted from it. Mr. S had thought of moving, like many of his friends, to a Mac, but the advantages were not clear, and he was fond of the old Word text processing system with which he was writing his latest agile advocacy text, tentatively entitled Software in 30 days. (It has since appeared as a book [1].)

Mr. S — whose full name was either “Schwaber” or “Sutherland”, although it might have been “Scrum” or perhaps “Sprint”, as some of the details of the story are missing — opened up the document at the place where he had left it the evening before. Like many a good author, he had postponed finalizing the introduction to the last moment. Until now inspiration had failed him and his coauthor: it is always so hard to discover how best to begin! Over the past months, working together in long Skype discussions from wherever each happened to be, they had tried many different variants, often simultaneously editing their shared Google Docs draft. But now he suddenly knew exactly what he had to say to capture the future readers’ attention.

The sentence, which was to remain as the key punch delivered by the first page of the published book [1, page 1], sprung to his mind in one single, felicitous shot:

You have been ill served by the software industry for 40 years — not purposefully, but inextricably.

References

[1] Ken Schwaber and Jeff Sutherland: Software in 30 Days — How Agile Managers Beat the Odds, Delight their Customers and Leave Competitors in the Dust, Wiley, 2012.
[2] Part 2 of the present article was published on 16 May 2013 and appears here.