First, it is ridiculed,
second, it is violently opposed,
third, it is accepted as being self-evident.

- Arthur Schopenhauer

Our society has passed through thirty years of tearing down established wisdom.  We’ve witnessed a housing bubble where the traditional thinkers were ridiculed.  We’ve witnessed a stock market bubble where the traditional thinkers were ridiculed.  We’ve witnessed many business practices embraced where the traditional thinkers were ridiculed.

We’ve witnessed long established truths replaced with popular theories.  They seemingly worked for a while, which reinforced their support and broadened the appeal, but as they were working, they were sowing the seeds of their own destruction.

Well, here we are with the aftermaths of a stock market bubble and a housing bubble.  Traditional truths that were formerly ridiculed are suddenly accepted as being self-evident.

Oh, the stages truth must pass through to become accepted, and oh, the damage wrought until then.

“Jack Welch, who is regarded as father of the “shareholder value” movement, has said the obsession with short-term profits and share price gains that has dominated the corporate world for over 20 years was “a dumb idea”. ”
– Jack Welch

Jack goes on to say,

“On the face of it, shareholder value is the dumbest idea in the world,” he said. “Shareholder value is a result, not a strategy…your main constituencies are your employees, your customers and your products.”
– Jack Welch

Read the Financial Times article Welch rues short-term profit ‘obsession’

Corporate obsession with short-term profits has been a contributing force behind the adoption and advocacy of the Agile Software practices.  As I’ve argued repeatedly, customer satisfaction and product success isn’t about process or delivering faster, it’s about creating a great user experience. 

Customer value is a result of building a great product; building a great product is the strategy; customer satisfication is the by-product.  In fact, short incremental releases often result in less customer satisfaction, not greater.  

Customers are not the software team’s QA department or product marketing team.  

If you need the customer to tell you exactly what to build, you aren’t the team to deliver on outstanding customer value.  If the customer needs to be a constantly contributing member of your team, you DEFINITELY ARE NOT building the next thing. 

Great people committed to teamwork build great products.  Teamwork is the only time when it’s possible for 1 + 1 to equal 3.  Great teamwork is the only instance when the whole is greater than the sum of its parts.  While individuals are important, the team is most important.  Good process is a manifestation of GOOD TEAMWORK.  Agile’s emphasis on individuals is misplaced. 

Our culture’s obsession with individual’s interest over society’s interest is what brought us to this inauspicious moment in history.  Perhaps we can once again embrace the principles and values that run throughout every modern religion and put the interest of mankind first. 

We do this in business and software development by putting the interests of the company, the shareholders, the customers and the team first.  We lost those priorities along the way with our avarice and obsessive focus on stock options, the stock price, bonuses, and empty careerism.   Where’s the “I” in teamwork? It isn’t.

I’ve been away from blogging on software while I’m busy with another project that unfortunately is consuming all of my spare time.   I couldn’t resist commenting on this article because it rebuked the culture that brought us all here to this moment.  We get angry at Wall Street for taking huge bonuses while their companies are sinking and receiving bailouts from the taxpayer, but we’ve all been part of that culture of excess and greed.  It’s time to begin heeding the words in the Michale Jackson song:

If You Wanna Make The World A Better Place
(If You Wanna Make The World A Better Place)
Take A Look At Yourself, And Then Make A Change
– Michael Jackson, Man In The Mirror

It’s nice to see that “Old School” Values are making a comeback.  Too bad, we have to pay such a painful price to learn what we should have known.   The Agile movement had one thing right: CHANGE IS GOOD. It’s time to CHANGE! This is our wake up call.   WAKE UP!

When I review the articles published to this site over the last quarter, there is a dominate theme for the quarter.   The theme deals with the mistaken trade-offs of delivering products faster.  Our culture has become increasingly impetuous.  Many buy homes without saving for down payments.  Many lease to drive cars that would be, otherwise, too expensive to purchase outright.  The investment community has become increasingly speculative where promising high risk investments are outrageously favored over modestly priced companies with strong balance sheets, good earnings, and promising but modest growth rates.  Parents purchase new vehicles for their high school children instead of teaching the lessons of working and saving to get what they desire. Executives destroy the balance sheets of great companies to satisfy Wall Streets expectations for quarterly earnings.  Political candidates maliciously and falsely tarnish the character of their opponent rather than invest in the hard work to make the case for their policies and leadership.  In software, many start coding before completing sufficient analysis and design, and many accept requirements change without fully analyzing the impacts. Society increasingly mobilizes to satisfy its desires and needs quickly; however, satiating too quickly comes with grave consequences as we are seeing in our economy today.

