Talk About Quality

You can do anything in software. Hordes of eager computer science graduates, not to mention brilliant open source coders, keep joining the ranks of software development because it’s fast and fun.

The fact that software is instructions to a machine (the “hard” in “hardware”) seems to have been the only thing John Tukey had in mind when he coined the word “software” back in 1958. (Dr. Tukey, an accomplished statistician, was more focused on computerizing the Fast-Fourier Transform, and criticizing the Kinsey Report for its questionable sampling methods.)

While software attracts developers with its ease in creating things, it tempts us all with its other “softness”: amenability to change. Software can be endlessly fixed, extended, improved. And that advantage demands something of developers which was unexpected, and, well … hard.

Hardware must fit form to function so it’s easy to use. And come with good documentation for maintenance and repair. But that’s all on the outside. Software, always ready for change, has to be clear and readable on the inside too. In other words, software developers have to be good writers, because the next developer will have to read and quickly understand what’s going on in order to change it.  Written changes, again, have to leave the software in a clear and readable state.

In high school, I avoided English class like the plague (and got bad marks for using cliches in my papers), preferring to go into school on snow days to use the (one) computer. Good writing is not why people become programmers. But it’s exactly what we need. Clear written communication. Equal in impact to life-changing books (pen mightier than sword and all that), software crucially affects our lives — from cars, to food transport, to the electric grid.

That good writing is an unwelcome requirement of sofware is why developers code quickly and obscurely, hate documentation, and shun code review. And  why managers push for features, delivery, and fixes, while devaluing internal quality.

Is there hope? The only one I can think of must exploit other likes and dislikes: managers want software changes fast, while developers like writing new code more than fixing someone else’s (or their own) bugs. Good writing is the only way to make code support that scenario, and reap the advantages of software.

That’s right, not “development” but “developer”.

The latest issue of The Embedded Muse newsletter—#179 (pdf)—has a reference to an interesting and very different kind of book about C. It’s about the business pressures and the thought processes of C software developers. And a lot more. It’s also long—1600 pages! So download a copy and skim for what interests you:

The New C Standard: An Economic and Cultural Commentary

Some lines that caught my eye, just in the first 100 pages, skimming with the “Page Down” key:

“Software developer interaction with source code occurs over a variety of timescales [for example, those] whose timescale are measured in seconds.”

“The act of reading and writing software has an immediate personal cost.”

“Source code faults are nearly always clichés; that is, developers tend to repeat the mistakes of others and their own previous mistakes.”

“A list of possible deviations should be an integral part of any coding guideline.”

“The following are different ways of reading source code, as it might be applied during code reviews …”

Other related references from the book’s author Derek M. Jones (http://www.knosof.co.uk/):

• Blog: http://shape-of-code.coding-guidelines.com/
• Article:  Coding Guidelines: Fact and Fiction
• Article: The 7±2 Urban Legend (small pdf)

And somehow related, from another author, Les Hatton (http://www.leshatton.org/):

• Article: Testing the value of checklists in code inspections

Something that nags at me in the background is time-suckers. E-mail for example. A while back I made myself a list of rules for e-mail handling:

1. Delete without reading
2. Read and delete
3. Read and file
4. Read and reply

But it’s got some problems. First, it’s hard to keep to rules when my e-mail is always there, tempting me away from harder, though more productive, activities. Second, the hidden assumption is that e-mail is a satisfactory way to handle every task which is introduced in e-mail. (Wrong!)

I tried a little experiment, unplanned, on a day when I was off work. I told myself I would process my e-mail (so there wouldn’t be a mountain of it when I returned) but not reply to any of it. In other words, I would apply options ##1 – 3 above, but not #4.

I was off for 2 days, and during that same period, my local worksite was closed, so nobody local was sending me any e-mail. Still, when I logged on, I had almost 100 new e-mails! Some were automatically generated, and the rest originated at another worksite that was not closed. Most of the e-mails were simple text, but a few had attachments. Including reading those, I “processed” all but 5 e-mails, which seemed that they would merit a response or action upon my return to the office.

What’s interesting is that, on second look, none of the remaining e-mails really require a response. My replies might help the sender a bit, or suggest to them something that could help me slightly in the future, but nothing big. Probably my responses, if they are still helpful by the time I do return and respond, will only generate more e-mail.

Meanwhile, I just noticed that the only e-mail that actually requested something of me alone (that is, if I don’t do it, nobody will) was not among the 5, but was an additional e-mail left behind from the first of the two days’ e-mail I reviewed. And the best way to deal with it will be to visit someone in person to discuss it.

So what’s the best way to save time on e-mail? Use it less. Receive less, by tailoring subscriptions carefully. Send less, by e-mailing only to request or provide an answer that must be in writing.

I’ll try that.