Are most programmers male?

[brueckd at tbye.com]

On Tue, 13 Aug 2002, Dilton McGowan II wrote:

> > Yup. The code itself is worth _something_, but the real asset is the
> > knowledge that was used/acquired when creating the code, and that
> > knowledge is terribly hard to extract from the hermit. This is the same
> > reason why code is easier to write than it is to read, and why programmers
> > (myself included) are always tempted to throw old code away and write a
> > better version instead of endlessly tweaking the old stuff.
> 
> I agree that it should not be as tempting to re-write old code. Does that
> mean that our languages are not expressive enough? Perhaps that's why I've
> recently started looking again, after Java. One thing's for sure, I keep
> going back to C++. I do like what I've seen of Python and am encouraged. I
> think there's no good language, only a good mixture.

Hmm... actually, I didn't say that it should not be as tempting to rewrite
old code, and sorry if I made it sound that way. Frankly, I'm less and
less convinced that it is the Bad Thing that many in management make it
out to be.

Assuming you have a good set of tests (including tests for bugs found so
far during the lifetime of the code), then complete or partial rewrites
can have some major advantages. Often you don't know what you really need
until you've built a first version, and the process of building "one" of
something gives you the knowledge to build a better one next time. 

Python encourages rapid initial development, but it also drastically
lowers the cost of _redevelopment_, and (outside of places like NASA where
they can afford to be extremely precise on requirements) there is a real
need of ongoing redevelopment - the tendency is for programs to evolve
significantly over their lifetime.

Python makes me less fearful of ripping out and replacing "bad" code
(usually in conjunction with adding new functionality), and as I result
I've found that my Python programs tend to mature towards really good and
really stable much quicker than their C++/Java counterparts - maybe for no
other reason than in C++ or Java the cost of change is higher so we tend
to wait as long as possible (i.e. we wait until the need has shifted very
far away from the original implementation AND we have a large stack of new
functionality to add).

-Dave