Legislating quality in software development

Is it possible to obtain quality software by forcing developers to produce quality software? I think not.

What is quality?

First, there is the issue of what "quality" means in the first place. Consider Ruby and Java. A typical Ruby developer would consider Java excessively verbose. A typical Java developer would consider Ruby too dangerous (I imagine; I am not friends with many Java developers). Is one of them of higher quality than another?

Then there is the issue of shipping. Most software is useless if it is never finished, never released to customers, never sold. At some point in a nontrivial project quality compromises must be made for the sake of completing the project. How much quality can be compromised in this fashion?

Then, what "quality" means is a function of who provides the definition. The hypothetical typical Java developer would probably not consider Java excessively verbose. In a typical Java environment the developers are unlikely to be unhappy because they write too much code. Now put a Ruby developer in that environment and see what happens!

So far the aspects mentioned have been on macroscopic scale: projects, schedules and programming languages. But even on microscopic scale there is a wide variety of what "quality" can mean.

Consider a junior and a senior developer working on the same application. What makes the senior developer worthy of their title? Part of the reason probably has to do with the quality of the code they produce, as opposed to the time taken to produce it or whether they can accomplish a particular task. If you were to ask such a developer what their definition of quality was, you would probably get some pretty generic answers like "variable names should be meaningful". Well, who decides whether a variable name is meaningful? And what does that mean? When is "i" a meaningful variable name, and when is it not?

By now services have been developed to evaluate quality of code, and offer suggestions for raising it. These services however can only look at objective factors like how many lines of code a method takes. And there are coding standards that flat out prohibit methods over a certain number of lines of code. But objective metrics do not tell the whole story.

Everything else being equal, methods with fewer lines of code are more readable. So why not restrict methods to having at most 3 lines of code: either the method does a single operation, or it delegates some work to another method and does one operation with the result, or the method is a conditional statement delegating each of the branches to other methods. Sounds like a good plan? The problem with it is that while each method may be easy to understand, comprehending an entire system built in such a way may well become more difficult. A 10 line method that encapsulates a certain piece of functionality is going to be more difficult to comprehend if it balloons into 10 methos with 2 lines of code in each.

While objective metrics can be productively used by developers who intrinsically are trying to write better code, using only objective metrics far from guarantees that the code is of great quality.

The human factor

Even if a particular developer can write high quality code, nothing requires that to actually happen all the time. Generally speaking, quality takes effort. A developer who is capable but not interested in the project can easily write code that meets all coding standards' requirements but is difficult to read or maintain.

Case in point: I took a programming class in high school. It was taught in C++ and the assignments were roughly "hello, world" level. By then I have already been writing Windows applications for a few years. I was so bored with the assignments that I submitted them all with empty main functions. Not only that, I made it a point to vary the mechanism by which I the programs performed useful work despite having empty mains from one assignment to the next. My submissions did not violate any rules because, well, rules for intro to C++ assignments are along the lines of "you must use variables" and not "your code must be in main and not in a class destructor".

If you think this example is contrived, The Daily WTF provides plenty that are not. "I'm thinking this problem will be best solved via stored procedures/a rules engine/web services."

What can be done?

Assuming you do want real quality, how can you make it happen?

I believe quality is something that comes from within developers rather than something that is forced on them from the outside. If you agree, the way to have higher quality is to cultivate it in your developers. This can broadly be divided into two vectors: making developers desire quality in a particular project and making developers happier in general.

Quality on a project

Developers working on commercial software typically have implementing features as the most important goal with quality being a distinct second. A well implemented feature is worthless to a business if it has no market, or if it took so long that competitors now control the market. Businesses have entire departments dedicated to selling functionality before it exists and making sure unhappiness of existing users does not stop new users from paying for software.

Free and open source software, on the other hand, values quality much more. The norm is to release fewer features but have those features really work. By allowing developers to release internal software publicly, the software becomes judged by the typically higher free software quality bar. Besides that, published code is developers' public image, and developers generally want to publish high quality code.

Open sourced projects therefore see a quality increase due to developers caring more about the code they publish.

Developer happiness

Quality takes effort; it essentially is expenditure of short term effort for long term gain. Unhappy developers are unhappy right now, which means short term. They are unlikely to spend effort writing high quality code when they know they don't have to.

Happy developers are more likely to take a little extra time to clean up those warts right now to avoid having to deal with issues in the future.

Keeping developers happy is, of course, a tricky problem that deserves its own space and time.