Programmers and design knowledge

A few days ago I stumbled across an interesting article on java.net. There a java guy (Giovani Salvador) who was doing several hirings complained about the lack of design and architectural knowledge of java developers. His point is, that nowadays developers only care about frameworks instead of the problem domain they are working in. In his examplary job interview he asked the developer in question to explain him what kind of architecture he would use for a medium sized enterprise application. Without thinking the developer answered he would use spring and hibernate and thats about it. Even after some more detailed questions the developer did not go in detail with the architecture of such an application but talked in terms of spring framework internals.

I understand the point of Mr Salvador, that it is more important to understand the problem domain of an application than think in terms of which frameowrk to use. In my current project (a 20 person project that has the goal to replace a 30 year old cobol application with a complex datawarehouse with java clients) the company we work for has severe restrictions of which frameworks we java developers could use and how. For example spring and hibernate were strictly forbidden. The reasons for this are many and as a consultant I was in no position to argue about that. So I had to come up with alternatives how to solve database abstraction and transaction handling and so on.

My team and I then created a simple framework using the well known Java and J2EE patterns (Value Objetcs, DAOs, Factories, Session Facades, Service Locater, ... just to name a few) and found a very elegant and simple but yet powerful solution for all these problems. We even found a very performant solution for our  query performance requirement. If an application has very high requirements for query performance I would almost always use the pure sql approach.  Maybe I am not skilled enough in the usage of hibernate or jpa, but none of these frameworks were as fast as the pure approach.

My bottom line of this is "think first, code second". The existing frameworks are all very nice and helpful and ease many things. But you always have to think about your problem first to decide if it is really neccessary to use this or that framework or even any at all. Sometimes like in my example, you mustn't use any at all. Then you are forced to come up with a good design. But even if you are given plenty of rope it is better to first think about the problem domain and how to solve this in an abstract fashion.