Quality Is Speed

Nov 30, 2009   //   by Hackadelic   //   Blog  //  No Comments

Quality Is Speed - that's why Intelligent Solutions MatterOf all attributes a product or service can have, quality is one of the most mistaken ones. From a sales viewpoint, quality seems to be natural. Everybody claims to provide stuff of “premium quality”. So much so that we, as buyers, seem to take quality for granted. Heck we don’t even attempt to demand it.

On the other hand (and you know this if you’ve ever been on any kind of development project1), quality assurance is treated solely as a cost factor, a necessary evil, a bitter pill that has to be swallowed in order not to disgrace oneself on the market, and avoid the much higher costs of a product recall or such.

I want to present a different view on quality in this article – one that avoids the negative connotations above, and most importantly: a view that matches reality.

[toc style=”margin: 1em 15em”]

What’s wrong with the “traditional” view?

When quality is treated as necessary evil, it should be obvious that any one product or service will have “just enough” quality, and no more.

But is that enough?

I say it’s not. I say, you, as a buyer, should explicitly demand quality.

Why? Read on…

Types of quality

Every product crafted by human work has two types of quality: External quality and internal quality.

External Quality

External quality is what is externally perceivable. For a software application it is, for one, the UI: Graphical appeal, look and feel, smoothens of operation etc. For another, it’s the lack of visible defects (bugs). I stress “visible”, because bugs the user never sees don’t impair the externally perceived quality.

The one thing that external quality has in common no matter the product, is that you don’t need any special knowledge to judge about it. Hence, external quality is, in the end, a matter of opinion.2

Internal Quality

Internal quality is what you can’t judge about unless you “open” the product and look inside. Obviously, you also need adequate knowledge about what’s inside to be able to make a judgment at all.

Let’s take, for example, your TV set. You can easily judge about the color quality, or how sharp the picture is. But what about the electrical circuits? Are they designed in a way that’s robust to electrical or magnetic disturbances? What about the used integrated circuits? Or the used materials? Have they been chosen with durability in mind? Or will you have to buy a new device next year?

The same about your car. You can easily judge about how the engine sounds.3 But you better open the hood and take a look under it before signing that check (especially with used cars). And if you don’t have any knowledge about car engines, you better take with you a friend who does.

Internal Quality in Software

With software it is no different. Except maybe that nowadays software tends to be much more complex then any hardware device. Hence it is much more important for software to be of high internal quality. Otherwise it may stop working (crash, or produce false results) under conditions when you least expect it. Just as if your car’s engine stopped right there when you were driving up that hill, and you start rolling backwards.

Why Average Software Quality Sucks

There is one more thing with software that is special compared to other types of products, a thing that makes things worse on the quality frontier: The entry barrier to writing software code is so damn low! Especially with open source software.

What this means is literally: Every prick with a keyboard can write a line of code. Education? Computer science? Who gives a shit! Look: I can write an IF and a FOR and a WHILE… What else is there to know?

Well there is! Things that you can’t learn from syntax alone, or by just harking to the ideas in your head. Things like principles and patterns of good software design. Things like abstraction, and conceptual clarity. Exactly the things that make the difference to internal quality.

Most of us who know sh*t about TV devices wouldn’t dare to mess around with the entrails of our TV. But how many are quickly at fiddling around with their web application’s code? Too many, as I happen to know.

The result: An ocean of inferiorly designed programs. This is especially true for the web field, where open source is the rule, and budgets are tight.

Getting a clue about internal software quality

While generally it is true that you need special knowledge to judge about internal quality, there is – and this is special about software – one thing you actually can get a clue about the internal quality of a piece of software, even without any programming background.

A little quiz question:

The more lines of code go into an application, the more it is worth. Right or wrong?

Wrong!

If you would have to pay for it, you want to pay for the amount of usable features, not the amount of code it took to implement them.

The more intelligently a solution is designed (a process that starts with concepts, and ends with code, and which requires intelligence and craft4 all the way long), the less code it will have. Of course, there is a natural minimum to the amount of code it takes to implement a particular feature set, but – as I have sadly experienced – there is no natural maximum to it.

So one metric for good internal software quality is the amount of code per feature. I call this a software impact factor. Drupal is an example of high-impact coding. It is much smaller than other CMS’es (roughly the size of WordPress), while providing a similar, or even better, set of features. (And that’s the reason why I struggled a lot with myself to decide against it for my website, but that’s another story.)

Having a small code footprint brings another immediate advantage: Less bugs.

It has been investigated that humans err once every 100 actions on average. (With a huge variance though: Some err once every 10 actions, some every 1000 actions.) The interesting thing is: It does not seem to make a huge difference what kind of action we take.

In the context of software engineering this means: Every developer errs once every N lines of code (where N is individual) no matter what. In other words: The less code it takes him to solve a problem, the less bugs there will be.

Ergo: Intelligent solution design matters.

Why does internal software quality matter?

For one, internal and external quality correlate to some extent. Of course it seems obvious that you can’t have a piece of software (or anything) that externally appears a masterpiece, while being crap on the inside. But there’s more to it.

Why would you want to have less bugs at all? Besides the obvious reasons, here is one that’s much less obvious, and at the core of this article’s message:

Quality is speed!

You pay for a piece of software because you aim to achieve a goal. On the way to that goal, you don’t want to stop to fix the software. Market pressure rarely leaves you enough time for this. Especially on the Internet.

Ideally, you want bug-free software. And the less code there is, the closer you are to that ideal.

Alas, that’s unrealistic a wish. In the case you have no choice but to take a pit stop and fix bugs, you want the pit stop to be as short as possible. Hence, you want software that’s easily changeable. (The buzzword for this is maintainability.) Quite obviously, less code is easier to change (and fix) then more code.

Again: Intelligent solution design matters.

But goals also change. When this happens, you would want to change the software to match your new goals. Again you need easily changeable software. And again, less code is your advantage.

Once more: Intelligent solution design matters.

Technology And Quality

Often, it is not only the software that’s specifically written for the application, but the underlying technology that makes the greatest difference. Technology includes, among other things, programming language and platform on top of which an application is implemented. Choosing the right technology foundation for a solution can dramatically decrease the amount of application code that needs to be written and maintained. So yes, the technology choice needs to be made intelligently.

Hence (you guess it): Intelligent solution design matters.

Conclusion

Software does not become easily changeable by accident. It does so by design. This is the difference between being able to program a loop, and being able to create intelligent solutions. And you need intelligent solutions in order to have the right kind of quality, because:

High quality is the prerequisite for high business agility.

Unless, of course, your business does not have to rely on software in any way, and the computers in your company are only used for playing games and “reviewing” adult material. 😉

  1. not necessarily software development []
  2. And we all know, opinions are like a*holes – everybody has one 😉 []
  3. BTW, did you know that car manufacturers employ sound designers who take influence on the overall design in order to achieve a desired sound. With every new car generation the sound that you actually hear when you are inside it has less to do with the actual source, and more with tricky sound design. []
  4. and knowledge, and creativity, and … []

Comments are closed.

I have come here to chew bubblegum and kick ass...
and I'm all out of bubblegum.
-- Nada in They Live