Programming on Paper

When I first started in programming (1977), we had to create *complete* technical design documents before a single line of code was written. This included technical specs, data diagrams, flowcharts, screen shots, etc... About 6 weeks ago, I was evaluating a fairly complex software project and and asked the engineer to provide a flowchart of how the application worked. He stated that he didn't see the value of a flowchart and that it would slow down the development process. In his opinion, it was much easier to just read the code. I was tempted to kick his ass, but decided the best way to handle this was to prove the value of proper documentation. So, I waded through his code, found the most complex module, and created a comprehensive flowchart of just that module. Now the fun part... I got the engineer, his supervisor, our VP of technology, and another non-technical co-worker (whom had never seen the project) together for a quick quiz. I gave the flowchart to the non-technical person and started asking the group fundimental questions like; "how many parameters are passed to and from the module", "what happens if an out-of-bounds value is passed", "what is the exact sequence of events when..." blah, blah, blah. Almost instantly, the non-technical person was able to answer the questions while the two engineers waded through hundreds of lines of code. Within 30 minutes, I was able to totally embarrass the engineer *and* his supervisor in front of the VP. Shoulda kicked his ass anyway... ;-) Steve Robertson <steverob(a)hotoffice.com>