[gameprogrammer] Re: "Mission Efficiency" - Blue Collar coding

Whoops - first, my apologies, the previous email was sent by accident,
before it was finished. Hope i didn't say anything too incriminating ;)

At 02:12 PM 06-05-04 +0800, you wrote:
>On Thu, May 06, 2004 at 01:47:18AM -0400, grant hallman wrote:
>> Nothing's "wrong" with it, per se. Nothing's wrong with a cordless
>> screwdriver either, but if that's the only tool u could have for every job,
>> u might come to resent it.
>
>This is true. But I have to say the number of real coding tasks that should
>_not_ be OO is very low. Very very low. Possibly approaching zero :P

You're entitled to your opinion. Mine is the exact reciprocal.

>> >    I have been taught that OO allows for generality, and less coding,
>> 
>> Well, less than what? I was told OO would allow software tools to be
>> arranged in a heirarchical library, and used for many different apps.
>> Except i'd been doing that for 20 years before meeting OO. I haven't seen
>> every possible example, but most OO code i see has the A-level code chopped
>> into so many small pieces, and each piece embedded between layers of
>> C-level stuff, that understanding it is like trying to rebuild a cow from
>> so many hamburgers. And everything wants constructors, destructors, and
>> other distractions which may be logically required by the language, but
>> certainly not by the application. 
>
>Bad code is bad code is bad code. OOP does not magically remove bad code, but
>it does encourage modular design which at least means the bad code has a
chance
>of being localised.

Yeah, it "encourages" modular design, in the same sense a 400-lb Sumo
wrestler with a pitchfork, standing in the OR, "encourages" a brain surgeon
to not make any mistakes. IOW, by heavy-handed forcing of a particular
style, it interferes with actual good programming. 
 
>Yes, you can code in components without OO.
>Yes, you can partition things into nice bite-size chunks without OO.
>
>But I contend that an average group of programmers have less chance of 
>putting out a crap system using OO design and techniques than an average
>group of programmers using non OO design. This is where software engineering
>is headed - towards the ability to put out useful solutions without requiring
>all workers coming from the top 5%.

There's a short answer and a long answer to that point. First the short
answer:

Windows. Look at any Windows app. 

Then the long answer: No language, no design technique, can make a good
programmer out of an average programmer. The promise of OO was always that
it would make good programmers out of average ones, just exactly as you
describe above. It just hasn't happened, and the industry has noticed.
Development costs have skyrocketed, as writing even the smallest program
got laden with all the baggage OO brings to "Hello World", or "Get the next
keystroke", or any other dam' trivial task that used to take 10 lines and
be done with it. 

What we've got now is an average group of programmers producing OO crap,
instead of pre-OO crap. But it's still crap. It's just far more expensive
to write, and debug.

>As for destructors etc. If they don't need to do anything, leave them blank.
>It's really quite simple.

Even simpler: leave them out ;-)

>> The cost of OO compared to, say, structured programming? First off, the
>> boundaries are fuzzy, because on the street, comparing OO with !OO is
>> typically to also compare C++ with C, and Windows with !Windows. But it's a
>> perfectly reasonable qn, so i'll try. But i'm really comparing OO and C++,
>> and to an extent Windows, with some alternative language and o/s.
>> 
>> One of the costs is that OO introduces a whole new category of errors,
>> having to do with scope, range, inheritability etc., which, taken one at a
>> time in a comp sci course, may make sense, but which, when dumped on the
>> street with a real "blue collar" programming job, become just so many more
>> ways to f*** up. 
>
>The 'more rope' theory, which applies nicely to c++, not so nicely to
languages
>like C# (which is, if you were wondering, quite, quite OO).

Look, we went thru the same thing when "structured programming" (SP) was
the new state religion. Around 1980, i hired a guy i'd gone to school with
- call him "Fred". He'd spent 10 years teaching computer science at U of
Waterloo, while i'd been working at HP and then on my own. I'd already
switched to the SP model, because it actually made my code better, but i
saw it as a tool, not a religion. 

So our first job together was a graphics app for the forestry industry. I
and "Betty" were coding the HI - keyboard, (text) screens, and honkin' big
"digitizer" - basically a mouse with a crosshairs, on a 3x4' platen. Fred's
job was to take the vector lists we produced and put them onto the honkin'
big plotter. He was all gung-ho, said we'd get the "best SP code ever
written". Like the naive CEO i was at the time, i left him to it. He took
the entire 6 weeks we had, handed me a tape and stack of listings at the
last minute, and swore it was ready.

So here's delivery day, me and Betty on the plane out to Alberta, and i'm
getting my first good look at his code. It's... well, a shock. It's got
100's of "Structured" modules like:

C  update pointer   (yeah, Fortran)
   subroutine B(I)
   int I
   I = I + 1
   return
   end

Completely SP, completely modular, completely unreadable. I thought, oh,
sh*t! We're doomed! He took 6 weeks to write this and it's useless, and
delivery's tomorrow! 

Well, adrenaline has a funny effect. Betty and i had dinner in the hotel
that night, and i showed her the problem, and said, Look, you start
training the customer, tell them i'm busy "installing" the software. Then i
donned my Blue Collar and got to work. How long did it take me to reproduce
the rigorously-SP masterpiece produced in 6 weeks by a guy who'd been
teaching programmers for the last 10 years? 

Three days. 

Well, not exactly "reproduced"; unlike Fred's, my code actually made the
plotter move, too. His "masterpiece" was a total writeoff. But my customer
never felt a thing... training took 3 days :)

There are a lot of lessons to be learned from stories like this, but i'm
just making two points here. One, programming style is not, and should not
be, a religion. It is not the job of a language, or a design method, or an
operating system, to "encourage" a programmer to do any dam' thing at all.
That is a grotesque reversal of roles. The language, method and o/s are
tools, nothing more. Good tools don't "encourage", they empower. They do
what they're told, and they're as easy as possible to learn, and as soon as
they're learned, they get out of the workman's way and become as invisibly
a part of him as his hands and eyes. I have the same reaction to OO
"encouraging" me to make lots of little modules, as i'd have to a socket
wrench "encouraging" me to make lots of little turns where one big sweep
does the job, or vice versa. IOW, i know what the job needs, the tools
don't. Or if i don't know, i should get out of the kitchen.

And my second point is, nothing, period, can make an excellent programmer
out of an average programmer. The very best we can get is the coding
equivalent of training wheels on a bicycle. And what that does, is reduce
everyone to the average. Industry experience with development costs shows
this is exactly what OO has bought us. Steeper learning curves, narrower
specialities, and slower, buggier, costlier coding. "Training wheels"
pretty well expresses how i feel about a dev env that forces me to use OO,
or any other dang thing, whether i want to or not. It's just too intrusive.

There, i finished this one before sending (doh!) - fire at will!

cheers - grant

Other related posts: