Using your argument: Mcdonalds, Starbucks, Walmart, Coke and many other companies are O(N^2) solutions and therefore failures. They repackaged an existing idea, made slight modifications, and sold it for lots of money.

I hate seeing wasted money and stupid solutions succeed like the next guy and maybe we're talking about different things. But whether things got done should be decided by the customer not your TDD fanatic coworker.

I tentatively agree because these things can be showstoppers, but it really depends. I've seen PhDs who can't tie their shoes. Theoretical knowledge is useless in production software if you don't know how to apply it, and yet without it you will be greatly limited in the scope of systems you can build.

Of course an elegant solution is desirable, however I prefer bloatware that works, over a beautifully architected one that is vaporware.

I used to believe that too, but I've changed my mind.

Now, I'll always prefer clean organized code, even if it doesn't work. I can always hire someone or jump in myself and make the changes that are necessary.

It is safer to assume that all code is broken in some way. E.g. If someone says that code "works", what they usually mean is that the software is broken in ways that they doesn't understand. When someone says a system is "secure", it means that it contains vulnerabilities that they haven't yet discovered.

A pessimistic attitude, but it has served me well.

Sometimes a decision can be made to accrue technical debt or to keep paying the interest on the acquired "technical debt rather than the principal. However, the decision has to be made by someone who understands what an elegant solution would look like (if time or budget restrains aren't there).

That's why you need somebody who is both smart (can see the elegant solution) and gets thing done (will ship a minimally acceptable solution and re-factor when needed).