5 ms·

Your Architecture Sucks and I Don't Care

59 points by rco8786 16y ago

wccrawford 16y ago
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 16y ago
  It seems that, once again, the best position is somewhere in the middle, rather than on either extreme.
  - kls 16y ago
    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.
CodeMage 16y ago
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.
- viraptor 16y ago
  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.
- synotic 16y ago
  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-nosql.php 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.
  - DougBTX 16y ago
    He says that his latest creation with "minimal" architecture hasn't shipped yet either, so this is all hot air.
- wambie 16y ago
  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.
- Aegean 16y ago
  Slightly branching the topic, but how would you market a product that has cleaner architecture? How do you show its power? I have been an architecture advocate from the start. We claim to have the cleanest code among competitors and it is probably true. We get many people telling how beautiful the code is to work with. But there is such a marketing cacophony that it bears less significance than it ought to, at least that is what I perceive. There is more to architecture than refactoring code. For example, you should achieve the simplest design while keeping it generic. But these words are so overused that it gets really vague for someone to judge how good your architecture is. How do you differentiate? Well, we have the simplest and most generic solution that is very well architected compared to others. To overcome this, we tried to add quantifiable terms to our product datasheet and produced this: http://bit.ly/ifGXxN http://bit.ly/ifGXxN Still, I feel that only engineers care, and saying we have generic and simplest can be defeated against a compelling demo with a huge, complex logic behind it. You may surely win in the long term but a startup has little time to wait.
Jach 16y ago
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.
atomical 16y ago
What if your business is based on architecture? What if your customers are developers who care about a rock solid foundation?
statictype 16y ago
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.
- saurabhsharan 16y ago
  But what if Adobe actually had (and maybe still are) tried to make Flash performant on non-Windows platforms, but can't because the codebase is such a mess? In that case, yes – Flash did fail because of a bad codebase. Then again, Flash is probably an extreme example, but it just goes to show that there is a point at which a bad codebase will interfere with your product.
- evgen 16y ago
  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 16y ago
    What architecture issues caused Friendster to fail? I'm not very familiar with it.
    - blasdel 16y ago
      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.
mcantelon 16y ago
Meh. Pay at the beginning or pay 10 times over if you're forced to re-architect.
- ct 16y ago
  Or never launch because you're always worrying about the millions of users you'll never get because you're too busy trying to learn NOSQL instead of just using MySQL for the first iteration.
- ceejayoz 16y ago
  Paying 10 times the cost in the future may be easier than paying the cost today.
powdahound 16y ago
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 16y ago
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...
napierzaza 16y ago
I love "why are you not rich yet?" articles. It's so motivating.
yesno 16y ago
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.
lemmsjid 16y ago
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 16y ago
  > 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.
brudgers 16y ago
A case in point: http://news.ycombinator.com/item?id=2062057 http://news.ycombinator.com/item?id=2062057
weixiyen 16y ago
I'm re-doing my architecture because it will allow me to push these said features out much faster.
EGreg 16y ago
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.
ukorac 16y ago
Marcus Ranum on why bad architecture can lead to bigger problems for everyone else: http://www.youtube.com/watch?v=o59mQhBiUo4 http://www.youtube.com/watch?v=o59mQhBiUo4

59 points by rco8786 16y ago

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 16y ago
It seems that, once again, the best position is somewhere in the middle, rather than on either extreme.
- kls 16y ago
  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.

CodeMage 16y ago

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.

viraptor 16y ago
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.
synotic 16y ago
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-nosql.php 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.
- DougBTX 16y ago
  He says that his latest creation with "minimal" architecture hasn't shipped yet either, so this is all hot air.
wambie 16y ago
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.
Aegean 16y ago
Slightly branching the topic, but how would you market a product that has cleaner architecture? How do you show its power? I have been an architecture advocate from the start. We claim to have the cleanest code among competitors and it is probably true. We get many people telling how beautiful the code is to work with. But there is such a marketing cacophony that it bears less significance than it ought to, at least that is what I perceive. There is more to architecture than refactoring code. For example, you should achieve the simplest design while keeping it generic. But these words are so overused that it gets really vague for someone to judge how good your architecture is. How do you differentiate? Well, we have the simplest and most generic solution that is very well architected compared to others. To overcome this, we tried to add quantifiable terms to our product datasheet and produced this: http://bit.ly/ifGXxN http://bit.ly/ifGXxN Still, I feel that only engineers care, and saying we have generic and simplest can be defeated against a compelling demo with a huge, complex logic behind it. You may surely win in the long term but a startup has little time to wait.

Jach 16y ago

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.

atomical 16y ago

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

statictype 16y ago

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.

saurabhsharan 16y ago
But what if Adobe actually had (and maybe still are) tried to make Flash performant on non-Windows platforms, but can't because the codebase is such a mess? In that case, yes – Flash did fail because of a bad codebase. Then again, Flash is probably an extreme example, but it just goes to show that there is a point at which a bad codebase will interfere with your product.
evgen 16y ago
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 16y ago
  What architecture issues caused Friendster to fail? I'm not very familiar with it.
  - blasdel 16y ago
    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.

mcantelon 16y ago

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

ct 16y ago
Or never launch because you're always worrying about the millions of users you'll never get because you're too busy trying to learn NOSQL instead of just using MySQL for the first iteration.
ceejayoz 16y ago
Paying 10 times the cost in the future may be easier than paying the cost today.

powdahound 16y ago

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 16y ago

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

napierzaza 16y ago

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

yesno 16y ago

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.

lemmsjid 16y ago

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 16y ago
> 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.

brudgers 16y ago

A case in point: http://news.ycombinator.com/item?id=2062057 http://news.ycombinator.com/item?id=2062057

weixiyen 16y ago

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

EGreg 16y ago

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.

ukorac 16y ago

Marcus Ranum on why bad architecture can lead to bigger problems for everyone else: http://www.youtube.com/watch?v=o59mQhBiUo4 http://www.youtube.com/watch?v=o59mQhBiUo4