David Seruyange pointed me to a great presentation by Yahoo! Javascript Architect Douglas Crockford on software quality. At least, “Quality” is the title of the presentation, but in fact Crockford gives a wonderful history lesson, showing how we got to where we are today. This is a 48-minute presentation, and well worth the time. If you don’t have time to watch the whole thing at work, do yourself a favor: forgo an episode of American Idol, set 48 minutes aside at home, don the headphones and listen in. You won’t regret it.

Crockford reminds us of some theories that have been around for a while, but have gotten lost in the morass of “snake oil” - new methodologies, tools and techniques that are claimed, by their vendors, to be silver bullets - quick, easy wins in the battle against poor software quality. There are no silver bullets, says Crockford, and you know what? He’s right.

In case I can’t persuade you to watch the whole presentation, here are some highlights:

Crockford recalled some key points from the 1975 Frederick Brooks book The Mythical Man Month, which is still surprisingly relevant today:

He also referred to Donald Knuth’s concept of Literate Programming, and Harlan Mills’ surgical team concept, which recognizes the fact that certain programmers can be as much as 10 or 100 times as productive as others. High performing developers are provided with a support team, which Crockford updates to include a co-pilot, a writer, a “language lawyer” - someone with a deep understanding of the language being used, a buildmeister, toolsmith, testers and interns. (Mind you, Dave Delay thought way back in 2005 that Mills’ perceived need for all those people just to support one programmer had been obviated by automation.)

One of the most powerful arguments for caring about software quality, at least from a business standpoint, is almost glossed over in the presentation. Crockford points out that for a company like Yahoo!, the state of the code base has a significant impact on the company’s valuation. They look at two aspects of code quality: coding conventions (aka coding standards), and macro architecture. They have found that the easiest win for improving code quality is to improve readability. His suggestion (although he didn’t actually say whether they do this at Yahoo! or not) is that every 7th sprint, no features are added to the code; you focus on clean-up. Crockford ends by noting that security and simplicity go hand in hand: a way to make your code more secure is to simplify it.

Pair programming is a concept that has been around for a while and something I have heard good things about, although we have never actually come across any customers using it. This is probably because, in many organizations, pair programming would be too easily interpreted as “two people doing one job”.

When I worked for IBM, back at the start of the e-business phenomenon, the management of our group made a very uncharacteristic decision for the time (and as it turned out, a very wise decision). None of the e-business technical staff went on-site; all work was performed within IBM’s offices. The decision was based solely on the fact that this was a new area of the business where there was very little resource available, and practical experience was particularly scarce. Keeping everyone in the office allowed us to share resources and put them where they were most needed at any time. Of course pair programming, as we know it today, didn’t exist back then, but my understanding is that one of the key benefits of using pair programming and rotating the pairs is “fuller knowledge of the code base by all developers”.

That concept was particularly important back in the heady days of the mid to late nineties. At the time, many people would gain a year’s experience in a technology (at the time it was WebSphere, Java, JSP) and then leave to go freelance (or to another company) and make a lot more money.

Turnover was high, and handover was pretty minimal (usually just a list of outstanding items). However, due to the fact that almost everyone in the group had worked with everyone else on many of the projects, it was not necessary to go into a deep explanation of how classes mapped, or even what the architecture was – people knew. If we had all been around the country at different client sites, I know a lot of these projects would have missed deadlines.

So, even though our projects were rather informally structured, all of the projects I worked on for this group were delivered on time. Had we adopted Agile/XP/RUP or some other methodology to formalize the aspects of what we were doing, I am sure that would have led to even better quality applications being released.

Although what we were doing back at IBM wasn’t pair programming in the strict sense, it certainly gave me a first hand view of the benefits of having more than one person work on the same code. Before dismissing pair programming as a concept, you might want to think about how much stored knowledge about the projects you are working on walks out the door every night.

Amiram Hayardeny wrote a thought-provoking post yesterday in which he applies the broken window theory to software quality. The broken window theory suggests that neighborhoods where minor evidence of decay (broken windows, deteriorating building exteriors, etc.) do not get fixed quickly start to deteriorate more rapidly. Hayardeny suggests that the same theory can be applied to software development teams: “Evidence of decay (large defect backlogs, no documentation, no code reviews) remains in the system for a reasonably long period of time. Quality oriented engineers who work on the project feel more vulnerable and begin to withdraw. They become less willing to intervene to maintain software quality for example, to attempt to enforce code reviews, or to address signs of deterioration…”.

There’s no doubt that quality is a mindset issue. Ignore the issue, and the natural state of things is to deteriorate. Foster a quality mindset, stay on top of minor defects, and there is a better chance that things will not get out of hand.

Having a particular interest in data visualization (more on how that relates to what we are doing here later), I was browsing around the Digg API visualization contest today. The many different approaches to building a meaningful representation of a dynamic data set made me realize that there are probably as many ways to solve that problem as there are people willing to build a solution (some wackier than others!).

Ultimately, what struck me about the different approaches to the problem is that sometimes, the simplest approach is the best. Although I didn’t like the fact that it was an Apollo application (yet another runtime to download and install), I thought the Digg Graphr application did a nice job of representing the relative popularity of articles in a way that was very intuitive.

