A favorite fairy tale of many is The Emperor's New Clothes. This story plays out every day in one way or another. Two projects come to mind that illustrates how sometimes it's better to have simple clothes than no clothes at all.

A few years ago, I worked with a Fortune 100 company that put a lot of time and energy into "Quality." This organization had developed a set of "quality tools" that they taught the employees to use. Every employee was required to identify a task from their daily work and, using the Quality Tools, document a process to improve the performance of that task. Even the receptionist at the front desk displayed a certificate on her bulletin board stating that she had found a task and improved its "quality."

This organization had the trappings of a quality software development process, including formal code reviews, a change control board, unit tests, user acceptance tests, and beta tests. Bulletin boards proudly displayed the status of each project. Managers signed off on the Requirements Document, the Design Document, the Test Plan, and the Release Document. With this structure and emphasis on quality, one would expect this organization to produce great software.

Surprise! This emperor had no clothes! The user interface was difficult to use. Users had to take a class and a test to be certified to use specific screens before accessing them. The code itself was even worse. The system, built on undocumented spaghetti code, had an extensive list of outstanding bugs. In one part of the source code, I found a line that essentially said: "If you are using a test account, then make sure that the system works correctly."

Now, contrast this with another Fortune 100 company that lets each development team determine the best process to develop software. We had a two-person team and six weeks to build a system that would enable a factory floor robot controller to communicate with a desktop computer for this project. Communication systems are often troublesome due to their inherent complexity.

We spent the first week analyzing the architecture, documenting some design, and prototyping some modules. We then began using Test Driven Development (TDD) to build the system. With TDD, the developer writes automated unit tests before writing any implementation code. We wrote a few unit tests, implemented the code for these tests, and then moved on to the next set of unit tests. We maintained peace of mind (flow) because we continuously made small design and implementation decisions rather than trying to keep the whole system in our heads at once. Upon completing each new piece of functionality, we made sure that all of the unit tests ran without error.

Surprise! This emperor wore simple, elegant clothes! In just five weeks, we built a complex 4500-line C++ system that integrated with three third-party products. When we took the system to test with the robot, it performed flawlessly. The next time I saw the person I worked with on that project, he told me the system had been in production on the factory floor for over a year, and he had never changed one line of code.

Note that the second project had no management interaction and very little documentation. Yet, the results were significantly better than those on the first project. So, the next time you see a lot of pomp and circumstance around a project in your world, take a closer look to see if there are any clothes. You may be frightened by what you see.