Posted by tobi — 08:45 AM Apr 22
Todd Hoff in his love letter to Amazon’s SimpleDB
SimpleDB shifts work out of the database and onto programmers which is why the SimpleDB programming model sucks: it requires a lot more programming to do simple things. I’ll argue however that this is the kind of suckiness programmers like. Programmers like problems they can solve with more programming. We don’t even care how twisted and inelegant the code is because we can make it work. And as long as we can make it work we are happy.
I can’t think of what drove him to write this. This argument is directly contradicted by the success of Rails.

Marcel 22 Apr 11:38
It’s true, there is a whole class of programmers who have stopped adding to their box of programming tools/techniques, and are no longer curious about writing better code or working more efficiently. If you make things more complicated, then you can feel good about being able to solve complicated problems, instead of being able to get things done more efficiently.
Also, learning new problem solving tools is hard, so people tend to stick to the tools they know. I remember some axiom about not trying to solve every problem with a hammer just because that’s the only tool in your toolbox, but I’m not sure exactly how it goes.
Maybe that’s something that happens to programmers who get stuck spending years trying to maintain and modify crappy legacy code written by someone else. And usually the someone else has suspect skills to start with. In that case, the highlight of your day is telling your manager ‘you want it to do what? oh, that will take a looong time and be verrrrry complicated. and i will remind you once again that’s because we’re locked into this crappy software written by all of those stupid idiots who came before me.’
jason 22 Apr 21:50
I’m confused.
Is this for or against the Rails way of putting database logic into our models?
There is a lot to be said for keeping it that way. Atleast for small to medium sized projects, or the majority of website which don’t have massive amounts of users.
It less because “learning new problem solving tools is hard” and about keeping everything simple and easy to manage. Being agile.
So I disagree with a lot of what has been said here. There is only subtle differences between being “locked into this crappy software written by all of those stupid idiots who came before me” and being locked into a diverse range of technologies that perfectly fit each their field yet nobody has the skills or finance to maintain them “perfectly”.
Finanzamt 23 Apr 09:26
Did you try it?
tobi 23 Apr 09:57
How did we get from this quote to an implementation detail of Active Record? :-)
I’m not sure I’m understanding the point you raised but i think you are saying that you don’t like that AR overtakes data sensitization instead of the database.
To understand the rationale on this please google for the difference between “Integration Databases” and “Application Databases”. Rails uses the Application database paradigm where only a single webapp accesses a given DB. All external access to the same DB goes through an API such as REST. Given this it doesn’t matter at all where the constrains logic resides: It can be in the DB or the Model, both are on the path of data to the DB just on different layers. Given that we all here love ruby its only natural to use Ruby for constrains and not manic SQL.
I assure you that this argument has nothing to do with size of project. Shopify is a large project, in fact larger than most large projects and AR validations were never a problem.
Marcel 24 Apr 14:27
I guess I wasn’t clear in my first post, I was keying on this bit: “I’ll argue however that this is the kind of suckiness programmers like.” when I started talking about programmers who have stopped trying to learn new and better ways to do things. (Not being able or willing to add new tools or techniques to their toolboxes.)
It might seem counter productive, but there is a whole class of programmers who are perfectly comfortable with that kind of suckiness. They will just go ahead and copy and paste a lot of code to do simple things without ever being curious about finding better ways (new tools) to do things. In fact, I suspect that there might even be a tendency in many programmers to fixate on the most complicated solution possible.
The success of Ruby, fortunately, proves that those suckiness loving programmers aren’t the only type of programmer, which means that we have at least two camps of programmers: suckiness lovers and ruby loving suckiness haters.