The Importance of Developer Quality Attributes

This is a brief discussion of different aspects of the quality of software and how I believe the development process (including newer agile methodologies) gets the focus wrong.

You can divide the aforementioned quality aspects into two general categories: those that affect the users of the software and those that affect the developers.  To help you understand the discussion below, I first need to explain the different types of software quality.  If you are familiar with the idea of quality attributes of software (often discussed in SQA literature) then you can skip the next section.  Here I present a shortened list and a brief explanation.

Quality Attributes

The quality of software depends on many inter-related attributes of the software.  Some of the more important ones are:

One attribute that I think is very important but I have never seen mentioned before is what I call debugability or how easy it is to track down the cause of a bug.  The debugging process consists of three steps:

1. detecting the presence of a bug (aided by verifiability)
2. tracking down the root cause of the bug (aided by debugability)
3. changing the code to fix the (aided by modifiability)

Sometimes the second step can be the most time-consuming; this is common in poorly written C code.  In C debugability can be greatly improved by such things as assertions and Unit Tests (which also improve verifiability, modifiability, reliability, etc).

correctness	the extent to which the soft- ware does what it is meant to
reliability	how often it crashes or behaves erratically
efficiency	how well it uses resources (memory, CPU cycles, etc)
usability	how easy the software is to use
reusability	how easy the software is to adapt to other uses
verifiability	how easy it is to test (ie, verify its correctness)
understandability	how easy it is to grasp the design and source code
modifiability	how easy it is to make changes to the source code

It is useful to think about these quality attributes for many reasons.  First, you may want to consider which attributes are important for your current project.  Generally, I think modifiability is the most important attribute but for a one-off program it may not be important at all.

You should also be aware of trade-offs between different attributes - for example, how fast the code runs (an aspect of efficiency) is often traded-off with one or more of the other attributes.  On the other hand, some attributes are highly correlated - for example, modifiability is strongly related to understandability.

Note that there are also other attributes (eg, security, compatibility, portability, etc) that I have not mentioned.  The list above is enough for our purposes.

User vs Developer

I like to group the quality attributes into what I call user quality attributes, or those that directly affect the users of the software (correctness, usability, etc), and developer quality attributes, or those that directly affect the people creating the software (modifiability, portability, reusability, etc).  Another way to think of this is that user quality attributes can only be measured by running the working software, whereas developer quality attributes may be determined by evaluating the source code.

Now we come to the main point.  My contention is that developers and the processes they use tend to focus on the user quality attributes, whereas their primary focus should be on the developer quality attributes.

Now before you dismiss this idea, I will introduce an analogy to try to get across my point...  A few decades ago a new car model had been on the market for several years.  This was a nice car: it had all the latest features, was easy to drive, very safe and had very good reviews, the only problem was that nobody was buying it.  The problem was that it was very difficult to repair and this fact became well known to many people especially car mechanics.  Nobody is going buy a car that costs a fortune to fix no matter how nicely it handles.  For this reason car manufacturers now spend more effort on making cars easy to maintain than they do on other niceties like the interior design.

Unfortunately, in the software industry the users are not so savvy.  They push the user quality attributes with the effect that developer quality attributes are neglected or at best downgraded.  Unless the developers are aware of this influence and actively resist it the long term effect is to the detriment of the software product.

We have probably all seen legacy applications where making small changes takes an inordinate amount of time due to the original design and subsequent modifications.  This is the equivalent, going back to our analogy, of removing the engine to change the spark plugs.

The software industry is light-years behind the automobile industry in this regard.  Even modern software practices like Scrum emphasize giving the customer what they want.  In Scrum the Product Owner (sort of a representative of the users of the software) has absolute power over what the team implements.  Sure the team can propose things for the backlog like refactoring for maintainability but generally Product Owners have little appreciation for how software is created and the importance of developer quality attributes.

Correct Software is Not the First Priority

The idea that removing bugs from software is not important would induce heart-palpitations in every software manager I have ever known.

The idea that removing bugs from software is not important would induce heart-palpitations in every software manager I have ever known.  Their attitude is typically that they have to keep the developers focused on delivering user quality attributes to keep the customer happy.

