Category: Uncategorized

Posted on

Five Errors Managers Make About Quality

Often quality programs are not begun owing to errors in the thinking of management.  That might not surprise cynics, but it doesn’t have to be the case.

Lets clarify a few of the misconceptions about quality programs that might be lurking in the synapses of managers … if we are ever going to get a quality process in place

Crosby defines quality as “conformance to requirements” … the nice thing about that definition is that it is as meaningful for software as it is for manufactured products.  It also makes the definition quantitative rather than qualitative.  Because who wants a qualitative definition of quality?

Many people seem to think that quality has no objective standard.  That it is purely subjective.  The nice thing about “conformance to requirements” is that it makes it objective and therefore measurable.  And what you can measure, you can manage.

It is hard to “conform to requirements” that are undefined. We have worked for years with an ERP system that was clearly built without any overall vision of what it was trying to do.  You can always tell when software has been written without any defined set of requirements – and I don’t care what software development lifecycle model you use – if you fail to define what you are building before you build it then it will turn out to be a cobbled-together mish-mash of half-baked features.  

The 5 erroneous assumptions about quality plaguing management … and therefore organizations … prevent quality processes from getting a start.  Here they are:

Quality means “goodness” or “luxury” or … the relative worth standard.  Makes “quality” look like “gold-plating” and that reeks of expense with no ROI.  But taking the definition of “conformance to requirements” corrects that error.

Quality is intangible and therefore unmeasurable.  And what cannot be measured cannot be managed.  But it is measured by the cost – the expense – of non-conformance.  Re-work, fixing defects after they have been deployed, missed schedules and budgets all result from non-conformance.

There is an “economics of quality,” viz. an organization cannot afford to make things well.  Often this originates in a short-sighted or narrow point of view.  Fails to consider the overall lifecycle of the code – even if it is an MVP.

All problems of quality originate with the “worker bees” – especially in manufacturing (which doesn’t concern us in the software business) – in our case the programmers/coders.  In fact, quality processes should permeate the organization … the worst quality problems are those in management because they have the greatest multiplier.

Quality originates in (or is relegated to) the “quality department.”  Everybody in the organization is responsible for quality – has to care.

As Juran said: “It is most important that top management be quality-minded. In the absence of sincere manifestation of interest at the top, little will happen below.”  So top management needs to be convinced, persuaded … or the whole effort will go nowhere.

To recap … We define quality as “conformance to requirements,” and how closely a work product conforms to its requirements is measurable

That means as long as you take care to define the requirements then the quality will be measurable and therefore manageable.  And if you don’t define the requirements then just what the heck are you building?

Posted on

How much refactoring is too much refactoring?

Here’s a question that came across the transom … it had to do with “… a 2-week Sprint where we went through a massive code refactoring in one of the major modules “ one of the quality engineers was wondering if the development team was being ineffective/inefficient …

The Question from reddit user

  • We are working in a 2-week Sprint where we went through a massive code refactoring in one of the major modules (a web module); the developers’ (5 of them) justifications were:
    1. At the time of the development, they didn’t know how to develop it
    2. To make the codes better for future development
  • After testing was completed, and suffice to say, was grueling as the tester had to go through multiple Sprints tickets and test cases just to re-test all the refactored codes, one of the developers took a ticket from the backlog where it also enhanced another “sub-part” of the module; therefore the tester now needed to re-test 30-50% from the same module again, and the test had to be done within the same Sprint.
    Unsurprising, the tester asked, “if this is the case why wasn’t that “improvement” done on the prior work since the work itself is very close to the already completed work? The developer said it will not be as difficult as the prior one, which seemed to be an attempt to appease the tester, but the tester was not having any of it and complained to the test manager that the development process is being ineffective and inefficient in their development work, wasting testing time.
  • To the experienced QAs, what do you think of this situation? Is the development team being ineffective and inefficient? Was the tester right in concluding as such? What went wrong?

My response:

  • The question posed (constant code refactoring) and the scenario presented looked like two different things. So, first step is to validate that we were dealing with a chronic – rather than an acute – problem.
  • If the “massive code refactoring” was needed – and both rationales presented appear to be adequate reason for re-factoring – then there should be little argument about doing it. That doesn’t make the refactoring “constant” unless it recurs sprint-after-sprint-after-sprint …
  • If there is constant refactoring then there is a serious project management/engineering breakdown. The quality problem in such a case is far removed from testing because the is a systemic process problem leads to a lack of stability in the product.
  • In the case where there is a single “massive re-factoring” (not constant) then … having left major issues lying around in the backlog and/or allowing major issues to be picked up late in the sprint … that is a different project/engineering management issue. It suggests that the estimates of the effort required may have been be seriously flawed.

