>> What bugs me no end is that some people don't want to learn. They're not
>> interested in understanding what the code does. They just want to get
>> something 'working' (for certain definitions of working) as fast as
>> possible.
>
> Time is money - hey it took me a third the time to produce this working 
> code then you did yours. Oh sure your code scales up whereas mine conks 
> out with large input, and sure your code is robust whereas mine fails if 
> someone sneezes at it in the wrong direction; but mine works *now* with 
> what we're using *now* and it took less time to write then yours - neh neh 
> neh neh. ;-)

IME it seems that most software that is written in-house is in response to 
demands from other people, so there is often huge time pressures on getting 
results.

For instance, application A may be developed all very nicely and in time to 
do exactly what is needed.  It's tested and everything is well, so it is 
used regularly.  Then one day, employee X comes along and says "hey software 
dude, my customer needs result X from the software tomorrow, can you modify 
it to give me that info please.".  So then software dude modifies the code 
in a very hackish way just so that employee X can give some result to his 
customer the next day.

The problem is, that then software dude doesn't go back and make everything 
nice and test it (he has other stuff to do), the software just gets left in 
this "bad" state.  Repeat the situation above a few times and you end up 
with a big mess.

We have an application here that followed that exact life cycle, you could 
see very easily the central well-designed part that someone took a lot of 
time over, but the problem was that only accounted for about 10% of the 
code.  The rest was just ugly hacked on feature after feature.

Post a reply to this message