About 25 years ago I came across a book nestled amongst some technical books on the bookshelf at work (a company called Encom).  It was called the Psychology of Computer Programming by Gerald Weinberg.  This was a great book in many ways but sometimes I think it fell short.  [Interestingly I went back to work at Encom again about 12 years later and the book was still on their bookshelf, even though they had moved offices several times, and it still had an old monthly DJ's statement of mine in it as a bookmark.]

There was one anecdote in this book that I still recall.  It was about a large new project where the team basically were incapable of producing a solution that worked.  (I think it was something to do with configuring options for new cars and written for a large automobile manufacturer.)  The developers had created a design for the system which was very efficient but had no other quality attributes.  They spent many months trying to get the proper outputs for all inputs but changes in one area affected other areas so that they could never get the thing to work properly for all situations.

Eventually the team gave up trying to get their design to work.  On his way home on the plane the author came up with a completely new design which avoided the problems of the troublesome design.  He went back and explained his solution, but the team pointed out that it would be too slow.  Eventually they adopted the new design which actually worked even though it ran much more slowly.

The point that Mr Weinberg was trying to make with this anecdote is that the first priority is to have correct software.  That is, there is no point in having something that is blindingly fast that does not work.

One reason I actually don't like this story is that it implies generally there is a trade-off between efficiency and other quality attributes like correctness.  Though this can be true, it is rare.  Usually, buggy software is also inefficient; in contrast most well-written software is both efficient and correct.

I like the story in that it highlights how a team can become sidetracked (by technical issues) from the real purpose of what they are trying to achieve.  However, I would go further than Mr Weinberg and say that there is no point is concentrating on quality attribute A when attribute B is more important.  In particular, for a typical software project there is no point in having correct software if it can't be modified.  After all even if a program produces the wrong results, as long as it is easily modified, it can always be fixed.

Software Rusts

Software is just information so it should not be subject to the wear and disintegration that physical objects suffer.  Nevertheless there is a perception that software decays or rusts over time.  Every program I have ever worked on has suffered to some extent as modifications were made.  If you are lucky you can start with a brilliant design that becomes a bit messy as unanticipated modifications are necessary; typically you start with a small mess that evolves into a really big mess.  The result is that some larger companies completely rebuild their products every ten years or so, but most can't afford this luxury.  (eg, Microsoft completely rebuilt Visual Studio for VS2002 and again for VS2010.)

What are the causes of this effect?  Well, I could write a whole article on that [later note: I did exactly that in March 2012], but here are some off the top of my head:

•  programmers can't (or can't be bothered to) understand the original design
•  quick and dirty fixes made due to time pressures
•  avoidance of fixing things properly due to the risk of bugs

Which of these do you think is the most common reason for rust?  (Or, if you think the most common cause is something else please let me know what you think!)  After many years of being oblivious to it, I have slowly come to the belief that the last (risk avoidance) is the most common and most insidious cause.  Let me explain why.

risk avoidance is the ... most insidious cause   

First, managers are obsessed with defect counts.  They believe that every time the customer finds a bug that everyone is horrified and that the customer thinks less of them and their team.  Also, programmers themselves are ashamed to make a mistake and loathe to incur the criticism of their supervisor.  The net effect is that code modifications are not done properly but in such a way as to minimise the likelihood of causing or exposing bugs.

This is a classic example of emphasizing user quality attributes over developer quality attributes.  The whole emphasis is placed on correctness at the expense of understandability and maintainability.  The effect is that in the long term the code becomes of lower quality, so becomes harder to modify (among other things) which in turn actually causes incorrectness/bugs (among other things).

Customer Management

Maybe the next buzzword will be this term I just thought of: customer management.  Actually, that sounds a little demeaning - what about customer re-education ... hmmm, maybe not.

Anyway, the point here is that we have to change the way customers (and managers) think about software development.  Buyers of software have to become as savvy as buyers of cars and remember that all the shiny bells and whistles are not as important as what is under the hood or more particularly how easily the developers can modify what is under the hood.

But don't forget unit tests.  (All my posts seem to come back to unit tests, because they are at the heart of all good development practices.)  With unit tests you can refactor the code and be confident that you have not introduced new bugs.

The first rule is: Bugs are not bad.  If you know your developers are not lazy or incompetent then the more bugs they create means the more refactoring they are doing.  This is a good thing as down the track this will mean changes can be made more quickly and consistently, with less bugs and unreliability.

Conclusion

OK, I know you don't agree with all I have said above (but please think about it and read it again later).  Everybody knows that the whole point of creating software is to create something that is useful to the users of the software - so bugs are bad and correctness, usability, etc are good, right?

I agree that whole point of creating software is to create something that is useful to the users of the software, but the current emphasis on the user in software development works against this in the long term.  Does the user really want a shiny new sports car (not another car analogy! :) that turns into a Yugo after a few weeks?

Concentrating on the aspects that are important to the user, while ignoring aspects that affect developers (modifiability, verifiability, etc) is the worst thing you can do for the users of the software in the long term.