Monthly Archives: July 2010

Fail Safe Processes

My first job was working in the aerospace industry, working for McDonnell Douglas (which is now part of Boeing). One tenet drilled into me during my tenure building military aircraft was the concept of “fail safe“.  One example of a fail safe design is the control switch for the C-17 hydraulic pumps. The primary pump is directly connected to the engine, and is on by default. If the pilot wants to turn the pump off, he or she presses the button which applies power to the solenoid to disable the pump.  Since hydraulic pressure is required to fly the plane, turning the pump off is an unusual condition, so active power is necessary to disable it. If any of the components in the chain fail, the pump stays on, which is the safest condition for the aircraft.

One question that this experience leads me to ask, during a design review is “how is this design fail safe”.  But, this video reminded me of systems that are inherently in-stable and got me to thinking about fail safe processes.  Which processes at work would go out of control without personal intervention?

Continue reading

Life of a Cowboy

The life of a cowboy would be perfect, if it weren’t for the cows.

Successful entrepreneurs know that its vital to talk to actual customers.  The business plan may be solid, the product incredible, but without customers, the business is nowhere.

If that advice is sound for a small business, then why does it frequently break down in large businesses?  Talking with actual customers is not the job of the software development team, but instead the role of the marketing, sales, and support teams.  Job specialization has been the hallmark of big business since Henry Ford.

Here is a little secret, large businesses are really collections of small businesses.  Senior management at large businesses look at each department as individual smaller businesses.  They will construct a P&L (Profit & Loss statement) for each department, and praise those with earnings that improve the overall bottom line.

So, many of us work in larger businesses, but in an individual product line.  Think of your product as a small business, one where funding comes from your success as a product.

What does this have to do with Software Quality? Well, as a software quality professional that follows the Context Driven School of thought, we believe that practices should be applied in the given context.  Many practices that are common in small businesses seem less important in large businesses.  Specifically, interacting directly with customers.

In a large business, interacting directly with customers is someone else’s job. The sales or support team are on the front lines, protecting the dev/test team from having to spend time with customers.  Small businesses don’t have the luxury of separate departments, so the development & quality team get the benefit of interacting directly with customers.

For those of you in large businesses, what would you do differently? What are the artificial constraints that prevent you from talking directly to customers?

What does talking with customers have to do with cows and cowboys?  I’ve frequently seen the similar attitude in software development & quality, where we really enjoy our jobs and practices, but find that working with customers can become a real inconvenience.  Customers want changes that mess up our great specifications. Customers don’t like the cool feature we just developed.  Customers found a bug by doing something they shouldn’t have been doing.

However, we need to remind ourselves that the customer is always right, and its all about how the customer defines quality.