3 ms·

Interesting, but do we have enough information? To quote Spolsky... A 50%-good solution that people actually have solves more problems and survives longer than

Interesting, but do we have enough information? To quote Spolsky... A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it. (http://www.joelonsoftware.com/items/2009/09/23.html http://www.joelonsoftware.com/items/2009/09/23.html) This article doesn't go into details about the history of why Etsy's architecture is the way it is. It's entirely possible that this architecture enabled them to launch and iterate faster at a critical point in their history, without which they'd be nowhere. Do what you need to now that will work. If your project is successful enough to experience a few orders of magnitude growth it'll need rearchitecting in some way anyway; build the heavy engineering when you know what you need, not think you know what might be the pain point.

SoftwareMaven 15y ago
The corollary to that theorem is to make changes when you identify thaas what you are doing isn't working anymore as that pain grows exponentially.
div 15y ago
It doesn't feel like this applies here. 6-7 years ago a decision was made to go with stored procedures over using an orm or at least implementing db logic in the application code. Along with this, they also chose to split the responsibility for code and sql across two teams. 6-7 years ago, plenty of other options were available. In fact, the sharded MySQL solution that they use now was already possible back then. It sounds more like they made some architectural decisions based on the companies org chart and it came back to bite them in the ass hard. edit:typos
- SoftwareMaven 15y ago
  The constraint may have been knowledge. They may have made a very reasonable tradeoff to forego learning "best practices" and "proper architecture" to just get something out the door. The original developer may have just graduated with his philosophy degree and never have written more than a bash script. Hard to say. Given the size of the company, the architecture didn't grow along org charts (that is a very real phenomenon in large companies!). Rather, the org chart grew along architectural lines. Regardless of cause, it is a pretty significant smell and can tell you something is (or will be) wrong.

SoftwareMaven 15y ago

The corollary to that theorem is to make changes when you identify thaas what you are doing isn't working anymore as that pain grows exponentially.

div 15y ago

It doesn't feel like this applies here. 6-7 years ago a decision was made to go with stored procedures over using an orm or at least implementing db logic in the application code. Along with this, they also chose to split the responsibility for code and sql across two teams. 6-7 years ago, plenty of other options were available. In fact, the sharded MySQL solution that they use now was already possible back then. It sounds more like they made some architectural decisions based on the companies org chart and it came back to bite them in the ass hard. edit:typos

SoftwareMaven 15y ago
The constraint may have been knowledge. They may have made a very reasonable tradeoff to forego learning "best practices" and "proper architecture" to just get something out the door. The original developer may have just graduated with his philosophy degree and never have written more than a bash script. Hard to say. Given the size of the company, the architecture didn't grow along org charts (that is a very real phenomenon in large companies!). Rather, the org chart grew along architectural lines. Regardless of cause, it is a pretty significant smell and can tell you something is (or will be) wrong.