Little Things Mean a Lot

By Peter Coffee  |  Posted 2005-10-10 Print this article Print

Opinion: Finding and fixing fatal flaws may accomplish more than seeking breakthroughs.

Last year, the best brains in robotics couldnt build a vehicle that traveled more than seven miles without human input. This year, five vehicles finished a 137-mile test course in the Defense Advanced Research Projects Agencys second Grand Challenge competition, and they could probably have kept on going much farther. Does anyone really think that the state of the sensor, actuator and software arts improved in that time by a factor of almost 20? Or is it more likely that incremental improvements crossed key thresholds of adequacy to the task?

Theres got to be a message in this result for project teams charged with identifying, adopting, refining, implementing and deploying strategic technology. The vehicles that finished the DARPA course this year werent 20x faster or 20x more powerful or 20x more thoroughly instrumented than the ones that did so poorly last year. Rather, this years entries didnt make the same kinds of stupid mistakes, or have the same kinds of fatal weaknesses, that kept last years entries from doing as well as their overall high levels of engineering and construction should have allowed.

When an enterprise application fails, it can be just as embarrassing as when a robot vehicle hits a wall--or even locks its own brakes--before leaving the immediate vicinity of the starting line. Most of a failed applications carefully written components, like most of the parts of an ignominiously failing robot, were probably working just fine--but an obscure security loophole, or a failure to allow for needed scaling of workload to larger data sets or transaction rates, can bring down the whole thing as badly as if it were a botched job from end to end. When a product fails in testing at eWEEK Labs--for reasons that were often now illuminating on our blog-enriched "Inside eWEEK Labs" site at common for our reaction to be, "Why would people with so much talent neglect a problem so obvious, so vital and so easy to fix?"

At this point, I thought it might be useful to introduce the Japanese term "kaizen," commonly and casually translated into English as meaning "continuous improvement": Many management commentators use this label when theyre encouraging an approach of finding and fixing small problems on short cycles, rather than seeking sweeping changes that introduce fundamentally new problems of their own. While researching kaizen, though, I ran across another doctrine called "Five S" (not to be confused with "Six Sigma") that sounds as if it applies to manufacturing workplaces, but that I think has something to say to application developers as well.

The Five S philosophy of removing the unrelated, arranging the useful, discarding the distracting or dangerous, standardizing the proper practice, and systematizing the overall process has much to offer in application development efforts. When bad code or flawed concepts are excised, rather than being encysted in workarounds; when application functions are introduced because users want them and will use them, not because they seemed to the developers like good ideas; when developers can readily get access to data, to code libraries, to testing tools and to other key resources instead of inventing their own stopgap solutions to these and other needs, then its likely that project success rates will dramatically rise.

Tell me about the walls that youve seen hit, and about the systems that youve devised to focus your efforts on what most needs to be fixed, at

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel