by Sindri Traustason

Recently the VYRE core development team held an internal workshop to discuss and brainstorm about future technologies and our long term plans for staying ahead of the curve in that space. No, sorry I won't be revealing the amazing secret action plans we came up with. Instead I want to write about an anti-pattern I noticed in how people judge problems and solutions.

The story goes like this

Someone proclaims that technology foo is a huge hassle. To use foo we have to do a whole lot of X. The more experienced developer then points out that foo is intended to take away the hassle of having to do Y, and that Y is much more difficult than X.

A more concrete example would be claiming that Hibernate is no good because it's a huge hassle to have to define all the mappings for all your persisted classes, and their relationships. However the alternative is writing loads of code that copies values from JDBC result sets into class properties. You still actually have to define the relationships, but back in the pre Hibernate days, no one thought that was a particularly big part of the job.

So how do we make decisions then?

From the abstract example above we can derive a simple rule to determine weather the juice is worth the squeeze, or getting rid of Y worth the X. 

foo is worth it if the following effort equation is true:

    effort(foo(X)) < effort(Y)

Note that you still have to make sure that foo(X) = Y. And remember if that is the case it might well be that X ? Y. In that case the effort equation must be true.

But it's not that simple

This is all of course a bit of a simplification, choosing technical solutions is usually more than balancing between the effort involved two different sets of work needed. But my aim is to illustrate that these sort of choices are reasonably simple to formulate. You could go on and model more complex decisions, such as weather or not to replace one solution with another. Then the equation becomes you should choose technology foo over bar if:

    effort(foo(X)) < effort(bar(Y))

And for existing projects you have to take into account the effort of switching:

    effort(foo(X)) < effort(bar(Y)) + effort(switch(foo, bar))

But beware that the switch cost is only there in the short term. For a concrete example of this we can take the choice between Maven and Ant. With Maven dependency management and deployment becomes easier, however the build itself has somewhat more effort. So one could say the following needs to be true to choose Maven over Ant.

    effort(Maven(manageBuild)) < effort(Ant(manageBuild, manageDependencies))

I think most people that have used both agree that managing an Ant build is usually simpler than Maven. So you should use Maven if managing your dependencies is difficult, which it is for any non trivial programming project. Some Java projects might not have many dependencies, but have a somewhat complicated build process, and in those cases Ant would be a better choice. Your mileage may of course vary.

The juice

So what I hope you get out of reading this is a slightly more analytic way of deciding what to do or not to do. I'm not suggesting you start writing equations for all you decisions, simply having a mental model of what work is required to use something, what it replaces and the effort involved in each helps.