POV-Ray : Newsgroups : povray.off-topic : Curious perversions of IT : Re: Curious perversions of IT Server Time
29 Jul 2024 14:19:26 EDT (-0400)
  Re: Curious perversions of IT  
From: Invisible
Date: 18 Aug 2011 11:34:16
Message: <4e4d30f8$1@news.povray.org>
> So if it doesn't happen in structural engineering, why the hell does it
> constantly happen in software engineering?

Let's take a look at the common themes of TDWTF:

1. People who think they are "experts", when they are not.

2. People who convince others that they are "experts", when they are not.

3. People with unrealistic expectations about software development.

The more I think of it, the more it seems that almost everything that is 
wrong with defective software development stems from these three 
fundamentals.

There are plenty of stories about awful code written by "the previous 
employee". This is usually due to the previous employee simply being an 
extremely bad programmer. Sometimes the person doesn't realise how bad 
they are; they honestly think they're the best. And sometimes they know 
damned well that they're terrible, they're just very good at convincing 
everybody else that they're brilliant.

There are also lots of stories about perfectly competent programmers 
forced to write absurd code because of decrees by management, the lead 
programmer, or some other figure. Again, this person thinks they know it 
all, and they don't.

Finally, there are the stories about code written under ludicrous 
circumstances. Like, you tell your boss a certain feature will take 6 
months to develop, and they demand that the code be finished by tomorrow 
evening. Or you tell the customer the project will cost X million, and 
they demand that you do it for a hundredth of the cost. Or sales promise 
that XYZ can be done in a week, when really it should take years to write.

And then there are those poor unfortunate souls who have to maintain 
code so ancient it should have been thrown away decades ago. If you take 
/any/ body of code and try to modify it too far beyond its original 
design goals, the result is bound to end up being a monstrosity, no 
matter how good you are. Usually you can attribute this to management's 
refusal to allow a rewrite. In other words, management think they know 
more about software than you do.

So all of these problems basically come down to the three points above.



Now, as far as I can tell, points 1 and 2 *definitely* occur in all 
sorts of industries. I don't think 3 happens so much. (E.g., if somebody 
tells you it will take 5 years to build a large bridge, you don't order 
them to have it done by Tuesday.)

So why does IT abound with defective products, whereas other industries 
don't?

I mean, sure, there are defective electronics on the market. But when 
was the last time you bought a microwave oven, got it home and found out 
that it doesn't actually contain a microwave generator, it just uses a 
fan to waft the warm air from the transformer in the general direction 
of your food? This *never* happens! And yet TDWTF regularly catalogues 
the woes of people using million-dollar software written in QBASIC or 
whatever.

After meditating on this, I've come up with a couple of reasons.

1. If your microwave oven is defective, you damned well take it back and 
demand a refund. If your software is defective, you have to click on a 
box that said "THIS SOFTWARE IS PROVIDED AS-IS AND COMES WITH ABSOLUTELY 
NO WARRANTY EXPRESSED OR IMPLIED."

2. It costs money to manufacture a microwave oven. You need specialist 
equipment and expensive materials and so on. On the other hand /anybody/ 
can write computer software and attempt to sell it.

3. A bridge built by a moron with no knowledge of structural engineering 
looks /nothing like/ a bridge built by professionals. (For one thing, 
it's probably snapped in half already.) Software written by a complete 
moron can sometimes superficially appear just as professional as 
software written by experts.

4. If you build a house and it collapses, you can pretty much guarantee 
that it was your fault. If you write some software and it doesn't work, 
you can complain "It's a conflict with your AV software. You're version 
of Windows is too old. It's a known issue; the next paid-for upgrade 
fixes it. You're using the software wrong. That's an optional extra 
which you haven't purchased..."

Anybody else have any suggestions?

Better yet, how do we /fix/ this nonsense?


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.