I fear little-by-little we’re losing the culture that has made America the eminent economy of the world: the culture of preparing intelligently for the future.  We’re forgetting the lessons of Aesop Fables, “The Ant and the Grasshopper:” the lesson of sacrifice and preparation today for tomorrow’s needs.   The future is a current requirement.  It’s why we save in 401(k) plans for retirement.  It’s why we send our children to school.  It’s why we purchase insurance policies.  Without proper investment in the future, today, the future, that we arrive at tomorrow, is likely to be regrettable.

Of course, there is a balance that needs to be struck between today and tomorrow.  The proper mixture cannot be reduced to a formula or a set of rules. The right balance is unique to every situation.   Sometimes the balance favors the future as children spend most of their time in school preparing for the future.  Other times, the balance favors the present when health issues strike.

I recall an interesting study presented on 60 Minutes a number of years back.  The study concluded that those who are able to postpone present gratification for the promise of a larger future benefit are more likely to be successful.   Isn’t that the promise of a college education?  Doing the hard work, today, of earning a college degree holds the promise of a more prosperous future.

If you think about it, though, all product development is an exercise in satisfying future requirements as the typical software product release sells for one to two years before the next release hits the shelves, and development typically requires six to twelve months of effort to create the application and to prepare it for delivery to customers.  Consequently, the debate is less about making tradeoffs between the present and the future, and it’s more about assessing how far into the future that we should prepare.  Many of the problems that society is dealing with today are the consequences of bad decisions made in the past – and in many cases the future wasn’t even considered. 

In the business of product development striking the proper balance between present requirements and anticipating future needs is an art, requiring a mixture of experience, talent, knowledge, and vision.  It’s essentially a function of leadership, leadership that seeks council and then decides.  Those leaders who strike the right balance win and secure longevity in the marketplace.  Those leaders who wrongly favor the present are doomed to a regrettable future since opportunity is realized when good decisions about the future are made in the present.

You’ve probably heard someone say it, or you may even say it yourself:  “You design quality into a product; you don’t test quality into a product.”  The last time when I heard those words uttered, I had to restrain myself from reacting.  What did this person mean by that?   The product was in trouble.  It released late and with low quality.  Customers were rolled back to the former version, and now the product marketing team fears that if things aren’t corrected soon they will lose market share.

Did the person mean you can’t expect QA to find all the defects? Well of course they cannot.  Or perhaps it was meant that you cannot expect QA to certify that the release is ready for customer consumption?   I hope not.  In my opinion the primary purpose of the QA effort in any release is to certify that the release is ready for customers to begin using for their everyday purposes. 

Customers should expect when they purchase a software product for it to perform the functions as advertised flawlessly.  Isn’t that what we expect from our automobiles, our televisions, our iPods, our radios, our phones, our refrigerators, our toasters, and the myriad of products we purchase for our everyday uses?  I’ve seen people nearly lose it when they discover a small scratch on their new vehicle that they missed when they picked it up from the dealer.  While I agree that you design quality into a product, I don’t believe that assertion changes anything about the QA mission.  Let’s take a look at what are some of the sources of defects.

1. Requirements are not defined correctly or are misunderstood.
2. Design has flaws.
3. Code has flaws.

Of the three points where defects can be introduced (requirements, design, and code), the best design would only prevent 33% of the defects from being introduced as the design phase is only one third of the sources of defect introduction, assuming defects are introduced evenly between the sources.  Even the best design team would still introduce some number of defects at the design phase.  Let’s assume for a moment that the team was excellent at reviewing the requirements, design, and code, we would still expect some number of defects to slip through.  Further, let’s assume that the developers were very good at unit testing their code; we could still expect some number of defects to slip through.  Plus, unit testing isn’t the same testing as system test.  The QA team traditionally executes system test.

If we do an excellent job at requirements, design, code, unit testing, and reviews, does that reduce the need for a thorough and comprehensive QA test suite?  I think not.  One, if we can agree perfection is impossible to achieve, there is no telling where the defects — however small in number — will be found in the application, and so you have to test as if there are potential defects anywhere in the application; otherwise, why have the test phase?

