What would you say if your manager suddenly confronted you and said, “Quick! Tell me the three most important things that our software industry needs to do in order to bring about a substantial improvement in software quality! Just three things!“? Of course, if you don’t work in the software field, you wouldn’t know what to say … except, perhaps, to put your manager on the defensive by saying, “Whaddya mean three things? Why not just one thing? Don’t you remember what Jack Palance had to say about ‘just one thing‘ in City Slickers?”

But if you do work in the software field, you might want to give the question some serious thought. I was asked to do so yesterday, as part of a panel session on the final day of the JaSST conference that I attended here in Tokyo. Two other panelists and I were given a short ten minutes to present our ideas, before the audience was invited to express their opinions and ask some questions. My three proposals for improving the overall state of software quality focused on these areas: politics, collaboration, and negotiating tradeoffs.

Politics might seem a strange thing to talk about, in the context of something complex and esoteric like software quality. But consider the following: most of the large companies around the world today — ranging from banks to telecom vendors to automobile companies to consumer electronics firms — are actually thinly disguised software companies; and the same is true for most government agencies. The products and services provided by such companies are software intensive; and even if the software doesn’t account for the largest part of direct expenses, it’s typically the most crucial factor in terms of overall success and failure.

Considering the importance of software in so many companies, it’s interesting that senior managers– especially the CEO/COO and Board of Directors — are usually people with backgrounds in finance and accounting; sales and marketing; law; and (sometimes) hardware engineering (or mechanical engineering, aeronautical engineering, etc.). So, in my humble opinion, we should be electing, promoting, and rewarding people with software skills and backgrounds into more senior management positions. That doesn’t necessarily mean that I’d vote for Bill Gates as President … but it might lead to more successful results than electing a former movie actor as President.

Collaboration is something we hear a lot about in the Web 2.0 world, but you don’t hear much about it in traditional software development — at least not in the context of software quality. We hear mostly about software processes and methodologies, better tools and testing techniques, etc. But it seems to me that large software teams (or, perhaps more accurately, “software armies”) organized in a traditional hierarchical managerial structure have not worked very well. One reason is that the people in the senior technical managerial roles are often technically obsolete (e.g., their last programming assignment was in Autocoder on an IBM 1401), and thus incompetent to be giving technical instructions to the bottom-level technicians who are trying to write high-quality Java code for a complex distributed system. Another problem is the typical time-lag between the moment that a senior technical manager makes a decision (”the architecture for our system shall be X, and the programming language shall be Y!”) and the time it reaches the bottom-level technicians, by which time the decision may no longer be relevant.

So, we should be exploring peer-organized, grass-roots open-source development strategies — e.g., why is it that development efforts like Linux and Wikipedia have been so successful, when (to oversimplify things a bit) nobody is “in charge,” in the traditional sense of the word? The issue here isn’t whether Linux is better than Microsoft Vista, or whether Wikipedia is better than Encyclopedia Britannica; the issue here is that a traditional management-oriented person would have predicted that the Linux/Wikipedia organizational approaches would quickly disintegrate into chaos and anarchy. But they clearly have not done so; and while books like Eric Raymond’s The Cathedral and the Bazaar have given us some insights into the open-source development model, we need more analyses and investigations.

Also, we should realize that we not only need more collaboration within a software development organization, but also across the organizational boundary, into the marketplace. We need to get customers involved in R&D, product definition, documentation, QA, and technical support. The Web 2.0 people have been telling us this for the last couple of years, and people like Don Tapscott and Anthony D. Williams have been articulating the concept in new books like Wikinomics: how mass collaboration changes everything. The pharmaceutical industry is already making big investments, and reaping big rewards, in this area; the software industry needs to start listening.

Finally, on the technical side of things, we need to remember that the tradeoffs between functionality, time, people, cost, and quality are non-linear. If you compress the schedule for a project by, say, ten percent, chances are you’re going to suffer a disproportionately larger decrease in quality, assuming that you hold the cost, functionality, and people constant. Unfortunately, customers and senior management don’t understand that reality; indeed, most of them don’t want to acknowledge any tradeoff at all, and would prefer to accomplish shorter schedules by yelling and shouting at the developers to “Be more motivated!”, by which they mean “Work more unpaid overtime!”

In order to have a rational, mature dialogue about this issue (which may be difficult to do in any case, because of the politics — which is why my first proposal concentrated on the political issues), we need to make better use of existing software estimating models and tools. One of the best ones, though by no means the only one, is Larry Putnam’s SLIM model. Sadly, tools and models like this are used in only a small percentage of software development efforts.

So, those are my three suggestions for improving software quality. Somehow, I managed to articulate all of this within the prescribed ten minutes, but I’m not sure it made any sense at all when it was translated into Japanese.