[gregmac]

How does this relate to maintenance?

Whether code is practical or not is not a black and white issue, and a solution that "works" today - meets all specs, generally bug-free - doesn't mean it's maintainable. In fact, most of the code I've dealt with from people who basically only value the metric of "does it work?" completely fails at being maintainable.

What I mean by this is as soon as you start trying to add/change features, you quicky run into bad design and have rewrite huge chunks to get the new stuff to fit, end up playing whack-a-mole with endless bugs, or both. Sometimes you can hack on a fix with duct tape, but that only delays an even bigger rewrite or more bugs later.

I've run into this with mostly "job shop" places, both in North America and offshore, so perhaps the problem is the nature of that business more than the culture, but the mentality seems to align with your description of practicality.

[startupdiscuss]

There is also another issue with “just works” and meeting specs: specs are almost universally under constrained.

I might describe an admin interface in terms of what it controls but implicitly I want large choice sets to have search functionality and dates to have calendars and so on.

A large choice set implemented as a massive drop down technically works but I don’t have to explain why it’s just wrong. The “practical” programmer may say hey it works and let’s move on. The “clever” programmer wants to impress with a new widget that is intuitive to use. In this particular case (interface design) I’d prefer the clever coder over the practical one.

[waholleyiv]

What you're describing is about end-user empathy than being "practical" or "clever".