I recently had a conversation with a friend and fellow developer who was very excited. His company recently welcomed a new CIO to the organization, who had some, comparatively, progressive idea. One of his first actions was to increase IT development spending by several million dollars to tackle some projects that had had to be put off over the past few years, including renovating several applications that we’re quite performing up to expectations.
Unfortunately, while the CIO’s spirit was in the right place it became clear that his money was not.
The various development groups began developing applications the way they had always done, but made no effort to update their tools, techniques or practices. Instead of spending part of their substantial investment to introduce things like Agile methodologies, Test Driven Development, Web Standards, Source Control policies or automated builds, they proceeded to develop a whole new collection of applications like they had been developing them for years.
The group knew that these old practices had led them to a lot of pain in the past and needed to be revamped. But the organization placed value on raw lines of code and not the quality of what was being produced. As a result, those applications that needed “renovation” were simply ported from .NET 2.0 (and in some cases 1.1) to 3.5. Management was surprised when “upgrading” these applications did not result in large performance and stability increases.
Making a lot of changes to the way we work as developers can be scary. There’s a lot to learn, it seems complicated at the start, and no one wants to risk looking stupid. But it’s also important for us as individuals and software development in general to be willing to examine and investigate new techniques and tools that will make it easier to develop higher-quality code more efficiently. Keeping an open mind will unlock a lot of doors to improvement.
Companies need to understand that their code is an asset just like a building, vehicle fleet or piece of manufacturing equipment. You wouldn’t dream of letting those things fall into disrepair, so why are companies OK with their code base rot? When making an investment in IT, it’s important to understand where that money is going, and what it’s going to buy you in the long run. If you have a code base of dubious quality and pay for large teams to simply “plough ahead” you will just end up with a larger base of low quality code.
Print | posted on Sunday, August 02, 2009 10:05 AM