Your Architecture Sucks and I Don't Care
friendlydingo.com
friendlydingo.com
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.
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.
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.
Customers may not care about the details of the architecture (they may not even know what 'software architecture' means), but rest assured they indirectly care about the architecture. As a layperson when it comes to automobile engineering, I only care about whether or not my Toyota works. But as a customer who relies on its safety, I assure you I care a great deal about whether or not it is well architected. As a layperson when it comes to structural engineering, I only care that my house stays up. But it better be well architected.
Don't mistake a customer's lack of caring about C# vs Java with them not giving a crap about whether or not your application will suddenly spew their credit card numbers to the world due to a slipshod security model. I don't care what approach Toyota took to form my transmission, but I would sue Toyota if my transmission suddenly broke and it turned out they'd put it together in a sloppy fashion.
Like all things, a customer's real care is based on a continuum. I don't care particularly if Reddit or Twitter goes down, but I care a great deal if Bank of America suddenly lowers my balance due to a rounding error.
Of course you can get overwhelmed by architectural possibilities. Assess your customers' expectations of your uptime, overall quality, etc. Assess your customers' expectations of your ability to release new features quickly. Assess projected scaling issues. Avoid buzzwords. Adjust accordingly. A foolish building architect could easily spend a year figuring out the ideal materials, but a competent one will still get the building done safely, on time and on budget. Same with software architecture.
I believe that, if you are writing the latter kind of software, you already know who you are and what you should be doing (whether or not you actually do it is another matter.) Most software isn't "important": it doesn't affect the user's life or health or wallet or relationships or anything when it screws up.
Defaulting to assuming your software needs to be as security/privacy/stability-conscious as online banking, is just as much of a waste of time for the average programmer as assuming every website will get hit with as much web traffic as Facebook/Google/etc. and so needs to be "web-scale." Your company's intranet to-do list won't get a million hits a day, and if it goes down, people will just write things down on paper instead. It can be a 20-line Python script. Really.
I fail to see how this is not important: they haven't won a conversion out of me although I'm still getting spammed by them through my friends.
Your company's intranet to-do list won't get a million hits a day,
and if it goes down, people will just write things down on paper
instead.
The applicable advice for startups here is: when you're just starting off, your software can afford to be hella buggy, because (unless you're entirely dependent on viral growth) one lost conversion here and there doesn't do anything more to your product's momentum than any other leak in your funnel. Make a buggy v1.0, sell it to the people who will buy it, and forget about the tiny[1] number of people who check out your 1.0 and write you off because of it. Then, use the money from 1.0 to fix the bugs, and release version 2.
Assuming your product survives, most of its lifetime will be spent beyond version 2—and so most of the customers your product gets (or loses), it will get (or lose) based on how version ≥2 works, not on how buggy 1.0 was.
[1] The people who will write your 1.0 off will be "tiny" in an absolute, not relative sense. You might be losing 50% of customers because your software is crap—but if that 50% is 50% of 100 people per month, then you still aren't doing yourself much damage. Once you have 50000 satisfied users, those 700 or so people who you scared away in the first seven months will be entirely forgotten. Heck, they might even come back again, if their friends are telling them about all the features of 2.0.
As it is, there are alternatives available, and my friends experimenting with Foursquare are early-adopters that also have accounts on the alternatives. If your assumption would be right: driving 50% of users to those alternatives is an awful thing to do.
As I said, it might have been just my luck (I don't have something against Foursquare, it was just an example from my experience).
My preference is to just build less functionality in version 1.0, such that scaling / availability is just not an issue, but IMHO first impressions and early adopters count a lot.
What are the products that failed, not because they weren't popular or solved problems, but because they had a poor architecture or codebase?
I'm hard pressed to think of any.
Twitter had terrible scaling issues early on, but they solved it and are still successful.
I've heard that Flash's coded base is a steaming pile of unmaintainable C++ [citation needed]. But most of the backlash from Flash comes from the fact that it's proprietary and only partly from the fact that it runs poorly on non-Windows platforms.
Most products that fail because of poor technology choices do so before they ever get released so it's hard to judge whether or not the product would have ever been successful at all.
I can think of a couple.
Friendster, as evgen points out. Probably MySpace. Zaplets, although it wasn't really their own code but rather Microsoft's. Quattro Pro for Windows. OpenOffice, although it's still struggling along. Netscape 5. Flash (you're wrong about the reason for the backlash --- the iPhone, iPad, and Kindle are just as proprietary.) Guile. mSQL. Arguably, F-83. WordStar 2000. Most likely, the entire pile of search engines trounced by Google in its first five years: Inktomi, AltaVista, Lycos, Excite, and so on. The GEM desktop, according to Steve Yegge. CERN httpd. Duke Nukem Forever. The GNU Hurd. INFORMIX-Online, probably, although again it's hard to tell from outside the company. Windows ME, in that it was the end of the Windows 95 codebase and was replaced by a better-architected codebase in the form of XP. Windows Vista, in that it shipped very late, missing most of the promised features, and was so sluggish that many people paid a premium to use XP instead. VisiCalc for MS-DOS. Anything written in BLISS-10, after the demise of the PDP-10. Almost anything written in 360 or 370 assembler when the mainframes got replaced. troff, which had to be rewritten as ditroff because nobody could maintain Ossanna's code after he died, although it's a peculiar sort of "failure" since it's still in use today. mod_svn (everybody uses svnserve now, right?) Zillions of Perl shopping cart scripts from the 1990s. Perl 6, probably.
There's an interesting distinction hiding here.
If you're putting together a web site where you're going to write articles about your local community and sell ads, you probably aren't going to be competing on the agility of your code. You're going to be competing on the quality of your writing (with a funny metric of "quality" where your optimum is cracked.com or eHow, not Faulkner or Hunter S. Thompson, but meh.) There's very little reason to take technology risks. You should install WordPress. If you do take technology risks, you're probably wanking but you're unlikely to make your product fail.
There are hundreds of thousands, maybe millions, of products like this. Hacker News and Metafilter compete on the quality of their communities, not their codebase. Enterprise software competes on the skills of its salespeople, not whether or not the code actually works, let alone whether it's better than the competition.
On the other hand, if your code quality is actually what you're competing on --- if your users will pick your site instead of the competition's because you have better spam control, or faster page loads, or more richly linked data about Little League games, or a more usable user interface, or richer graphics --- then you're going to have to take technology risks. If you just use off-the-shelf code, your product will be easily surpassed by the competition. You have to take risks by trying some new things, and if your risks don't pan out, your product will fail.
Ding Ding Ding!
A couple years ago at the Metafilter 10th anniversary party in Portland, after he made his entrance Matt Haughey walked right up to me and called me out for having made fun of his lack of programming skills in comments on his site -- it was then that I became enlightened: http://news.ycombinator.com/item?id=1138506
Friendster. With better architecture they are sitting on billions and Mark Z is writing code in a cubicle at Google...
There were guys in Columbia university who (supposedly) had a much better system than Mark Z, and are probably writing code in a cubicle at Google or equivalent.
I suppose Zuckerberg got his start because he knows how to code, but he is an excellent CEO, something neither of these 2 guys nor Friendster had. Do you really think facebook is winning because of a better architecture?
I despise facebook, and don't use it. But I recognize that Zuckerberg has been doing an excellent job in growing the company, seizing opportunities, thinking huge, and most importantly -- bringing the right people in at the right time.
I tend to agree with Fred Wilson about the three things a CEO does: develop vision, acquire talent, raise money. Zuckerberg has done all three very, very well.
In implementing Facebook, Zuckerberg redefined the problem space to give him an implementation advantage at every turn. Limiting it to manually-added colleges didn't just restrict the total userbase to be manageable -- it also introduced the concept of 'networks' that mostly eliminated the graph traversal problem. Photos were severely limited for a long time to constrain the storage problem. They also had a massive advantage in that they came of age in the post-bradfitz era of big consumer webapp architecture.
And yes I have seen companies go under for this. Either they lose their competitive advantage of working quickly or they lose customers because of stupid problems that could have been fixed with some planning.
The (very hard) trick is to do a good enough job to deliver fairly quickly for a fairly stable product. Then be prepared to learn and refactor until it becomes better. How do you decide what is good enough? Experience...
Often I saw 2 types of architectures:
1) System-Level
2) Component-Level
The System-Level type of architecture usually shows up in companies (or person that does the explanation) where the tools being used are UNIX-y: python, ruby, rails, django, apache, nginx, mysql, linux/command-line, syslog, etc. These people/companies tend to adopt a strong "pipe"-like architecture.
The mindset here is to write a program/application that does one thing really well.
The Component-Level type of architecture usually shows up in places where there's a strong OOP/Java/.NET culture. Often, this is the place where many people try to write the best damn code possible. You'll see some sort of "ManagerXYZ.java" or "XYZService.java" or "PolicyXYZ.java" or "XYZProvider.java". The Component-Level type of architecture tends to link many components tightly together and somehow each Component acts as if it is a "mini-API".
The mindset here is to write a library/component/class that does one thing really well.
Which one that the author chose?
Now when ugly code happens. Well.. I'd like to stay away from flame-war and all that stuff so I suppose you'd have to make your own judgement which way is better: System-level or Component-level.