Same old warning against becoming an "architecture astronaut". Look, I understand you got burned and you want to share. However, I'm getting a teeny little bit tired of people who -- out of good intentions -- make it sound like architecture (and clean code and whatnot) isn't important at all.
There's a reason you should pay attention to the state of your codebase. Or rather, there should be a reason for it, one that is better than the intellectual equivalent of wanking. If you're trying to make your code "beautiful" just because you've heard that it's good to keep it "clean" and to "follow every coding standard you've ever heard of", then you're wasting your time.
However, if you're refactoring your code because you found yourself doing the same thing for the 10th time (with small differences), then it's time well spent. If you're spending a bit of effort to structure your code in a way that will help you avoid shooting yourself in the foot (because you've been there and done that and it's no fun at all), then it's effort well spent. And guess what? That's what architecture is all about.
Your users don’t care about architecture, they only care if your app works.
Architecture is what keeps your app working over time.
Came here to write something like that, but you said it better than I could. Soon, I'm going look again at people continuing a 1yo rewrite of some codebase, which noone {is willing / knows how to} touch... 2nd rewrite actually. You don't need to worry about the traffic and conversion rates when your application cannot be changed in any way and works only because it cannot stop.
FTA: "The end result was mediocre product reviews and slow sales. But man, was my code beautiful."
The author is missing the point. Features and user experience drive sales not architecture or beautiful code. Sound architecture and clean code provides a basis for ongoing development. Simple once only app then be a cowboy and hack it together, want a product with an ongoing development cycle then care is needed when building the foundations. "An ounce of prevention is better than a pound of cure" - Benjamin Franklin.
I think that this article is talking almost entirely about shipping. If you consider the start of Facebook or Twitter or Tumblr, a lot of what they had going for them was first-mover advantage and building out a product that people actually used. If Twitter started out trying to build the architecture they have now (http://www.readwriteweb.com/cloud/2011/01/how-twitter-uses-n...), they probably would have never launched.
Re: refactoring and other comments. Of course optimizing and re-working your code for new use cases and scale issues is critical to support your product, but unless people are using it, you're not going to know what those use cases are and what parts of your product you need to scale.
There's a reason you should pay attention to the state of your codebase. Or rather, there should be a reason for it, one that is better than the intellectual equivalent of wanking. If you're trying to make your code "beautiful" just because you've heard that it's good to keep it "clean" and to "follow every coding standard you've ever heard of", then you're wasting your time.
However, if you're refactoring your code because you found yourself doing the same thing for the 10th time (with small differences), then it's time well spent. If you're spending a bit of effort to structure your code in a way that will help you avoid shooting yourself in the foot (because you've been there and done that and it's no fun at all), then it's effort well spent. And guess what? That's what architecture is all about.
Your users don’t care about architecture, they only care if your app works.
Architecture is what keeps your app working over time.