Are most programmers male?

brueckd at brueckd at
Tue Aug 13 11:23:21 EDT 2002

On Tue, 13 Aug 2002, Peter Hansen wrote:

> > 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.
> I've found that when code is developed test-first, it is rarely tempting 
> to rewrite old code.  In fact, I consider code developed test-first to be
> a _real_ asset, rather than just some lines of text someone wrote that is
> cluttering up random folders on his hard drive after he left.  Other 
> code does not seem to have so much intrinsic worth.

Hmm... that's interesting. In most of the cases I've seen, whether or not
the code was developed test-first has had *nothing* to do with the
temptation to rewrite it (the few exceptions were when in addition to no
tests the code was just plain horrible, in which case there tended to be
deeper problems).

Instead the drive comes mostly from the evolution and clarification of
business needs - additional features are needed or the need can be better 
described with each new version of the program.

In terms of new features, you always need to strike the right balance
between developing only what you know you need (JIT development) and
anticipating future needs, but in C++ or Java the cost of change after the
first implementation was higher so I would tend to lean way more towards
anticipating future needs (making the code more general, making more
elaborate and generic class hierarchies, stubbing in future services,

Unfortunately this tends to weaken the design and bloat the
implementation, and more often than not my bets on what we'll need down
the road end up being wrong. To the degree that a language safely lowers
the cost of change, you can lean more towards JIT development - build well
what you know you need now and as your needs change then tossing and
rewriting becomes less crazy of an option. Besides, any time you build
something you gain knowledge that will enable you to build a better one
next time.

The other motivation I mentioned above is clarification of requirements.  
For most programs it's unfeasible to precisely define requirements up
front - it's too expensive, too ambiguous, there's too many details, or
there are simply too many unknowns. The statistics on large software
projects that never make it to completion, or even out of the requirements
stage, are appalling (insert zany autocoding plug here ;-) ), so an
alternate approach is to cheaply (low-cost, not low-quality) build
according to your best educated guess and use that first version as a
starting point for the next round of requirements. Most customers can't
precisely tell you what they need, but if you give them something to play
with they have little difficulty telling you what's right and what's 
wrong (even better, you often avoid them quibbling over details they don't 
know enough about to wisely decide on).

Traditionally this means build a prototype, which from a developer's point
of view is the purest form of evil (the marketing guys want to doctor it
up with fake features, the customer loves all the fake features, and the
developers must then scramble to implement what the customer thinks is
already there despite what you told them). 

The reason for the prototype is that it is (was) too expensive to build a
quality application that might be the wrong thing. I have found that
languages like Python are a step in the right direction away from that
model - with practice you can actually build high-quality functionality
much cheaper than we're used to. What does this mean? Well, gathering
requirements in relation to a working implementation of something has
always been more accurate than gathering requirements from scratch, it's
just that up until now that better approach has been too expensive. Now 
it's becoming viable.


More information about the Python-list mailing list