History is written by the victors. Ross Snyder, who describes himself as a code jockey at Etsy, recently gave an account of the evolution of Etsy’s technical architecture from 2005 to the present. As Ross tells the story, a number of serious architectural flaws have now been sorted out. Ross attributes the former problems to trying to be too clever, and suggests that if you’re doing something “clever” you’re probably doing it wrong. However, he admits that future architects may well say the same thing about him.
I don’t want to comment on the technical detail of the story, but I was interested in the (implied) architectural processes. And I wondered how effectively and efficiently any given architectural methodology would have either solved the problems experienced at Etsy, or avoided them in the first place. The first key question here is whether such methodologies actually help to focus the architect’s attention on those issues that turned out to be critical in the Etsy case. And the second key question is whether a case study like Etsy allows us to perceive any significant difference in outcome between one methodology and another, or whether the supposed benefits of these methodologies is largely the result of Common Factors.
Sean Gallagher, When “clever” goes wrong: how Etsy overcame poor architectural choices Ars Technica October 2011