What if writing and delivering software were like publishing a newspaper?
After more than fifty years of practicing software development, the experts of our trade are now agreed: we are still useless at it.
At least some of this is my fault. It was people like me who wanted swanky job titles like ‘Software Engineer’ or ‘Chief Architect’ rather than ‘Programmer’ or ‘Application Developer’. Well, things have changed; most of us are now prepared to admit that the practice of our trade is not an exact science. And although we may be tempted to call what we do an art, it is too often the case that our creativity is as cramped as that of a McDonalds jingle composer.
We need new ways of thinking about what we do. On the other hand, this is not a time for abstract philosophizing, but for practical advice. With these considerations in mind, I suggest we look to those who have faced and overcome pressures similar to those of a software project. So what other industries have to deliver accurate and interesting content under absurd time restrictions? Who else is forced to be creative and yet compromise creativity as a matter of course? Extreme programmers are not the only ones delivering stories. I propose the news-desk of a daily newspaper as a new metaphor for software development.
The Daily Fortnight
Your average programmer has many fine qualities. Timeliness, however, is not normally considered one of them. If software were delivered along the same lines as your daily newspaper – with all the features you expect and according to a predictable schedule – our customers would be a lot happier. If the opposite were true, and journalists started to adopt our processes, then one thing is for sure: the daily newspaper would not arrive every day.
Publishing a newspaper is, of course, nothing like publishing software. It is usually possible to understand what a journalist has written without a series of PowerPoint presentations. But the problem of producing a daily newspaper is subject to many of the forces common to our own industry. Harsh time constraints are the norm and the price for sloppy work can be just as costly and embarrassing as software failure.
The methods a newspaper uses to cope with these risks will be familiar to most programmers. Early review of stories helps avoid typographical and stylistic errors. Editors keep an eye out for errors of substance and libel (defamatory untruths that could lead to lawsuits). The editor’s mandate is to inspect the creative work of others and order revision where necessary.
This role is analogous to that of the tester in large-scale development projects, with one big difference. The copy editor of a daily newspaper has the authority and competence to correct or rewrite the work assigned to him for review. Large rewrites are likely to be “bounced” back, but for modest changes a copy editor will most likely only confer with the assigning editor or reporter, and not even that for smaller corrections.
Stop the press again!
Here, I think, we find the key to speeding up the production of large-scale software. Almost everything has been tried to tighten the feedback loop between designer and tester. Now it is time to remove the loop. As ever, this is easier said than done, but again, we are able to learn from newspaper journalists.
The first problem is one of culture. Testers today represent a kind of underclass in software development; they receive less pay, less training and less respect than ordinary designers. This was once true also of newspaper reporters who were demoted to the job of editor. Today the copy editor of a tabloid newspaper would be expected to have real reporting experience and probably a degree in journalism. In order to reverse this culture and provide software testers with the authority they require, they must receive training and, most importantly, experience writing code.
Roughing it in style
These steps towards a more streamlined development process cannot be made in isolation. Back at our daily newspaper, the editor has to work quickly to get the latest stories in. If time is running out, and it always is, then he will have to make fast and dirty decisions.
Reporters are trained to write using the inverse pyramid style; the editor then knows that he can cut off paragraphs from the bottom of the story without losing the most newsworthy information. A story would take much longer to edit and fit if it were written Agatha Christie style, with the punch line at the end.
The reporter’s choice of style has practical consequences and every large newspaper has its own style guide, which its reporters are expected to follow. This serves the same purpose as a coding standards document in our own trade. Differences over style and usage can be settled quickly and without dispute. Such a reference is advantageous if more than one person is working on the same code base. But coding standards and readability are of the essence if another group is authorized to make corrections directly.
Conclusion
Running a successful software project isn’t easy. Neither is getting a newspaper to sell. For those who enjoy a challenge, software development and newspaper journalism are inherently rewarding vocations.
If you find this is not this case, it might be that you are a programmer spending all your time in delivery meetings to release two-second bug fixes. Or maybe you a tester who has written fault reports for a month on installation and now has a day and a half to test what is finally installed. To get away from this situation, design and test must be able to work seamlessly. Just cutting out red tape can stop a “show stopper” from stopping the show.
To realize that you will never achieve the rigor of an engineering discipline or the freedom of an artist is discouraging only if that is what you are aiming for. If you want to be held in the same esteem as a scientist, then buy yourself a lab coat and be done with it.
To come clean, programming is not journalism any more than it is architecture. Having said that, I think a study of journalism gives us new insights into familiar events. Testers would be more efficient if they can focus on solutions instead of problems. For this they will need essentially the same skill set as a programmer. And programmers will have to support test in everything they do if they ever want that promotion to ‘Chief Technical Editor’.
First appeared at Software Reality
Christian Steinbach has developed datacom and telecom network management software for most of the past four years, and now works with the embedded software of a 3G network component. He lives in Stockholm and actually looks forward to the cold winters.
Christian also writes for SoftwareReality.com, a satirical website for software developers.
