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.