Simply Fooled

It is always good to start out with a diagram. Here’s one:

It tries to say:

Tools that invest in “getting you started quickly” seem to always fail to stay productive or particularly useful in the mid and long term.

The typical example for this is visual programming tools or process designers of any kind. I yet need to see one that is useful beyond most simplistic demos.

I believe however the same problem is inherent with “scaffolding generation frameworks” like Ruby on Rails, Grails, and the like – possibly anything that claims “convention over configuration”.

While these approaches deliver some result quickly – eventually you will need to understand the framework, that is a pile of lots, lots of stuff that, once you lift the lid, can be totally overwhelming.

If you had started with much less, well-understood ingredients, you will be moving more slowly but at least on solid ground.

Not that I ever had an urge to use any of this kind of toolset and platform – I rather build from more essential building blocks that I understand and can keep under control – convinced that that leads to more robust, understandable, and maintainable solutions.

There is one example however that I use a lot and have a bit of a love-hate relationship with: Java Persistence Architecture (JPA).

And yet…

We use JPA a lot in most projects. It is rather convenient for simple tasks like storing records in the database and retrieving it for transactional data processing. The session cache is handy most of the time. Updating entities simply by setting values is nice. But you better not have complex queries, large transactions, or non-trivial relations. And better not ask for too much flexibility in combining modular domain models (a.k.a. Persistence Units in JPA speak). There has been so much stuff written on JPA, there is no need I repeat (the Vietnam of Computer Science however is a must).

Anyway, the point is: When you reach the limits of JPA, you better have your persistence tier already abstracted in a way that it does not hurt too much replacing the actual data access with other techniques where needed, which comes at a price.

Let’s say. If I had not invested in JPA previously, it would probably feel out of place and unwieldy now. Given the style of clean persistence API that we tend to implement on the application level these days, I would rather use some more accessible “bean mapper” tool.

Meaning…

Here is my little theory: Putting your main focus on solving 70% of the problem quickly compromises so hard on the completeness of the approach that the remaining 30% of the problem get overly expensive for its users. Worse, the “left-overs” may require to break your architecture, require unexpected 3^rd party stuff, etc.

In addition, if you have made a choice for the early win, the price to pay later on may be due at the worst point in time, just when your architecture has to stand the test of growth.

Hence:

• Don’t be lured by promises of simplifications of what is inherently not simple
• Always try to look under the hood. It is not necessary to understand everything down to the bare metal – but knowing how much there is, helps getting an idea
• Get into it, avoid what cannot be mastered in time – it will be mastered later!

Wish you a great holiday season!