
Do Not Treat Quality as a Separate Activity - techiferous
http://techiferous.com/2016/01/do-not-treat-quality-as-a-separate-activity/
======
ddingus
This is straight up LEAN type thinking. A core tenet of LEAN is the
understanding that quality is an intrinsic part of whatever process is in
play. A secondary one is short feedback loops coupled with localized authority
/ capability to identify and resolve problems quickly. (and I've taken
liberties with this to frame it in somewhat relevant terms for software)

...those get reported upstream and ideally are used at the front end to
improve though efforts like design for manufacturing. Translated to software
might result in "spec for coding", meaning easily identified tests happen up
front, library / common code use cases factored into the spec to limit new
feature create to those features actually adding value, not redundancy, etc...
Less new code, more code generated code, and reuse of code.

Additionally and regardless of the up front changes, I see this as writing
tests concurrently with writing the end use code. Spec, test, code, in LEAN
terms, are tightly coupled and managed together. At first, doing this is an
investment. People require training, process issues, communication issues,
flow issues all will combine to lower the overall productivity. But, it tends
to resolve and then resonate. Once that point of resonance hits, everyone gets
it, quality will go way up as will productivity.

It will remain possible to go faster in the short term, and that risk / reward
will always be tempting too. What is worth what?

That, to me, is the most interesting question.

~~~
techiferous
Yes, exactly! Thank you for expounding. Yes, this post was indirectly inspired
by LEAN, as I picked up this idea from a conversation I had with someone who
used to manage manufacturing.

~~~
ddingus
It's a great parallel. I've thought so for quite some time.

The really hard part is bootstrapping LEAN. For people not used to the way of
thinking, it's hard, gets in the way, isn't as fast, etc... Push back inertia
is often high and often requires a sustained investment to eliminate.

Back in the day, when I was doing a lot of manufacturing, the pressure was
always get more done right now today. A good friend and mentor picked up on
LEAN and I applied it in my daily work. Caught a lot of heat for it, and the
dynamic was this:

Do you want them fast, or high quality today? Pick one, or leave me and the
others doing LEAN alone, and you will get both over a reasonable, and dare I
say, "lean" amount of time. That's how it can start. Ideally, management buys
in, and drives it from the top, but it can start and spread with a group using
LEAN to significantly reduce costs and improve performance without losing out
on quality. Once it gets going, it gets noticed fairly quick. Excellence in
those metrics is hard to miss.

Make the investment, take the hit in productivity, and come out the other side
a much more competitive, efficient and high quality organization.

Tough sell, but very worth it. LEAN works, but everyone involved has to really
do the work, really does have to buy in and really does need short cut
discipline for meaningful gains to be had. Process is tough when a release
deadline looms. Frankly, it might not be appropriate for all software cases.

