[ninjac0der]

... and as expected, it's always the manager, not coding types that state this so aggressively. I know the servers are beefy at OmniTI, so I suspect there might be a code problem related to handling the load.

If I see sloppy code, or have to write sloppy code, I move to another company, and will continue to do so. So how's that employee turnover rate (hint, use the internet archive and check the about us page)?

[varjag]

I am a coder type, and I mostly support the sentiment.

Over the years, I gradually drifted from doing things the Right Way to doing things that are good enough. Doing things elegantly in practice unfortunately adds zero flexibility for non-trivial changes in business direction: you simply can't foresee everything. One swift decision at mid-management level and your elegant framework suddenly becomes an unwieldy Titanic impossible to put into a quick turn.

Now arguably works-for-today kind of solutions are not inherently any more flexible. However, they don't take nearly as much investment in the first place.

(Should also point out that quick and simple is not equal "sloppy code": I check my return values and handle errors just fine, it's just that my code makes no attempt at establishing world peace).

[dsrguru]

> Doing things elegantly in practice unfortunately adds zero flexibility for non-trivial changes in business direction: you simply can't foresee everything. One swift decision at mid-management level and your elegant framework suddenly becomes an unwieldy Titanic impossible to put into a quick turn.

Yes and no. If you're writing very elegant statically typed functional code like in Haskell or ML, you're going to have to be elegant at the design level, and yes, you might have trouble adapting to new requirements. But if you're in a domain where requirements aren't always set in stone, you're probably using a more dynamic environment where you don't have to be what the OP called "elegant" at the design level (e.g. his unrealistic caching layer example), but you can still write elegant code at the micro level (within functions, classes, etc.), which will almost certainly lead to substantially less technical debt and shouldn't cost much if any more time than quick hacks at the micro level.

[ninjac0der]

So the key is making the right call for the situation, which brings me back to the point, managers are not the ones maintaining the code.