On Value, Part 3: The Failure of Management

This is the third  post which resulted from a simple question my lady-wfe asked at a local tester meeting recently.

This blog post described problems with value in testing.  The second blog post looked squarely at perceptions of testers as unskilled, non-knowledge workers and the lack of response from a large number of testers. This post looks at the source of such perceptions.

I'm going to tell you a story.  Don't be scared, it has a happy ending and everyone will be happy at the end.

Once upon a time...

...there were a group of people trying to figure out how to make stuff quickly and inexpensively.  They were making all kinds of stuff: tools, pens, desks, chairs, beds, clothes, books, eye glasses, guns, railroad cars and train engines.  Lots of stuff.

One bright fellow said "This stuff is really hard to make and it costs so much to make it that no one can afford to buy it.  If they can't afford to buy it only the really wealthy will be able to afford it.  If only the really wealthy can afford it, they won't buy enough for all of us to make a lot of money and stay in business so we can get really wealthy too!"

Another bright fellow said "This stuff takes too long to make and costs too much.  If we can figure out a way to make it less expensively we can make MORE of it for the same cost and sell each one for a little more than it costs us and LOADS of people will be able to buy this stuff.  Then we'll make LOADS of MONEY!"

A third bright fellow said, "I have an idea.  Let's look at what it takes to make each of those things.  What does it take to make a desk?  What does it take to make a chair?  What does it take to make a table?  If we figure THAT out, maybe we can find a way to make them less expensively."

The first bright fellow blinked and said, "I think that's a fantastic idea!  I can sack all those expensive cabinet makers and joiners I have making my furniture and get some riff-raff off the street, teach one to work a lathe, teach another to use a plane, another to use a saw and a fourth to use wood glue and a hammer to assemble the pieces.  Brilliant!  I can charge the same amount of money, pay a fraction of the wages and I'll make a PILE OF MONEY!  I just need to get someone to divide the steps up and I'm good to go!"

The second bright fellow said, "I had not thought about it, but you're right!  I can build railroad cars the same way!  But instead of having all these specialists and experts who know how to work with steel and iron and rubber and wood and how to build engines, I can get a BUNCH of people who don't know anything, teach them each ONE PART of assembling a car, and that will be that!  I'll make a PILE OF MONEY!"

The third bright fellow said, "Ummm, bright fellows?  Do any of you see any possible downsides to this?"

The other two laughed and said "Downsides?  Don't be daft!  We're going to make a PILE OF MONEY!"

The Downside

Where craftsmen had used years and years of their own experience, and had the experience of others they could turn to for reference, the approach these bright fellow were considering would result in removing the human element from the process.

Using untrained masses to replace skilled craftsmen would certainly reduce costs - you could pay them a LOT less.  Would the end result be the same?  Well - maybe.  Not at first while the new process is being sorted.  Of course, errors would not be the fault of the bright fellows, or their immediate subordinates, but the fault of the untrained masses "not knowing their job."

The thing is, the bright fellows knew they could pile no end of abuse on the unskilled, untrained masses, and if they did not like it, they could leave and there would be MORE unskilled masses willing to take their place - and pay packet at the end of the week.

Because the unskilled masses were not un-smart, and could see their way through a wall (as they say in Bree) they knew this was exactly why the bright fellows were doing what they were, well, doing.

Because they can does not make it right.

Except... 

We're not talking about making physical things, we're talking about making software.  Software that runs on computers that human beings will be working with.  Software that people work with every day.
 .  
The odd thing is, when these conversations, and subsequent actions, happened when it was about people making things, the result was turmoil.  Societal upheaval was not in it.  Social revolution in some places, literal revolution in others.  Violence - physical, emotional and mental were the result.  The political and physical fights from that time continue to color politics in the US, Canada, Britain, France, Russia, Poland, India... the list goes on.

When you treat people like unthinking machines, expect a reaction.  It may take a while, it may not be immediate.  These days, it may not be the violence of the 1890's, or 1910's or 1920's or 1930's or... yeah.  Look at the history of the labor movement.  Not taking sides - not blaming anyone.

But it happened.

When it comes to software, most managers, directors, whatever, who have people developing software reporting to them share a common background - most were software developers at one point in their career.

Most remember the skills the had to learn, at College, University, some where, and how hard it was to gain those skills.  Then they realize that other things are needed - things they may not understand.

Customers are complaining about software and bugs and problems and ... stuff.

Management consultants come in and consult.  Except they don't understand this stuff, really, either.  So they look in their case study books for examples that look like this same basic thing - where people are making stuff.

And they come up with a model that works great on assembly lines.  Processes need to be repeatable.  Define steps and follow them the same way, every time, and you will have a "positive result."  Make sure you are following these, and other, best practices.

Sounds great, right?  And then the world looks like a Dilbert cartoon.  You know, the one (well, several) where the pointy-haired boss says something about anything he does not understand must be easy.

Many of these same bosses know that software design does not fit neatly into repeatable processes.  They understand this.  They'll talk about following the process and using "intelligent cheating" or some such.

The Fault

... lies in the belief that by breaking things into small enough pieces, they can be done by anyone - or a machine.

That might work for things where thought is not required.  Things that can be done as well, more efficiently and at less cost by a machine.  This is patently true on the modern robotic assembly lines - which are nothing more than Henry Ford's assembly line taken to its logical conclusion.

This same logic is often applied to testing.  I believe that it is at the heart of the "automate everything" and "reduce manual testing by x% per year".  On some levels, it makes sense to do things as efficiently as possible.

What happens when it is not possible to reduce manual testing by whatever that magical percentage is?  Many of those same companies will tie performance measures to these other goals.

Did you reduce the testing by the magic percent?  No?  Too bad.

Did you automate all testing?  No?  There are no excuses for "that can't be automated."  Of course it can.  You did not try hard enough.

This proves to the people doing this work that no matter how well they do their work, empty meaningless slogans trump the reality of what the work is. 

If you treat your people as machines, as unthinking automatons, I pity you.

You are wasting the potential to soar - both yours and theirs.

One more thing.

If you treat your people as machines, as unthinking automatons, I will not work for or with you.

Oh.  The happy ending?  There isn't one, at least not yet.