Code Reduction == Good Idea?

Question

I just went philosophical again and wondered:
In the producing industry, there is something like a user-based value analysis of features. Features that aren't used will be removed, as every feature costs money, and more costs are less earnings. Near-hypothetical example:
A car usually has at least one ashtray. Market research found out that most people don't smoke in their cars, though, or even if so, rather use the window than the ashtray. So the controlling guy sez: hey, we spend $5 to equip every car with an ashtray and cigarette lighter that isn't used by anyone. Let's get rid of that thing by default (and charge anyone who'd like to have it an additional $50), because then we're not forced to rely on the ashtray manufacturer anymore, don't need to coordinate supply shipments, don't need to waste workhours on ashtray installation and don't need to pay for it.
After all, 100,000 cars *$5 = $500,000.
How about applying the same principle application code? An application has so many features, but some are just never used. It's code that has to be maintained, and that's usually kept because developers are hesitant to throw old work away. They'd rather add more features than remove old ones - maybe it might be useful later. So there's a chance of ending up with an attic full of old code that nobody really cares about. This code makes it more difficult to maintain the software - understanding a small complext program is easier than understanding a large complex program - and is therefore also a cost factor.
Is there any consideration given to "lean code"?
[I don't want to argue my point here, it is basically just a question like: "why isn't it done?" or "why doesn't it make sense to do this"?]

Answer 1

lol Sure. But you know, there's the difference
between what developers think must be done and what
they actually do. Like "we should have coding
guidelines" or "we should do documentation" or "we
should use a CM process".This is true for everyone, not just programmers.
Call me Rene, btw. :)Excellent, Rene. I'll try to remember.
I agree that redundancy is bad. But I'm not talking
about duplicate code here. Think about some GUI -
there are maybe two or three buttons that basically
aren't needed. These buttons have each a few lines of
initalizer code, maybe some properties, each maybe an
anonymous ActionListener (worst case), maybe
multi-threading code for their functions and the code
for the functionality they stand for. So you might
really end up with lots of messy code you could do
without. Given a reasonably good regression test
suite, you might begin removing it completely...Right - I see your point. You're saying that it could be 100% non-repeated code and STILL be chock full of features that no one uses or are used rarely.
Maybe it's the same thought that goes with the
Test-First approach, write tests for the specs, then
implement. Do not implement what's not in the specs...
I should talk to one of my former professors when I
get the chance.... maybe there's place for a little
research in this area.I think it speaks to how these features are driven in the first place. Where do they come from? Marketing surveys of actual users? Developers' imaginations? Help desk complaint tallys? "Wish lists" of some kind? How are they prioritized and ranked?
Unfortunately for me, I've never seen s'ware done in anything other than an ad hoc way. There are rarely design docs or formalize procedures. I've never worked on commercial s'ware, so I can't say how M$ or others do it.