"If you find yourself maintaining this horribly designed, hacked together legacy code from the early days of a company be thankful and bask in its glory. Without that spaghetti nightmare you wouldn’t have that job. It was that short sighted thinking that was able to get something done and create a profitable product/company." - xero from Bookmarklet

I have to agree with this article. It should be noted though that it does eventually say that you need the organization and clarity in startup code, just not to the point that it drives any real decisions. - xero

Seems pretty bogus to me. Both sides of the pendulum can be equally fatal - if you don't get stuff done, you won't have customers, but once you have that spaghetti nightmare you may not be able to keep them, and worse, you may not be able to make the new developers you hired with the money from the customers either be productive or stick around. - Robin Barooah

I think you have to find the balancing point, but I think it leans toward productivity instead of elegance. But, the more you forgo good organization and design, the more important automatic tests are going to be. You have to keep maintenance in mind, but you generally let getting the job done quickly win at first. Version 3 or 4 of your product is almost always a complete rewrite anyway. Once you know the company has a future then you can plan for maintenance. I generally think things should be done as elegant as possible under the circumstances. In a startup you'd weigh your options between the bandaid and the rewrite, but generally take the bandaid route, just be sure to note it's a hack in the code. - xero