Over complicating things

A few years ago when I wore a younger man clothes, I worked along side some COBOL programmers. They had been in the industry for ever and had seen it, tried it and done it. But still they used COBOL.

At the time Delphi was the best tool for the job, so I spent a lot of my time trying to convince them of this. "That's alright son. We'll stick with COBOL. We know it inside out, and anyway what will we do when the next trick language comes along?"

I would scoff at this, shake my head and go back to my programming.

A couple of years later C# was the best tool for the job, so I spent a lot of my time trying to convince them of this. "That's alright son. We'll stick to COBOL. We know it inside out, it does Windows now, and what will we do when the next trick language comes along?"

I would scoff at this, shake my head and go back to programming.

Now I am learning Ruby/Rails and Objective-C and they are still using COBOL. I no longer work with them, so don't have the opportunity to tell them how great Rails is, but I know their answer already.

What is the point of all this?

Well, over the years the only true constant I have witnessed in the IT industry is a tendancy to over complicate and over engineer projects.

Here is a real life example: A project I worked on once was a ASP.NET intranet Portal application. Different parts of the portal talked to different systems, coming from different places. All of these other systems either published web services, or were developed in house connecting to an in house SQL Server database.
A Biztalk middle layer was introduced to "expose a common middle tier" to the front end.

The real reason was because the Lead Architect of the system was a Biztalk guru. The only thing the Biztalk layer added to the system was an extra layer and slowed it down.

This sort of things happens a lot. Ok, sometimes it's great to build redundancy into the system, but most of the time we over engineer because we want to add another buzzword to our C.V., or find a reason to try out some flash new tech.

These days of agile and iterative processes, surely isn't it better to release for the now, get it out the door and add to it if the business needs change? Builders don't build a mansion when the clients ask for a 2 room apartment, just in case they have kids one day. Why do we?

And anyway, like my COBOL mates would say, no point building a mansion. Something new and whizzy will come along making the mansion look old and tired so it will be bull dozed and started again. Hmmm, maybe they did know what they were talking about after all.