By Anton van Straaten at Mon, 2012-01-02 09:14
Pretty much my experience of the technology field in a nutshell.
According to what I can glean from a John Siracusa/Dan Benjamin “Hypercritical” podcast (at 5by5.tv), Apple’s iCloud sync strategy doesn’t resolve conflicts via a complicated merging scheme (such as are found in source code version control systems).
If you enter a contact from one device and enter it in differently on another device, you’ll no longer get a dialog box asking you to resolve the difference. Instead, iCloud will pick one to push down to all devices and that’s that. What saves you from losing data is that they keep all versions of the contact on the server. When you enter your contact manager and discover a contact missing the data you thought you’d added, you can click a button and see previous versions and then “revert” to the “correct” one, if you so choose. Depending on the application, you can probably choose to “cut” from one version and “paste” into the other (thus doing a merge without thinking of it that way). Same kind of thing you can do with Time Machine.
I really like this approach because it makes things seem simple as you go about your life.
If you never enter data such that a conflict would occur (i.e., you never enter two contacts for the same person on separate devices or experience network splits) then you’ll never even notice versioning and history because the algorithms behind the scene don’t do anything other than store versions and are thus too limited to mess anything up.
However, if you look at a contact and say, “Wait, I fixed that yesterday. What’s up?” or worse, you end up dialing a wrong number or emailing a wrong address because you didn’t notice that the contact is not the one you thought you corrected, you can hit the “versions” button and pick the right one and you’re done and all your other devices are done, too.
The “syncing” problem is so much easier when you leverage the human brain, which you can do because the data is personal.
Really nice, and more akin to the way people think about these things. The inherent problems of concurrent updates are never brought to the surface. Everything is always consistent. And if the current state isn’t what you want, you make it what you want when you want to, because, ultimately, you are the single source of truth.
Developers seem to repeat to each other in an echo-chamber kind-of-way various methodologies and memes in what after enough repetition feels like an empty cargo-cult faith.
Because I’m not immune, I like to revisit basic ideas.
Whenever I feel that there’s a lack of clarity (maybe even just on my part) about what a project adds up to, the response from others is that we use iteration to find out what it adds up to. It’s a conversation ender, it seems, in which any lateral approach is asserted to be nothing more than “waterfall”.
So, some thoughts:
Business projects (for products) are waterfall: you plan, design, develop, market, deliver, all in the context of a strategic, business goal and according to a time schedule.
Software projects are iterative: explore, invent, revise, learn-as-you-go: mini-waterfalls over and over.
Iteration is a tactical technique for achieving a strategic goal.
A strategic goal is not a vision statement, or an identification of a problem space.
A strategic goal is a reasonably solid idea of what a release (even for a website) looks like and what it means for customers and the business.
If there’s no strategic goal, iteration leads to muddle.
Muddle is not a successful business strategy.
Muddle is not a product.
Even the most stereotypically heads-down software engineers need to know the strategic goal. Repeat it to them over and over. It’s hard for them to remember when they’re mired in the day-to-day, iterative, tactical development but it’s absolutely necessary, because it’s the only way for them to make good choices, make sure they’re solving actual problems and minimize technical debt.
I think the relationship between the goal and the iterations meant to achieve it is often lost in the literature.
For instance, “maintaining” an existing product doesn’t really require a strategic goal and all the talk about formulaic iterative development and agile makes a lot more sense in that context.
Coming up with something new is a different case all together. Even if the strategic goals shift as the business changes (say, in a start up situation), those goals should be clear to everyone working on a project. (E.g., “DropBox: We’re a folder that syncs. That’s it. That’s what we do. If what you’re working on doesn’t contribute to solving the problems of being a folder that syncs, then don’t work on it.”)
Writing apps for specific end-customers who keep changing their minds (the use case for iterative development with lots of feedback, etc) can also lead to muddle. A nice strong contract with defined deliverables is good no matter what, even for fickle customers, and even given that it’s not so easy with software to determine if a deliverable is delivered.
The goal is to define a strategic goal and keep it in mind, no matter how difficult that is to do. It won’t guarantee business success, but the business failure won’t be because the software doesn’t work.
Seems like all you have to do is use ORM once past the “implement a todo app” stage to get to these conclusions.
In summary (TL;DR)
ORM is initially simpler to understand and faster to write than SQL-based model code
Its efficiency in the early stages of any project is adequate
Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL
Entirely anecdotally, I claim that the abstraction of ORM breaks down not for 20% of projects, but close to 100% of them.
Objects are not an adequate way of expressing the results of relational queries.
The inadequacy of the mapping of queries to objects leads to a fundamental inefficiency in ORM-backed applications that is pervasive, distributed, and therefore not easily fixed without abandoning ORM entirely.
Instead of using relational stores and ORM for everything, think more carefully about your design
If your data is object in nature, then use object stores (“NoSQL”). They’ll be much faster than a relational database.
If your data is relational in nature, the overhead of a relational database is worth it.
Encapsulate your relational queries into a Model layer, but design your API to serve the specific data needs of your application; resist the temptation to generalize too far.
OO design cannot represent relational data in an efficient way; this is a fundamental limitation of OO design that ORM cannot fix.
A Groovy Programming book called ORM the Vietnam of Computer Science. I think I’d rather have the problem than the solution.
(Not a whole lot of people agree with me, as witness this discussion). I think ORMs are okay for Rails style apps with application specific data sets especially if the apps are to be client installed on a variety of RDBMS implementations. Maybe not so good for other sorts of data sets, or when writing an app to use a database some other app has created (say, at the end of a data pipeline). I don’t find writing SQL and related de/serializers tedious even in Java, mainly because I wrote a sort-of functional way to do it.
Maybe I’m a loon, but that’s an un-godly amount of code for one lonely table.
I know I’m a loon. I can’t for the life of me understand why anyone would, at any time, use Spring for anything. I understand all the sentences and paragraphs people say when they speak about it, but it still doesn’t add up, especially when you listen to your rapidly deteriorating psyche before you’ve even completed downloading all the dependencies. I just fall back to jokes and bromides: The first indication that you’ve horribly, horribly botched your design is when Spring seems like a good idea. If you want late binding, use a dynamic language. If you’ve got a problem and you think Spring is a solution, now you’ve got two problems and three maintenance programmer jobs. If you ignore 99% of what academics have to offer us, you get Spring. Spring is the antidote to a poison which was the antidote to a poison which was an antidote to a poison which was taken when you decided a bash script was old fashioned. My favorite: What’s Spring? It’s the bulk of the lines I see in stack traces.
*Shudder*
By which I mean, clearly, I’ve completely missed something. Scala + Spring? It’s like adding getters and setters to Erlang modules. There’s something really cargo-cultish in it all.
Oy.
Keith Irwin
Plenty of tropes, not much Zen.
