Tag: software quality systems

Posted on

The Software Quality V

A software development project is often, if not usually, complicated by many moving parts. Let’s make some sense of all that.

There have been more than a few software development process models proposed over the past 50 years.  From the engineering-/architecture-based, (much-scorned) waterfall model to the present-day “agile” process.  One thing is certain … something else will eventually come down the road … and it will be presented as the final, absolute  best possible solution to the software development process woes beleaguering software projects.  And it won’t be any of those things.  But it will solve some problems (and introduce some new ones).

What can we say is pretty universally true about software development?  Well, we know a few things for sure

  • First, we need to know what we are building before we build it.  Not necessarily the ultimate end – like an architect’s rendition of a proposed building – but we do need to know what we are building next.
  • For what we are about to build … we need to have an idea of how we are going to build it.  And if we have more than 1 person working on it … they had better have the same idea of how the thing is going to be built … or you end up like this:  ___ —-  (railroad tracks that don’t marry)
  • While building it, we need to do the construction with high quality materials (that is, code … the statements that are written need to be written well – both correct and understandable).
  • Finally, when the parts are all put together, everything works together to do what we intended to do in the first place … assuming that hasn’t changed along the way …

Agile and waterfall don’t differ from each other in that requirements precede design, precedes code, precedes integration … they differ more in the fact that waterfall attempts to build the whole building while agile – with the whole building in mind – worries more about building a floor (or a room) at a time.

Where does quality fit into this picture?  At each stage of the process … there are quality tasks/activities that pair up with each of the engineering/development steps.  The usual picture is a V with the two sides of the V representing the activities of development and quality

After the introduction of the computer “terminal” which is already an archaic term – so … after punched cards … software development has always looked like “typing” (now called “keyboarding”). And it looks like anybody can do it. As you know, if you have ever tried to write (well) even a short essay … There is a big difference between writing and typing.  There is an even bigger difference between coding and writing … and typing.

Posted on

Quality is Free

Originally published in 1979, Philip Crosby’s book “Quality is Free” is a seminal work in quality – especially manufacturing quality.  The premise of the book is that defects – poor quality – often causes re-work which is expensive. 

I’m sure we have all seen it … a road gets torn up (for months) and new infrastructure is embedded under the roadway … and then it is paved over … and construction is finally over.  And then here they come back again … tear up a part of the road that had just been replaced … and put something else in … or fix something.  If it had been planned properly… or the workmanship hadn’t been shoddy … then it would have all been taken care of the first time the road was torn up.  Re-doing it cost somebody (probably us) much more then doing it right in the first place would have cost.

With respect to software, as one of the reviewer of Crosby’s book puts it: “Very good read, but I’m not sure how well it translates outside of manufacturing – the software world is not like a production line: requirements are fuzzy, the designers are also the builders, and defects often arise from emergent complexity.” Fair enough.  However, re-work in software is much more expensive than getting it right in the first place.  That is not to argue for a “waterfall” development process (more about that later) … but just to observe that adding – or correcting – a feature after it is developed is much more expensive than developing it correctly in the first place.  Studies have shown that correcting errors after the software is fielded is 30x more expensive than doing it right in the first place.

So, quality is free – in software – when the entire lifecycle of the software product is considered.  The lifetime cost of software is heavily weighted to the lifetime maintenance of the software (we’ll define exactly what that means in a later post).  Consider that there is still software running today that was written 40 years ago.

The confounding factor – and a subject of yet another, later post – is how to decide how much focus to put on quality when you have no idea whether the software will survive in the marketplace.  How do we balance the cost of quality when building a “minimum viable product?”