Processes with build-in defect loops

From time to time i hear stories of organizations - or to be more specific managers - that struggle with agile concepts. One of these stories goes like this:

A manufacturer restructures its processes and some younger engineers propose feedback loops - build something, test, find defect, fix defect, test again until no defect is found, release. This little loop is frowned upon by the elder managers, because their expectation is that their engineers produce defect free products and if there is a defect it has to be managed by an outer feedback loop as defined in their processes - customer finds defect, service is informed, service validates, engineers get involved, engineers fix defect, release fix, customer applies fix. A development process with a build-in defect loop just sounds wrong to them.

Now this story is a bit old, but i guess somewhere this might still be the present reality. I won't argue, why this elder manager believe is not perfect and probably even far from the actual working-process of the engineers - for a deep dive into this topic there are many good books, articles, .... Instead i want to provide just another little argument, which i stumbled upon while doing some home renovations, to convince managers, which might be stuck in these believes.

The painter

From time to time i do some renovation in my home. I am not good at this, but i do it nevertheless. Renovations also occasionally include painting somethings - a wall, a window frame, a board, ... Many years ago i would just take a brush and start painting. And thus i had the opportunity to learn what every professional painter knows: Paint does not always stay where you apply it - mostly it follows gravity and decorates the surroundings with many little droplets. So after every paint session i had to do a intensive cleaning session and sometimes i even missed some spots, because i would never have expected that paint would go there - but it does.

After a few years with this painful experience - yeah, sometimes i am a slow learner - i discovered basic painting equipment and practices: Cover the ground and any parts that you do not want to be painted, either by tape or a plastic blanket. The droplets will still happen, but 95% of all droplets will do no harm and the painful cleaning session after the painting either are not necessary or much less painful. Every professional painter does it that way, because every professional painter recognizes that he will spill paint.

End of metaphor

Now back to software. The paint droplets represent our software defects. They happen, even when you are a seasoned professional. There are two strategies outlined on how to deal with these defects: painful cleaning session after the actual work - which represents the elder managers view - or having a safety net, which recognizes that droplets are bound to happen, but their probability to cause any harm is very much reduced. If you ask an 'elder manager' what kind of painter he would prefer, the manager would most likely prefer the one with the safety net, because that is what his intuition would tell him (painting is much more tangible than software engineering).

As a professional software engineer your safety net - your tape and blankets - are feedback loops, which should be small, fast and lightweight. If your organizations processes or elder managers cannot recognize this fact you have to convince them. And this little comparison with a professional painter might be helpful in this endeavor - feel free to use it or any other suitable comparison.