Writing code for today and tommorow

Writing code for today and tomorrow

Any developer working at a pace that will allow them to stay employed creates bugs. Testers get excited about a lot of different bugs. Testers should be lobbying for fixes that will have the biggest impact on the software. Teams don’t always agree on what those things are. Think about how the bugs you are fixing (or not) will impact you down the road.

Old code never dies

Computer code feels like it has a short lifetime. However this just isn’t the case. The code you worked on five or ten years ago may be old news in your mind. However, most production code written that long ago is still alive in one form or another. It’s extremely expensive to re-write from scratch. Working code is really hard to throw away. Remember a ton of COBOL programs that had to be updated for the year 2000. Computer code has a way of living a long life.

Maintainability

Maintainability is more than just a development concern. If your team uses visual studio you can get a maintainability index (from 0 to 100) for all the code in your project. You should try it sometime. If your code isn’t averaging at least 80 chances are you have some issues at a low level. Keeping these numbers high pays dividends for the lifetime of the code. Don’t be pedantic about those numbers. Some code is actually better in a “complex” form. 10% of your code can have a free pass to go as low as 40 on the Visual Studio maintainability index. Keeping your code maintainable will pay off for years and years, maybe even decades.

Sustained Engineering

The original author usually has the luxury of handing off code they wrote after the release. There are some good business reasons for this. However, code that’s hard to fix and update will come back to haunt you. I have seen projects drug into the mud when they constantly had to deal with customer “escalations” because no one but the original authors could maintain the code. The first release was out the door in short order, but the cost to the company and the project lasted for years and years.

The cost of repaving the road

You can’t anticipate which parts of your project are going to have to be overhauled in three years. Computers will get faster, but users will demand more out of them. A lot of applications continue to scale just by migrating to better infrastructure. However, at some point software projects need to be overhauled or re-written. Make sure you fix your issues that cause your software to be tightly coupled. That way in three years you can yank out the one bad part and put in a new fancy one. If your project is still tightly coupled, it won’t be able to be updated and it will die a premature death.

Customers aren’t the only customers

When you evaluate which bugs to fix, you should think about the customers. You just have to remember that the person sitting behind the desk using your application isn’t the only customer. Think carefully before you choose to fix a bug that only a small number of users will ever see over improving maintainability or leaving backend hacks in place

You have a responsibility to your first customer, the company who writes your paycheck. You have a responsibility to the “customers” who will maintain your work when you move on. Finally you have a responsibility to customers who will be using some version of your product years from now. Make sure all your customers are feeling the love.