The QA role in the lifecycle of the release has many folds, but the function of the QA lifecycle is to make certain that the project has satisfied its objectives, which includes the product being ready for customer consumption.  These objectives are shared by the developers as well, but it’s the responsibility of the QA team to certify that they have been achieved.  Consequently, whether the work products delivered to QA for test are great or poor, it doesn’t change the workload or the expectations of the QA team.  These are the objectives of the QA team:

1. To make certain that all the requirements have been delivered to specification in the release.  The QA team has many customers, but the business team customers rely upon the QA team to certify to them that they are getting what they asked for.
2. To make certain that changes to the product haven’t impaired any of the existing functionality.  Existing functionality works as before the changes were introduced.  This is normally covered in comprehensive regression test suites.
3. To make certain the new and existing functionality meets quality objectives.
4. To make certain the application performs to performance specification.

My expectation is that once the product exits QA after having delivered on these objectives, the QA cycle has confirmed that the software will meet the customer’s high expectations for quality – expectations like we have for everyday products.  Whether quality was designed into the product or not, I don’t see how any of these objectives can rightfully be skipped.  If the software engineers introduced few defects or many defects, it’s the purpose of the QA team to find them and to at least know whether the release decision is prudent or improvident.  Actually, it’s their information that should be the basis for the release decision.   So what is meant by “You design quality into a product” juxtaposed with “You don’t test quality into a product?”  T o me it only says QA cannot fix a poor design.  They also cannot fix poor requirements and poor code, but they better have an opinion on it, and they better have detected poor requirements, design, and code when it’s present. It’s up to someone else to fix it, of course.  What are your thoughts?

I often wonder why software teams always seem to be committing to unrealistic schedules.  You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what?  The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.

It’s not just the sales organizations though; the software organizations are all too happy to over commit without any help from outsiders.  You probably have one of those programmers on your team that when you ask him for an estimate, he says a week and three months later he’s still working on it.  When you ask him what happened, his answer is well it was a bit more complicated than I thought.  Does he learn from it? No way. Ask for an estimate on the next project, and he’ll still quote a week.

I often wonder if these same people would commit an organization to building the Empire State building in a month.  It sounds ludicrous, doesn’t it? But, software teams are asked regularly to deliver on similarly impossible feats — well maybe not on the scale of building an Empire State building in a month, but you get the point. Really, even these same salesmen wouldn’t make that kind of commitment for a building because even to them, it’s an impossible effort.

What is it about software that makes it so likely that the sales teams and engineering teams will over commit?   I believe a large contribution – not the only — is that we haven’t been successful in using metrics to size our projects.  The entire construction industry doesn’t make a single commitment to a project without knowing the size of the project.   Before you’ll even get a ball park estimate from a contractor for time and money, they want to know how many square feet the project is.  Even a salesman, without even knowing the exact square footage of a similar proposal to constructing the Empire State Building, would know just by looking at the plans that a month is an impossible commitment.  While he doesn’t know exactly how big it is, he knows it’s huge, and a month won’t be enough time.  In software, they just have no clue, and it’s the fault of the software profession.

It is my belief that we can begin correcting this problem if we can begin to size our software projects using a consistent unit for size.   The measure needs to be pushed all the way out to the team members who are making commitments for the organization.  Initially, the metrics won’t have much meaning to those people hearing and using it, but after they see the time and effort required to deliver projects in those units, they will develop a feel for what it takes to deliver functionality in those units, and they’ll be able to roughly size projects themselves after gaining experience.  They’ll at least have a feel for whether they are committing the organization to constructing the Empire State Building in a month or less.

At a minimum, when sales teams over commit, they’ll know it as soon as the software organization returns the estimates, and possibly more productive conversations about how do we fix it can be had, instead of work harder when it’s obvious that working harder won’t solve the problem. If every project that was 500 units in size or greater took 6 months or greater to deliver,  it’s obvious to all but the dullest minds that something needs to change to deliver 500 units in 3 months as was committed.  Only then can we begin to have productive conversations.   What are your thoughts?

Periodically, I plan to write a reflections essay on a peculiarity in the way we practice software development in industry — at least in my experience.  I hope to bring a new perspective on the topic, and I hope you comment with your thoughts and experiences.