Quality doesn’t end with the sale

Want to know why Toyota is the #1 selling car in America? I know one reason why. I recently purchased my first foreign car, a 2004 Toyota Sienna, from a third party. After a few months, the driver door started squeaking and popping when opening and closing, and the rear liftgate was starting to hesitate a little on opening. How disappointing to one who had expected the famed Toyota quality!

But wait, there’s more. I took it to my local Toyota dealer, who informed me that Toyota had extended the warranty for this issue to 100k miles, and also informed me of an active recall involving the rear liftgate struts. These were the major things wrong with the car, and both were fixed at no charge, even though I’m the second owner of a car with 89k miles and didn’t buy from the dealership! Until now, I’ve never heard of a manufacturer extending the warranty retroactively for a particular issue! GM and Ford think that TV commercials inspire customer loyalty, but Toyota understands that quality and service inspire loyalty, and neither ends when the car rolls off the line.

Does your software have enduring quality?

/dmc

David’s Laws of Management

1. Love your people. Listen to your employees. Give them the tools & support they need to do their jobs. Clear roadblocks. Keep hope alive. Act as though the people closest to the work are the ones with the best ideas about how to improve it. Empower them to fix what’s broken.

2. Have a plan. This is one of the greatest ways you can serve your people. If you do nothing else, when employees ask “which of your #1 priorities do you want me to work on today?” you should be able to pick one. If you can’t, what do they need you for? No problems worth solving can be solved without focus.

If You’re Too Busy, You’re Not Doing Your Job

Much has been written about the virtues of the lazy programmer, the one who never likes to write the same code twice. For the lazy programmer, coding anything once is fun because it’s a learning experience, but coding it twice is tedious. Not only that, but also it is dangerous because manual repetition means there are too many degrees of freedom for error. And not only that, but doing the same thing twice when you could have done it once is WASTE. One of the principal ways you improve throughput in any system is to eliminate waste (think for just a moment about your body).

The brilliance of the lazy programmer is that he can recognize when he has just done the same thing twice. Others don’t see they have done the same thing at all. In other words, the lazy programmer’s mind works at a higher level of abstraction. He can factor out the common code in the right dimensions and build abstractions so he never has to generate waste by writing that code again (and of course, this is fun because it’s a new kind of code). Then he sees the common factors in the successive versions of those abstractions, and after 10 years or so, can build something as beautifully well-factored as, say, JavaServer Faces.

I submit that the same ability for abstract thinking and automation are key requirements for Operations and QA, too. For an Ops guy to follow a standard procedure for system installations is mere competence (if the Ops organization has no such procedures, the Ops manager should be replaced–there is no excuse for such a lack of discipline). The truly great Ops people learn a system well enough to automate its installation and maintenance. They wield power tools with funky names like sed, perl, bash, and even InstallShield. They can run some command that will reinstall and reconfigure every server on the network in the event of a disaster and they know it works because they use the script for daily installs.

But, alas, like the lazy programmer, the lazy ops guy is rarely seen. In his place are (very) hard-working drones who manually repeat the same steps day after day, spend most of their time reacting to the perpetual crisis, and wonder why they live in a world of chaos.

If your Ops people are always busy, it might be a sign that they aren’t doing their job!

/dmc

How to Hire Good QA People for Web Applications

A veteran software manager recently gave me same valuable insights on finding highly productive and effective QA people.

These two questions reveal a great deal about someone’s mindset and approach to software testing:

1. How do you generate large amounts of test data?
2. What are the pitfalls of automated Web testing and how do you get around them?

Unfortunately, the people running many QA organizations don’t understand these things themselves and wonder why their automated testing efforts repeatedly fail. Those rare few who do and ’splain it to them are prone to get fired because it’s not safe to be smarter than the boss.Almost any programmer can tell you what you need to do to deep testing of a system: how to test each subsystem, how to generate meaningful test data that will really exercise the system, how to do positive and negative (no side effects) testing directly in the database vs. relying solely on what shows up on the screen, etc. In other words, the programmer knows more ways the system can (and can’t) fail because of their knowledge of how it works.

QA and Development should talk more often.

Abstraction leads to profits

I found an interesting quote in an interview with Microsoft great (and very rich man) Charles Simonyi. Speaking of his early days at Microsoft writing their first spreadsheet program, Multiplan, (which was subsequently wiped out by Lotus 1-2-3), he says:

We were competing very effectively against Visicalc using a strategy that is very much like Java today; it was a platform independent, interpretive, bytecoded system, that enabled us at one point to run on 100 different platforms, so we could fund the international organization and get acquainted with localization problems, and all those things.

Abstraction and the reusability it enables is a powerful support of profitability. Object-oriented programming was a step up in abstraction, followed by patterns, and in a related vein, components. What’s next?

According to Simonyi, Intentional Programming, which is yet another step up in abstraction that lets you specify the INTENT of algorithms and relationships in a language-independent, platform-independent way. It will be very, very interesting to see what happens next.

However, the failure of Multiplan may also provide a warning to purveyors of Intentional Programming. Simonyi continues:

Actually, Multiplan, our spreadsheet, remained very popular in Europe, for much longer than in the States. What happened in the States was that Lotus 1-2-3, wiped us out. So that was kind of difficult, but it was our fault. We were betting on the wrong horse — the mixed market with a variety of systems, instead of the right horse, which happened to be also ourselves, namely MS-DOS.

Microsoft, having learned its lesson early, seems to have never repeated the “mistake” of pursuing a multi-platform strategy. Perhaps the apparent conflict of interest between Intentional Programming and the Microsoft cash cow is why we haven’t see it yet. Can Sun beat Microsoft to the punch on this one?

/dmc

The Great Game of Software

Eric Sink’s latest amusing and instructive piece on running a software business….

The Game is Afoot

Why Hire the Best Programmers?

For the answer, says Joel Spolsky, consider the iPod.

Hitting the High Notes