Designing from the wrong end

In a talk on Java in the cloud, I described a problem that I think afflicts most of the software designs I’ve heard about lately. I call it designing from the wrong end. It comes from our obsession with bolting enterprise Java solutions and technologies onto every kind of problem we face. In the talk I set off a little verbal firework. “I regret every word I’ve ever written on this blog about Spring.” I’d like to explain in more detail what I mean by designing from the wrong end and how that line fits in.

Imagine an application like LinkedIn that presents and provides access to users’ professional profiles. The idea is that you keep your CV online and use current or former colleagues as references.

If I ask ten Java developers how they’d design and implement it, nine answers will go roughly like this. I’ll use a relational database, map the entities to it with Hibernate, manage transactions with Spring, and have a DAO and a service layer. Definitely an MVC framework for the web layer. Ask where they’ll run it and they’ll innocently say Google App Engine. They’ve never used it, but apparently it scales well.

That’s exactly what I mean by designing from the wrong end. We’re obsessed with technologies and layers and overlook what matters. We blindly apply the practices we’ve seen, know best and treat as sacred. Stop, stop, and stop again. Go back to the beginning. Clear your head and look at the problem from the ground up.

My experience tells me to design an application from the bottom and the top. Start by asking what data we’ll work with and what we’ll do with it. Will we mostly read or write it? What’s the ratio of writes to reads? Do we have one kind of data or several categories? How much data will there be? Do I need search or complex queries, or will CRUD be enough? How consistent does the data need to be? Can we live with stale data?

What we need to do with the data tells us something about what the client will look like. Do we need a thick or a thin client? Will there be one kind of client or several? Do we want an API for integrating with other services? Where will we keep communication state? Can we afford to keep it on the server? How much data can we transfer without making things too slow?

Answering those questions gives us fairly clear requirements for the middle tier and for the specific technologies that will suit us. It even tells us what infrastructure we can host the solution on. You’ll probably find that using Spring or Google Guice makes no real difference. It’ll be the last thing you’re worried about.

One more plea. Please start somewhere other than the middle :-).