Ever-vigilant, Enerjy’s software glitch radar reports that Atlanta’s metropolitan rapid transport authority, MARTA, suffered an outage in their automated fare system after a software upgrade Wednesday. Fortunately, it sounds like the worst thing that happened was that they had to open access gates to let people through, and a few folks traveled for free that day.

Right after I graduated college with a bachelor’s degree in Computer Science (way back in 1984!), I became an associate member of the British Computer Society. I was eligible for associate membership status on the basis of the 4 years I had just spent studying. To move up to full “member” status, I would have to complete 4 years of professional experience, during which time I would need to document the projects that I worked on, and submit that documentation, along with at least two professional references, plus a reference from an existing member, with my application.

Somehow, I never perceived that there would be enough benefit to me from doing all of that, and so I was happy to continue with my “AMBCS” designation. Until, in 2000, I received a letter from the BCS indicating that they had changed the rules of admission to membership, and now, somehow I was magically qualified. So, by just paying the increased annual fee, I could drop the “A” from my designation.

I continue my membership of BCS, not because I really get anything from it directly, but because I believe that professional organizations, and the accreditations that they often provide, are a Good Thing. The thing that bothers me about the BCS, is that those accreditations, if they are going to be worth anything, should be hard to achieve.

Cem Kaner has written extensively about this issue as it relates to software testing - starting with the second bullet point in his 2006 five year plan, in which he states: “Since 1999, the biggest innovation in commercial software testing education has been in marketing–more people are using “certification” to sell courses, sometimes at stunningly high fees.” More recently, Kaner has introduced the idea of open certification, which has significantly more value as a means of comparing skill sets, especially of potential employees. Not that Kaner advocates using certification for that purpose. But there’s no doubt that one of the toughest challenges facing any software development organization is finding really good people.

The problem is that there are so many organizations offering different certifications, that it is virtually impossible for anyone in a hiring role to get a sense of the value of the certification. Is the “Certified Software Tester” program better or worse than the “ISEB Practitioner Certificate in Software Testing“? It’s kind of hard to tell.

Here at Enerjy, when we’re hiring, whether it’s for developers or test engineers, we tend not to pay too much attention to qualifications, whatever institution issued them. We have a technical questionnaire we send to potential candidates and ask them to take a stab at answering. Often, the way the candidate approaches answering the questions tells you a lot more about whether they are the type of person you are looking for than whether they got the answer right or not. That’s an insight that a framed certificate will never give you.

Before I started this blog, we used to send out a subscription-based e-newsletter. We’d track which articles were clicked on the most. By far the most popular item in that newsletter was something we threw in for fun - we called it Software Horror Stories. Each month, we’d find some newsworthy example of a software glitch causing a problem, and include a link to the story. Just a bit of fun, but of course there’s an underlying message…

So, I thought we should coutinue that great tradition here, and in that spirit, I didn’t have to look far to find a report that some XM subscribers were not able to receive a signal yesterday, owing to a “software glitch”. Good job I’m a Sirius subscriber ;o)

I posted a couple of weeks ago on the pros and cons of putting a live demo of our CQ2 product up on our web site and letting anyone have at it. Well, we are about ready to go live with that demo, and will be putting the updates on the web site tomorrow.

Meanwhile, the demo server is up and running, and if you want to go take a sneak peek, you can do so here. If you have feedback, positive or negative, I’d be happy to hear it, either as a comment here, or by email to nigel underscore cheshire at enerjy dot com.

Going through late teenagehood in England, my first car was a Mini. Not the fancy, BMW-in-sheep’s-clothing that goes by that name these days, but an original, 1964 vintage Alec Issigonis-designed model with an 850 cc 4-cylinder engine and rubber cone suspension that cornered like it was on rails.

The only maintenance that car required, aside from the occasional oil change and a squirt of WD-40 every time it rained, was a change of spark plugs and a check on the points gap. You could do that in about 5 minutes with a screwdriver and a feeler gauge.

This all came flooding back to me as I dropped my car off at the dealership for its first (7500 mile) service this morning. The service technician told me that the service would take a bit of extra time, because there were some recalls that needed to be attended to. When I asked whether it was anything serious, he told me: “No, all software updates”.

I wonder how long it will be before our cars are able to download and install their own software updates - after which, hopefully, they won’t need a reboot - at least not while driving on the highway.

I was in a meeting with a customer earlier this week, discussing some of the changes that we see in development teams that start a metrics program and begin to measure the results. I used the phrase “change in the culture and behaviors” of development. In most cases, the skills are there, but the reason best practices aren’t being adhered to, or unit tests aren’t being written has more to do with that fact that there is no measurable goal to work toward in these areas.

One of the architects in the meeting made an insightful reference to Carnegie Mellon’s Personal Software Process (PSP). While the PSP represents a good, structured framework for changing “culture and behaviors”, we have never come across a development team that is using it, despite its having been around since 1998.

There’s no doubt that a change in habits will drive improvements in code quality. What is needed is a simple, practical catalyst for change. From what I have seen, capturing a few simple metrics and setting attainable thresholds is a pretty good place to start.