What does it take – what does it cost – to write one line of code?  What do you include in the “what does it take” – documentation (user and developer), what quality assurance activities are needed, what tools or environments are needed, etc.

In our consulting practice, we have seen projects running with no estimates whatsoever.  And no process for improving estimates, if there were any.  How do you know how many user stories can be developed or issues resolved in a sprint if you have no idea of what it will take? 

Estimation of the complexity of software work is notoriously difficult.  New, green field development, often has so many unknowns that it seems impossible to estimate.  My very first comp sci instructor’s rule of thumb seems to work:

  • Take your first impression (guess) of the time it will take.
  • Multiply it by 2 (or 102)
  • Increase the units by 1 order of magnitude
  • So … an original estimate of 4 hours becomes … 8 days

It is appropriate for a manager (or customer) to ask: what will it take (cost, effort) to get something done?  How long – wall clock time – will it take?  If you cannot answer those questions then it doesn’t matter how “agile” your process might be … you should not proceed.

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?”

Posted on

What is Quality in Software?

As you might imagine, software quality assurance is the application of quality principles to software.  So starting back at the beginning … what do we mean by “quality?”

Many definitions suffer from being self-referential: “… the act or process of confirming that a firm’s quality requirements are being met.”  And those that aren’t may be too 

specific – or focused – on a particular industry.

Quality, by definition, moves from characteristic … to essential character … to superiority of kind; excellence

1a. An inherent or distinguishing characteristic; a property: the medicinal qualities of a plant.

b. A personal trait, especially a character trait: “The most vital quality a soldier can possess is self-confidence” (George S. Patton).

2. Essential character; nature: “The quality of mercy is not strain’d” (Shakespeare).

3a. Superiority of kind: an intellect of unquestioned quality

b. Degree or grade of excellence: yard goods of low quality.

And it is that final definition that works for software.  But still what does it mean for something to be “superior” or “excellent?” We all have an idea of what quality – especially high quality – is in the sense of a degree of excellence.  We especially sense its lack, when it is missing.  Which it often is in software, but I get ahead of myself …

Automobiles are a great way to discuss quality differences.   There are many examples of pretty crummy (Yugo, I’m looking at you …) to blah to meh to good (Lexus) to great (Lamborghini) vehicles … but we can all tell – often just by looking, but always by driving – where a vehicle fits on that spectrum. Often, but not always, the shoddiest goods are the cheapest – or, at least, less expensive.  Some people – like me – are willing to pay more (within reason) for higher quality products.  Why?  Well, because they are often more serviceable – a better fit for their purpose.  Or they last longer.  Or they perform and/or look better while doing it.  Note that only some of that can be measured … lasting longer, for example.  Whereas “looking better” is usually a matter of taste. 

Note: In my ‘verse it is not important what other people think of me based on what I own or use … I am more interested in the intrinsic quality of the product rather than “keeping up appearances.”  Others’ mileage most certainly varies …

Applying all this to software – my industry and, hence, my particular focus – is pretty straightforward in some of those cases – for example, fitness for use.  How well software does what it is supposed to do – if it is supposed to compute a value, does it do so accurately (so that it is correct) and reliably (so that it can repeat the calculation with the same accuracy over and over again). The more complex the system, the more challenging it is to assess IT quality.  There may be things it does well and things it does poorly so that the question then becomes one of racking and stacking the relative importance of those things it does.  And, yes, different people differ on what is more/less important.

Posted on

Drawing a Blank; Sketching an Empty

Undisturbed snow

The blank page sometimes resists mightily the pen. Almost, the pristine surface – unmarred, unstained – is like a field of fresh snowfall that wants, above all, to remain untrodden.

What thought is worthy enough to disturb the peace and order of the tabula rasa? Like mindful speech, writing should improve the blank page. Most doesn’t.

There is an impulse to distraction – like a very mild l’appel du vide. It is a call to immerse the consciousness in a sea of banality (the internet). Like most bad impulses, if resisted then this, too, shall fade. With time (and adamant rejection), this impulse will join other such on the ash heap of thwarted, disordered, escapist tendencies.

Distraction wins when there is no better habit at the ready.

The better habit that should be always available is the habit of stillness. And stillness is that pristine surface of an undisturbed soul resisting, placidly, being marred.

Posted on

Let’s Get Started

A new blog is like starting a new book. It is more than just a blank sheet of paper – a tabula rasa – an empty notebook with an unlimited number of pages. A new blog is an opportunity to

This blog is intended to be a forum for the ideas that I find provocative or, rather, evocative … and a forum for thoughts on solutions to problems faced by my readers. The former, I will generate; the latter can only be in response to your thoughts. So … if you have a problem, challenge, or issue that may benefit from a different (if not dispassionate) point of view, then send it via the contact page or post it in the comments below.

Thanks for joining me.

More anon …