Unfortunately many of the longterm safe/quality practices don't always matter to those initially in charge of a project, and so you'll find a group that develops and then goes on to do something else that's never been done before--without thought to how they might've made it last forever and ever.

The mindset is often that there will always be something newer and better, and why maintain something when you can always rewrite what doesn't work later?

In some ways it's a matter of "We'll cross that bridge when we come to it." Also designers often take an anything goes attitude because they tend to get paid a lot, while code maintainers (the IT grunts) get paid a lot less to keep it working. I would expect that some developers probably have nary a thought of them or their feelings, they're paid to prove concepts.

When i worked with coders in the game industry, one of the most difficult motivational tasks for me as a project manager was getting the expert coders to do the boring coding... the stuff like tweaking the AI, fixing typos, and organizing code in a production release. All that takes a lot of discipline that was not appealing to the hot-blooded trailblazers of the coding universe.

It isn't always so, however. I know some folks who are proud their code is still being used after a decade. Though they're often the first to claim it's not good code.

finally there's an aspect of budgeting for maintainability that's hard for a lot of folks to swallow. It's the idea that if it's an expense in the future, that it's an expense at all. If I'm a manager and have a forty million dollar budget, thirty of which is for maintaining the project over the lifetime of the project, what are the chances I won't be tempted to spend that now? Or that my upper management won't cut that eventually anyway, because it's a huge expense that's just hanging out there unspent... future expenses are liabilities that make accountants nervous. Heck, accountants don't like it when you save up too much vacation time...

Of course those are external factors to what really should be self evident. I do wonder what some would consider "maintainable Perl" because I've heard a lot of folks claim that Perl isn't maintainable (mostly because they don't know it... which maybe is part of the problem with Perl... you have to hire a Perl expert in order to maintain it... and that's another expense that may not be worth the effort economically speaking, when Java coders are a dime a dozen in some country where wages are even less than that...)

--Ray