Last Friday when I went to buy some food I saw two guys working on an old Ford Capri (like this one, although in red). It was from 1972 and one of the guys told that he is still the first owner.
We began to talk a little and the other guy - about to repair something - told that in two hours it's will be done although some bigger change. When I mentioned that with the modern cars it is not always that easy he got red, agitated and began to badmouth (I was worrying if there will fly tools in a few seconds) about the modern cars. He told that he worked on a newer car some days ago where it took two hours only to remove the parts so that he could get to the main part he wanted to change or repair.
I know it from my own experience, that in newer cars sometimes it is either very difficult to change a headlight yourself.
Well, this is an IT blog so why the hell I am writing about cars here?
The answer is simple: I think that in IT similar changes happened. While software and either programming languages get packed with a lot of features the basic purpose often suffers.
Example: Many years ago it was sufficient to copy an executable (and maybe some configuration or data files) to a destination folder. Nowadays special tools for setup creation must be used (and either programs in their particular language must be written - the program for the program) and then it is not sure that everything works fine then. And it is possible that you need additional runtimes in addition to the setup (some setups for .NET applications for instance).
And then applications often need very huge amounts of space - memory and harddisk. I had the MS Visual Studio 2005 installed which used more than 2 GB (!!!) on my harddisk.
Or to mention the libraries and technologies in Java: Spring, Hibernate and all those "frameworks" - there might be a reason to use these in very large applications or projects, but I guess in 75 % of the projects using too much of that stuff only produces bloatware without a real benefit. I have been on a course for Alfresco API and one of the major impressions was that 75 % of the time we were struggling around with XML files and only 25 % with coding.
It often seems that IT is very far from applying the KISS principle, hence I strongly recommend reminding to it. Try to keep it simple. IT is already complicated enough even if you keep it simple!
Related posts: The good, the bad and the ugly; The Features.
7 comments:
Hi Martin,
You give an interesting opinion, but I tend to disagree with you on those "frameworks" producing more bloatware than benefit.
Once you set up a project, yes - initially you will spend some time playing with XML configurations. But once everything is set up, your life is made so much easier! You can really concentrate on the task at hand, would you agree?
You are mentioning an interesting point: "Once everything is set up, your life is made so much easier" - Maybe there are some frameworks to which this applies.
From what I have seen so far I didn't have that impression that it is a one-time work - because of many applications being customizable and hence you have to manipulate also the configuration files again and again.
Besides that - as much configuration has to be done by hand I would prefer another format like YAML or JSON for instance which is easier to write than XML if you do it by hand.
However, I notice that in my applications there is also often a lot of configuration to be done - especially for server applications and in addition to that also a lot of scripting. So anyway configuration work is mostly necessary.
But I think nowadays technologies often get used in the wrong places or in an exaggerated mode. For instance: Why use SOAP and other complicated protocols when a simple client-server transfer through whatever port of a simple and short YAML data block would do the job perfectly.
The problem often is that one technology uses the other and on top they built another protocol and then we have some library then some framework and ... and ...
I had a discussion with somebody else who told me that in many cases people exaggerate the use of "frameworks" and libraries. There must be a match of the project size with the used technologies.
Hi Martin,
I agree with you that sometimes people use frameworks, when there is no real need. I think it is happening due to lack of experience.
I think, as a designer/architect you should use technology/framework that will do the job in the most efficient way, taking into account consequences on the long run and possible future enhancements.
You mentioned that often people exaggerate, which is fair enough. But then how can you tell where is the limit? How can you tell whether you exaggerate or not when you design your application?
Lets say you designing client-server application. In your application you have several entity beans.
As a designer, you made a choice to use Hibernate (I am not a Hibernate fanatic, its just an example :) ), as your persistence layer. So, in this case - did you exaggerated or not?
You are right, it is often not easy to say where the limits are and the question if exaggeration occurs or not is mostly not that easy to answer.
You made me considering another fact: In many cases you might plan one thing but in the end it evolves completely different. So planning is one thing but reality is often another.
I think this is the reason why many programmers just use the things that are used already elsewhere and known to be working - and those frameworks which are so flexible that everything can be changed later.
This is similar as many consultants just recommend to use Microsoft products because nobody can then say the recommended complete stuff because it is a market leader.
People often prefer the "sure" way instead of trying something that differs from the main stream.
My original post was quoted here: Java and those frameworks - so please see also the comments there (javabeans.asia)
A related article can be found at "Joel on software":
Why I Hate Frameworks
Same happen here. 90% of our task is doing configuration. and only 10% of that is the actual coding. Sometimes I found it sooooo boring :).
But I somehow believe that once you know the configuration matter, things will go on smoothly the next time you do it.
Post a Comment