Chris said:
(e-mail address removed) wrote:
I largely agree. There have been times when I've cranked out code that fast or
faster (I'm pretty quick when I'm on a roll), but normally I'd say that if you
are in that position then there's a good chance that you are missing a chance
to abstract and/or automate.
There's another case, though its a bit rare. Some time back I was
working on a large online system where we had a number of modules that
pulled data out of the database and displayed it to answer queries. We
had a standard query response skeleton that just needed filling with
appropriate DB access statements and display formatting statements: the
rest of the system was menu-driven and had already collected the data
retrieval keys. This was entirely COBOL code using an IDMSX database in
case you're wondering.
Completed result display modules ran to about 300 lines of code not
counting the stuff that the IDMSX preprocessor injected. It was
generally possible to write, test and debug one of these in a day
without working overtime.
=======================
Another factoid that's always fascinated me is that, while programmers
vary widely in the number of lines of clean compiled and unit tested
code they can write a day, the number of lines any individual can
produce a day is almost independent of the programming language used.
IOW, most of the productivity gain going from assembler -> high level
language -> task specific languages (e.g., a 4GL, PowerBuilder, Perl,
awk, ...) is simply due to the fact that you can program a specific task
in fewer source lines.
This was discovered by the Lyons Organization, a British mid-20th
century Starbucks equivalent, who developed and used the worlds first
purpose designed business computer, the LEO series, in the early '50s.