
Your Architecture Sucks and I Don't Care - rco8786
http://friendlydingo.com/blog/2011/your-architecture-sucks-and-i-dont-care
======
CodeMage
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.

~~~
synotic
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...](http://www.readwriteweb.com/cloud/2011/01/how-twitter-uses-
nosql.php)), 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.

~~~
DougBTX
He says that his latest creation with "minimal" architecture hasn't shipped
yet either, so this is all hot air.

------
lemmsjid
This article makes such sweeping generalizations.

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.

~~~
derefr
> 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.

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.

~~~
bad_user
Every time I tried Foursquare their service was down ("for maintenance" their
page said). After ~ 5 attempts in ~ 5 different days I stopped trying. Maybe
it was just my luck, but even Twitter has been more reliable for me.

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.
    

If that to-do list goes down repeatedly, people will not use it ... it's hard
enough to convince them to try it in the first place.

~~~
derefr
But Foursquare being down, and losing a conversion from you, didn't affect
your life any more than if you had just _not heard of_ Foursquare in the first
place. "Important" software can actually have _negative_ utility if it's
programmed wrong: it can take away your money, make you lose your job, give
you a lethal dose of radiation, etc. Most software isn't important in that
sense.

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.

~~~
bad_user
You're argument would be OK if there weren't alternatives to Foursquare.

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.

------
wccrawford
Yes, the end user benefits from refactoring code. Good code is easier to
maintain and has fewer bugs. That means faster updates and fewer failures. I
can't imagine a user that doesn't want that.

~~~
jbri
It seems that, once again, the best position is somewhere in the middle,
rather than on either extreme.

~~~
kls
Right good architecture is transparent things seem intuitive but yet not
cumbersome. A good deal of standards and conventions can eliminate a fair
amount of "architectural" code. When I see managers and factories everywhere
is a project I know that it has the signature mark of being "architected" and
usually find a good deal of gold-plating that need not be in the project.

------
statictype
Agreed. No one cares about whether you used lisp or C++.

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.

~~~
evgen
_What are the products that failed, not because they weren't popular or solved
problems, but because they had a poor architecture or codebase?_

Friendster. With better architecture they are sitting on billions and Mark Z
is writing code in a cubicle at Google...

~~~
statictype
What architecture issues caused Friendster to fail? I'm not very familiar with
it.

~~~
blasdel
Every single thing a user could do was based on FOAF-keyed permissions, and
graph traversals were slow as hell.

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.

------
powdahound
The real lesson here is "balance". You won't be successful if you have a
kickass architecture and no users. You also won't be successful if you have
users that are always frustrated because your site is slow or unavailable.

------
suprgeek
Your Architecture needs to be "good enough". If you strive for the absolute
best, most flexible, most extensible, blah blah, you will be stuck with
analysis paralysis and spend too much time upfront with less information to
make decisions. Conversely if you just begin coding with no plan - you will
have an unstable product that will fall apart at the first instance of some
deviation from the normal.

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...

------
yesno
There's not enough detail of what kind of "gold platting" the author had done.
Now I'm not an expert on "architectures" or "patterns" and my view is just a
personal observation when I glanced over HN, slideshare.net, and InfoQ to some
extend.

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.

------
Jach
Besides the reasons users benefit from good code, if your code is open source
and you want anyone else to contribute it better be decent.

------
mcantelon
Meh. Pay at the beginning or pay 10 times over if you're forced to re-
architect.

~~~
ceejayoz
Paying 10 times the cost in the future may be easier than paying the cost
today.

------
ukorac
Marcus Ranum on why bad architecture can lead to bigger problems for everyone
else:

<http://www.youtube.com/watch?v=o59mQhBiUo4>

------
EGreg
Sorry man, I like architecting things. And as a result, I now have a framework
that will help me crank out lots of stuff, instead of that one-off project.

------
brudgers
A case in point:

<http://news.ycombinator.com/item?id=2062057>

------
weixiyen
I'm re-doing my architecture because it will allow me to push these said
features out much faster.

------
atomical
What if your business is based on architecture? What if your customers are
developers who care about a rock solid foundation?

------
napierzaza
I love "why are you not rich yet?" articles. It's so motivating.

