Should Engineering Compensation Be Tied To The Long Term Success Of Code?
One thing which has always troubled me about the software projects I’ve worked on is that the people who write the code at the beginning rarely have to live with it years down the road when it becomes someone else’s problem. This has led me to wonder if there shouldn’t be incentives to ensure that code is built in a sustainable fashion to a high quality? Instead of just paying developers for delivering functionality and meeting initial sign-off criterion, perhaps compensation should also be based on how many bugs are found over the years, and how difficult is it to maintain the code 5 or 10 years later.
During my career at Microsoft I would see engineers richly rewarded for completing projects on schedule, and “shipping” products. It was always someone else’s problem when it was discovered that some code was written in such a way that it cost millions to make an update 6 to 8 years later. There were many occasions when I dreamed I could have retroactively clawed back income from engineers for having created a rat’s nest for me to deal with a decade later.
Likewise, elegant code which was easy to update years after the fact made me want to hug the original engineer. In fact, I took at least one such developer to lunch once just to thank him for how well he had done his job years before.
The reality is that software lives for a LONG time and the days in which we should just use a short-term perspective to get something out the door as fast as possible are over. Every developer ought to be asking themselves how the code they write today will be serviced in the years ahead. Is the code being written in a modular fashion, making it easy to just change one component without impacting everything else? Is the software being instrumented to make it easy to understand what is happening?
It’s not just a matter of writing extensive comments. If your code is a tangle of spaghetti that requires whole portions of the software be utterly rewritten to make a small change then it will cause nothing but heart-ache to future engineers. I have seen cases where just recompiling a .DLL file resulted in breaking applications because another component was tying directly into the memory registers.
An increasing number of companies pay lip service to building quality code. Microsoft, for example, educates developers on best practices and requires code reviews. Unfortunately, I don’t think this is sufficient to ensure software is written from a sustainable viewpoint. Even the people doing the code reviews have incentive to just get the product shipped. Even with the best reviews, and recommended engineering principles, we continue to see products ship which are a nightmare to maintain.
Do you think that developers should be rewarded, or punished, for the success of their software over the long term?
SEP Chief Evangelist