Recap of Part I

“We all tend to tie our self-esteem strongly to the quality of the product we produce… Any step that you take that may jeopardize the quality of the product is like to set the emotions of your staff directly against you…

…the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.”

The rest of that post described the psychological affects that compromising quality may have on a development team.

This post will highlight another problem that compromising quality can have on your development team – making it more difficult to attract (and keep) the best developers.

Part II

“We managers tend to think of quality as just another attribute of the product, something that may be supplied in varying degrees…

…The builders’ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past.”

In particular, notice the last sentence: “The minimum that will satisfy them is more or less the best quality they have achieved in the past.” This characteristic is one of the best traits we developers have – the desire to continuously improve. Kaizen, the process of continuous improvement, is increasingly attracting attention as a key factor in making huge long term gains, both for companies and individuals. It is also a key principle behind agile techniques such as Extreme Programming and Scrum.

In our industry, continuous improvement is not just a desire, but also a survival technique. Things change so quickly, if we do not improve continuously, we will not only fall behind, but become obsolete in a few short years.

With these thoughts in mind, now consider what happens when a developer is told to accept a lesser quality product. On the rare occasion, the developer might only be disappointed or annoyed. If it becomes a rule, rather than an exception, any good developer will realize this approach will lead them quickly down a dead-end path. And the more passionate your developer is about their career, the faster they will reach this conclusion.

Again, taking shortcuts on quality is likely to affect you more in the long run. Where you might be able to deliver things sooner in the short term, you are more likely to lose the developers that can deliver faster in the long run. Don’t risk losing your best people by not allowing them to do their best.

My last post highlighted my concerns with the use of the “technical debt” metaphor, ending with this question and summary:

Should quality be compromised? When?

…the metaphor of technical debt seems to open the issue of quality as being a gray area, something that can be “traded away”. The decision to compromise quality should not be made lightly under any circumstances.

I realize this statement doesn’t exactly blow your mind. Of course, quality is important. We all believe so.

So, let’s discuss a seemingly innocent scenario we may face as a development team:

In this iteration, we need to release our software slightly earlier than anticipated. We won’t have the time to do the usual refactoring cycle after development.

“We all tend to tie our self-esteem strongly to the quality of the product we produce… Any step that you take that may jeopardize the quality of the product is like to set the emotions of your staff directly against you…

…the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.”

Many managers and team leaders may think such a reaction to a relatively small decision is inappropriate. They would be right. However, as humans, we seem to be programmed this way.

To understand better, consider the Broken Window Theory, which provides further examples and research outside of software development:

“Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.”

As humans, we have subconscious feelings about quality of things around us, and we treat those things accordingly. If we have a beautiful new car, flawless and free of scratches, we keep it clean and polish it regularly. The first ding hurts the most. Over time, we get more scratches, they hurt less, we worry less, clean the car less, and care less.

Looking back to our example, the decision to fast-track the release by a few days was probably not worth the harm to our team’s morale and self esteem. The impact is largely subconscious, but very real, and does the most damage.

As creators and builders, we developers are driven by the desire to produce something which makes us proud. When robbed of this feeling, for whatever reason, it hurts more than we may even want to recognize.

The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.

As many others have already already written on this subject, I will instead focus on this question from his summary:

What do you think? Do you like the technical debt metaphor? Do you think it’s a useful way to communicate the implications of technical/business decision making to non-technical project stakeholders?

The “Good”

Firstly, yes – I believe the technical debt metaphor is a useful way to communicate such implications to non-technical stakeholders. I’m sure most developers can relate to some version of a conversation going something like this:

The Big Boss: Thanks, that was an excellent demo! Let’s make sure to get this into tomorrow’s release!

You: Umm… I still have some things to finish up. I’m planning to have it ready for testing sometime next week. I am on track to meet the scheduled deadline.

The Big Boss: Finish up? Everything is working great! What do you have left to do?

You: Well, there’s just a few changes I need to make… strengthening the exception handling, making a few improvements to the design, cleaning the code up a bit…

The Big Boss: Ah, don’t worry! The demo looked fine to me and the customers don’t care about all that! Besides, Friday is the end of the quarter and it will be great to get this feature out now!

You: (sigh…)

Of course, as developers we try to explain to The Big Boss that we still need to do the last iteration of refactoring. We want to deliver code with a level of quality that we expect of ourselves. However, often The Big Boss cannot relate. Or, at least, he doesn’t think it’s as important as we do. In this situation, the technical debt metaphor can be an helpful way to describe such issues using terminology that he is more likely to appreciate.

The “Bad”

Although the metaphor can be useful, it also has some important shortcomings. These shortcomings are especially significant in dealing with non-technical stakeholders.

Concern # 1 – The term “debt” is too soft

Overly Acceptable

Financial debt is abundant and widespread, often accepted as a fact of life. I agree that some level of technical debt is also unavoidable in doing real software development. However, especially with a non-technical manager, the decision may be made too readily to accept technical debt without understanding the full implications.

“Interest rates” are usually low

The metaphor of “interest payments” is used to illustrate the implications of taking a more “quick and dirty” approach. In these days of low interest loans, the connotations of this analogy may not be strong enough to describe the real impact of accepting lesser quality workmanship.

Concern # 2 – The “Interest Rate” Varies

When describing technical debt, the individual issue incurring the “debt” should be highlighted in terms of severity (it’s interest rate). Take two possible examples of technical debt a team may choose to incur:

Refactoring to improve naming of methods/variables of a new class is not performed.

Unit tests are not created on this same new classes.

The first example of debt may certainly impact readability/maintainability, particularly in the long run. However, this is probably not severe and would probably be fairly to change in the next release or two. It is this type of debt where the use of this metaphor seems most appropriate.

The second example of debt is more severe and will be harder to “service”. The initial code will be released without sufficient testing from the beginning. Unnecessary dependencies may have been introduced that are difficult to extract later. Future development may be severely hindered without the “safety net” of unit tests to refactor… Whatever the impact, the point is that each instance of technical debt is different and must be considered independently.

Summary – Should quality be compromised? When?

In any case, my biggest concern is the metaphor of technical debt seems to open the issue of quality as being a gray area, something that can be “traded away”. The decision to compromise quality should not be made lightly under any circumstances.

Update: My next post further describes the issues of compromising quality