[mattlondon]

I don't quite buy this romantic image of an engineer trying to fight for the people still using the device in 10 years time - I really doubt this was designed so that it could be used after the lithium battery completely died.

More likely it was designed so you could use some batteries that you can buy anywhere in the world when you are out and about traveling/vacationing and the battery is flat.

I work at a fairly major place you've all heard of with a reputation for software engineering excellence etc. One of the engineering managers said something to me the other day: "You know, we engineers here at <Big Co> write our software with this idea that it needs to be extensible and flexible enough to handle anything, like it's going to be around forever. In reality a project only lasts 3 or 4 years, maybe 5 before it is deprecated, replaced, or shutdown. Imagine how much more we'd get done if we were more pragmatic and not obsessed with future-proofing something we know will be replaced soon"? Food for thought.

[exfed]

Well, to be fair, that romantic image plays pretty strongly on a desire to see my work as something of a legacy--something that outlives my own mortality. I might be unique in that romantic desire, but somehow I doubt it.

Your engineering manager is on to something. I feel like that romantic desire, ironically, gets in the way of making real progress 99% of the time; even the code I'm really proud of, given enough time, will probably end up irrelevant, if only because I'll have learned so much more in all that time. It's easy to think of the act of writing as the hardest part of "writing code." But, really, it's all the learning in all the years prior that's most difficult. So, really, "throwing away" code and starting over isn't actually all that costly. Throwing away engineers, their experience, or skills is what gets expensive.

With that said, one of these days I'll start writing my "The Art of Computer Programming" ...