Fools and Their Tools

January 16, 2008 by Isaac

This blog post about The Incapability Immaturity Model hit way too close to home. A former professor of mine used to say that "a fool with a tool is still a fool."

I used to work for a company that at the beginning of a project they would spend months on documentation. A full 1/3 of the project schedule was spent in this phase. All the latest in tools and UML diagrams and use cases was employed. The project was thoroughly planned out before any coding commenced. Sounds great, right? Nope. Once all of the documentation and modeling were completed they were never referenced again. The project proceeded along by verbal instructions. The systems architects would verbally tell the developers what they wanted, which usually differed from what was documented. Little wonder that the various pieces of the system didn't integrate well and the project ran *way* over schedule and budget (we're talking millions here). Of course in the end the test team caught a lot of flack for not doing their job and not catching all the bugs earlier. Gee, we only had a verbally defined moving target of a system to work with. Oh, and a developer to tester ratio of 10:1 didn't help either.

In any case, this company was CMMI and ISO certified. They had the processes and documentation to prove it. The problem, as is pointed out in the above article, is that the organization was sick and didn't realize it. The company kept trying to impose process to help alleviate these problems, but inertia kept things from moving in the right direction. Traditionally, the senior project staff always just told the junior staff what to do. By spending 1/3 of the project doing documentation they stuck to the letter of the law, but then immediately discarded all that work in favor of tradition. What happened is that the more senior management tried to implement processes the tighter the lowly developers and testers were squeezed and actually threatened (not a joke).

Contrast that to my present employer. They are neither ISO nor CMMI certified, but the corporate culture is very amiable to change and cooperation. Instead of a dictatorship of senior engineers there is a mutual respect for each other. There is still a clear management chain, but junior and senior engineers all work side by side as opposed to chain of command. The end result is that the project is actually on schedule and instead of enmity between developers and testers there is cooperation.

So, a "fool with a tool is still a fool." Or, maybe I should say "a manager with a process is still a manager."