> I've met programmers who 'design' like that as well -- they
> type in some code, then fiddle with loop limits, ands versus ors,
> etc until the program gives the 'right answers' on the test values. Is it
> any wonder some programs contain bugs..
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_at_hotoffice.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.classiccmp.org/pipermail/cctalk/attachments/20000619/79b40d90/attachment.html
Received on Mon Jun 19 2000 - 17:35:39 BST