Brian On Software

As promised in my review of The Big Moo, I will share with you three different lessons learned from reading the book.  The first lesson deals with compromise.  The field of software development is full of stories about products being bloated with unwanted or unnecessary features, costs overrun, late delivery dates, etc.  One reason that explains the cause of this is the lack of courage (that’s right, the same courage that Kent Beck preaches in Extreme Programming) from developers, analysts, managers or any serious project stakeholder to say “Hey, wait a minute!  I seriously we should think about this before we go on!” for example.  Lacking courage in such situations can make place for compromise to settle in and take more space than it should be allowed.  Once compromise is leading the project, the product will suffer, your team will suffer, your organization will suffer, your customer(s) will suffer, and this profession will suffer.  So why should you keep an eagle eye on compromise?  How can you avoid it?  Why should you avoid it?  This first lesson is well told in the essay title “The Problem With Compromise“.

Here’s the full text of this essay (author unknown):

The Problem With Compromise

“Any organization with more than one person in it is a place of compromise.  If you want to get something done, a project okayed, a budget approved, a product sold, you’re going to have to compromise.”

“Most of the time, it seems as though half is better than none.  If you refuse to compromise, nothing happens.  And this desire to make it happen explains why so many things are mediocre.  It tells us why it’s so hard to make something remarkable, and why the remarkable succeeds so easily.  Because everything is a compromise, everything is sort of mediocre, isn’t it?”

“The wireless Internet access at the Denver airport has compromise written all over it.  I’m sure that when it was first designed (probably by a lone engineer in a cubicle), it was simple and fast and easy to use.  Today, however, it takes at least a dozen clicks to get started.  You need to enter a username and ID not once, but twice.  And your ID must be at least eight characters long and include numbers and a special character like $, %, or #.  So, something like “$3eVh!” is not secure enough because it’s too short.  Huh?  This isn’t your credit rating you’re protecting…it’s just the right to spend nine dollars and go online.”

“At every step along the way, each compromise to the sign-on system seemed reasonable.  At each step, the evolution of the design was simple: Either the project manager had to go along with the needs of this or that person (and the boss) or risk having the project canceled.  What would you do?  All those compromises may have made each person happy, but the final product was something that absolutely no one liked.”

“The first step to fighting back is understanding how compromise corrupts the things you’re so busy building.  More often than not, half is actually worse than none.  More often than not, you’re better off doing nothing than shipping something that is just average.  The project manager in Denver should have just stopped the project and let the chorus of complaints from passengers sink in to make the case for doing things the right way from the start.”

“Twenty years ago, Japanese car companies solved their quality control problem using a technique called Kanban.  Instead of following the American technique of having plenty of spare parts on the assembly line (workers were told to just discard a screw if it didn’t fit right), the Japanese adopted a fundamentally different strategy.  They kept only one necessary part at a time on the assembly line.  If the part wasn’t perfect, the entire assembly line stopped until a new part arrived.”

“The Americans said that this was insane.  Everyone knew that keeping the assembly line moving was the only way to make a car efficiently.  If a finished car wasn’t good enough, then you fixed it after it was assembled.”

“What Toyota and Honda understood was that the act of stopping the assembly line would send a powerful signal to every worker and to every supplier.  Sure enough, the line didn’t have to stop very often.  Every part improved in quality, because no one wanted to be responsible for shutting the operation down.  As a result, better parts improved every car as well.  With Kanban, very few cars left the assembly line in need of later reworking.  It turned out to be cheaper and faster to build cars right the first time than it was to fix them later.”

“You might try the same thing in your organization.  Refuse to compromise.  See what happens.  For a while, the assembly line will slow down or even stop.  Things won’t ship, products will get stuck in development.  And then a funny thing will happen: People will begin to understand that compromising the product just to keep the system working is stupid.  The only reason the system exists is so that you can make the things you make, right?  So if the system is demeaning your work, change the system.”

What do you think?  Are you currently in such a situation where compromise has settled in your project team?  What did you do to get out of the situation and prevent it from repeating itself?  Your comments are encouraged for this first lesson learned.