O/RM Encourages Knowledge Reduction

Here is an other thesis from the "what encourages what" series.

From my own experience and observations, the object-relational mapping frameworks encourage the knowledge reduction since they offer access abstraction and not only the mapping itself. Some of the reasons for this claim are the following:

• The 100% concentration on the object orientation leads to the ignorance of technological finesses of the underlying database
• The ability to switch the database system behind the scenes is rarely necessary. Vendors of standard software and owners of legacy databases whithout the future are almost the only cases where such a switch would be needed
• O/RM abstracts from SQL. If you have SQL knowledge, why should you reduce it and go for a pseudo-QL or whatever query criteria langauges the frameworks offer?
• The O/RM framework knowledge must also have to be deep concerning the tuning, fetch strategies etc. - why invest here instead of investing into a very better knowledge of the database system? Well, one would be potentially "unportable" to an other database system, but this argument is very academic
• It is very, very difficult for a DBA to tune statements produced by the O/RM framework since they must go back tuned. The ideal usage of an O/RM framework says you shouldn't use native SQL, so you must trick around to make things work the way your DBA suggests
• The more abstract the framework the more common are the statements it produces the more untypical and unoptimized they are concerning the underlying database
• Not everything can be done optimally using a wrapping SQL standard such SQL-92. Starting using extensions provided by the underlying database means to violate the purity of the O/RM thought
• In the real world, you simply have situations where it's much more easier to work with results sets and generally flat representation of data instead of objects which cal also be very expensive in some cases
• One can also use native SQL with the O/RM. This leads to "unpure" abstraction, but in many cases would be the very welcome way if you want things to run instead of only going
  

So I think that there is no golden way. O/RM has its place wherever you need object graphs to be filled and persisted transperently. Whenever you want to have control over the data access and don't really care about the 100% object-orientation particularly where you simply need flat data, you don't really have to go for 100% O/RM - you can work with the database via native SQL and use O/RM for mapping only, not for the access abstraction.

The best way could be to mix both approaches. But to ignore the database means to reduce knowledge to me. There is no golden hammer, O/RM isn't any as well. I prefer to mix things which are working well for a concrete purpose instead of trying to do eveything using one tool.

A very wise statement I read somewhere on the web says: if your one and only tool is a hammer, every problem starts to become a nail.

Java Encourages Overengineering

Yes, it does.

I needed years to come to realize that. But the real experience that it realy does has come to me in a project where one had to start from the first line of code without having anything: no infrastructure, no real business understanding and no support from within.

What happens is quite simple: the infrastructure is done quickly since it isn't a real art, and you only need one who can setup an agile development environment from scratch. The mess begins, as one starts to analyze the requirements and ends up having a tone of lines of text without having written a considerable line of code. Well, it doesn't really have to do with Java, but it's normal for Java based projects to be completely overanalyzed and overdesigned. And the discussions start how to go doing that, doing this, generating that, deriving this. It takes that much time so that you are not able to convince anybody of that to be the right platform and the right way. And you cannot really stop this development since you would demotivate the team if they are not allowed to play around - it is a big sand box.

The most intersting situation is when you have a group of prima donnas where everybody has his own preferences concerning frameworks, modeling and patterns. Molecular discussions start to happen where simple code could be written to check out if that damn thing works. Even the youngest junior developer has the head full of architectural mess unsupported through own experience but producing a lot of noice. Every day, a generally new idea or approach is born whenever one reads about it in the newest magazine article and has to be tested immidiately in the running project.

Why does it happen? Because of the massive lack of pragmatism. Having a million of possibilities to solve a thing around encourages the play instinct where a solution could arise quickly. Having a very heavy complexity of the platform and the solutions being built upon it encourages half knowledge. Having nearly everything from the very smart books to be able to be implemented or even already implemented by somebody else encourages the effect of not seeing the wood for the trees and the massive lack of concentration. There are so many cool things to do that one doesn't know where to stop using them or trying to implement them. And even if you start implementing the way you feel it to be right one comes and shows you using metrics and whatever quaility measurement is around that your code is rubbish! Here, the life stops and everything becomes self purpose so you are trying to approximate the ideal perfection line instead of providing the customer with a solution which works now and will work later.

My opinion is that Java as it currently is doesn't encourage the rapid development though one has a dozen of mechanisms how to be capable of doing that. Not many Java developers could sit down and start coding without thinking about a billion of side effects of doing so or being critisized for not doing so - directly or indirectly through very smart magazine articles with very cool approaches and rules. You simply don't have a chance to develop - you must engineer. In most cases it means that you overengineer because of the fear of doing that wrong or the blindness to do it simple. And it is completely uncool to have a simple solution. It's cool to have a beauty monster.

And what now happens with the language extensions and multilinguality leads to much more mess since they start to mix unmixable things and increasing the overall complexity. The KISS principle is dead there, it's a self purpose leading to developers working on the beautification of principles instead of customer solutions.

I'm dissapointed - I really think that Java now encourages the overengineering. Not everything is lost as yet, but it is on the best way to get lost forever.

Financial Crisis Helps Conferences To Get Better

Did you notice how full and qualified this year's IT conferences are telling they are? I did.

Mostly every considerable IT conference which has survived announces the never-before-program full of the never-before-experts having the never-before-record of session suggestions with never-before-quality and generally a never-before-lot of responses to Call For Paper. Do you know why? I guess I do, though it seems very logical and shouldn't get mentioned.

The reason is the financial crisis this year. Experts seem to have much more time since experimental projects have all been stopped or are getting stopped now. Through the "good" years it was a very difficult thing to put an expert on a session since they could just pick up icing on the cake. Now it looks a bit different, and they fight for sessions. Provocation? Maybe. But also a fact.

The main problem and the real dilemma is that experts talk only to experts through those conferences since the customer representatives are not going to those events because they must save money. All those exhibitors are left alone talking to each other without a chance to sale anything.

The technical quality of the conference is getting better, but the sponsors are at least worried. It's a doom loop, and it will never happen that both come in one piece.

So, I think the financial crisis helps conferences to get qualitatively better, but the return on invest for sponsors is absolutely minimal this year. Sounds like self purpose to me.