Programming metaphors (Was: Programming as literature.)

[Jarno J Virtanen]

22 Apr 2002 06:29:05 GMT Lumberjack wrote:
> Tim Daneliuk <tundra at tundraware.com> wrote:
>> Carl Banks wrote:
>>> Computer programming is not science.
>> 
>> Agreed - it is craft.
> 
> Computer programming has all the properties of literature, including 
> subjective analysis, the existence of "schools of thought," and genres, 
> among other things.

This has been a significant metaphor in the past. It's just that it 
doesn't cover software development fully or adequately. For instance,
literature is often a one (wo)man activity whereas software development
involves several contributors (sometimes even several hundred or more).
Furthermore, writing a piece is an activity that has a clearly 
identified end point. It doesn't even matter whether there's few 
typos in the final product. Software development is more of a 
maintenance activity where bugs and shortcomings are fixed throughout
the lifetime of a product. (Taken to the extreme, literally, it is
actually only about fixing bugs and shortcomings (ie. adding features)
which starts as soon as the initial release is made which is made
very early in case of extreme programming.)

I find every other metaphor lacking something essential too.  One
popular metaphor is building construction or engineering activity in
general.  Personally I just don't get the feeling that there's any of
those so called components that the final product is made of in computer
programming.  These components are supposed to be realiable (and in a
way simple) yet provide something significant to the product.  I can't
figure any non-trivial and substantial programming component which can
be viewed having the same reliability (or reliability properties, such
as "this bolt holds the pressure of N") as the compontents that
buildings are made of. 

When I think of the final products of software development and building
construction I find it hard to compare them.  Yeah, sure there is some
sort of an "architecture" that they're based on and they're both
non-trivial combinations of some sort of building blocks.  But it's just
that the software product seems so fragile.  There are of course methods
and ways to build high quality software, but no matter how protectively
it is built, there's always the chance that some part of the software
fails which makes the service provided by the software unusable. Even
in the case of formal methods there is a possibility of failure. Now,
whether it's just that software development is such a young discipline
or that there's some inherent factor that makes it uncertain and 
undeterministic is beoynd my comprehension. 

Having said all that I'll just have to remind that metaphors are of
course useful if they shed light on some aspect on the subject.  They
just shouldn't be extended too far.  (Hmh, It seems that I've been
stating the obvious all the time, well, that's just me ;-)