[ploxiln]

So, there's no such thing as good quality code that saves time in the long run? So we should just give up and hire some cheap overseas contractors because the result will be the same?

To anyone except an MBA running a software project for the first or second time, that's pretty obviously not true. (Some people, when they realize this, do "additional process will be mandated until quality improves".)

[silverbax88]

I'm not clear what your last sentence means at all. You write the best code you can at the time, but a dogmatic approach - even the one that you think will save so much time in the long run, will likely be completely useless within a few years. It sucks, but that's what happens. This has a positive spin, too - you will be much less likely to adopt flavor-of-the-month programming tactics until you really vet them, unless it's incredibly obvious as an improvement.

This is usually one of the fastest ways in an interview to tell how experienced someone is. Younger, less experienced programmers are dogmatic, but their view is extremely limited - they believe defiantly in the current coding practices, but haven't yet learned that their dogma is just the latest, and will be replaced in short order.

Hey, I was once one of those dogmatic kids, too.

[Falkon1313]

Not to speak for someone else, but the last sentence was clearly a reference to "The beatings will continue, until morale improves."

You're right though. And it's a balance between technical debt incurred having not enough time (hacky shortcuts) vs technical debt incurred from having full freedom (overengineering of unnecessary layered abstractions and indirection).

It's a tightrope and we're always going to stumble somehow. In retrospect, we tend to focus on the stumbles (wouldn't do that now!) rather than the fact that we actually got across the canyon and delivered business value. A natural bias - we discount the fact that we're making new mistakes even as we look back and criticize our past mistakes.