No, I have a practical, day-to-day experience that may differ from
your own.
> I've talked to a number of folks who have a spent a lot of time working
> in such environments, and they've all told me that there's a lot of
> unbelievable crap out there, in software which you may be using every
> day. The issue is that in the "rush to market", there's often not time
> to do full debugging and coding and internal documentational.
I agree, some companies do it that way. That doesn't make it sound
development strategy. When I last went looking in the job market,
all the companies in my area were ISO900* compliant (a government
town makes this a requirement - heck, a few fly an ISO900* banner
outside their offices). The first question they ask is, "What are
your [code] documentation skills?" Any idiot can write code, and I've
had to deal with the code of a lot of idiots.
Again, my experience differs from yours. I can't understand why some
people don't realize this, and accept it like I do.
> This is why being able to read poorly documented code is a very
> important real world skill....
Agreed. I've had to reverse-engineer stuff (I actually got to enjoy
doing that <shudder>). This wasted huge amounts of time and effort
that would have been better spent on new development. A lot of the
companies in my area realize this.
If we have different opinions, so be it <shrug>.
P.S. If you want to make a living a reverse-engineering programs of
several MLOCs (million lines of code), written in disgusting
languages like COBOL, FORTRAN, and even SmallTalk, there are
hundreds of openings in my area alone. It's all grunt work -
documenting code that can no longer be maintained.
[Sound familiar?]
-- Andrew E. Mileski mailto:aem@netcom.ca