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.
2 comments:
Wow, that's quite a pessimistic point of view ... but there is a lot of truth in it!
I spent some time, trying to keep up with the fast development of the existing and uprising Java frameworks and their possibilities. There is always only time to get a very vague impression. When deciding for a way to implement a new module for our software, I often have the feeling, that I've chosen a totally outdated and old fashioned and out-dated way. There is always a new framework or a new version of an existing one, which promises to solve my problems easier. There sometimes really is a point, where I have to force myself to start solving the solution and stop thinking about the ideal way.
There is one thing, that helps me not to get lost. We have developed a company-framework, which itself is based on a couple of common external frameworks in certain versions. The integrated frameworks are updated from time to time, usually when it is technically necessary. So the first decision is always trying tom solve the problems with the given "tools". There have to be good reasons for updating one of the frameworks or integrating a new one.
thank you for the good comment.
In fact, it's always a good idea to encapsulate third parties through an own abstraction or even an own framework.
What I additionally mean is that the play instinct is very hard to satisfy in a professional development. But it is very necessary to keep it going for a higher motivation in the team. Though it is absolutely reasonable only to upgrade or to migrate when it is absolutely necessary, it demotivates to read about all those cool ways and means to solve the same thing using the most new and seminal technologies, frameworks etc. And the problem is that the new one is always better then the old one (either really or even just told to be so).
In the Java world the rate of change of technologies is that high, so developers just seem to fear the loss of innovation or just of the actuality. This is very hard to manage, and it's always hard to say no to that, so it hurts.
Post a Comment