Imagine if at the end of this life you had a new body and a new life ahead of you. Go ahead, try it...
I don’t know what you imagined, but I bet if you kept it up for a while, you might start to think about changes you should make while still in this life.
For instance, that new body could have asthma. Would that thought make you take a serious look at what your current actions do to the air quality for that future you?
In actuality, some people think about long term impacts in terms of what they are leaving for their children and grandchildren. Others think about long term impacts in terms of what they are leaving for society.
But how do we motivate software development organizations to adopt a similar view of the long term impact of what they do?
I’m sure we can agree that the entire organization achieves abundantly more viable code when the looong term view of the code is adopted. So why do so many organizations choose the shortest route to a feature or bug fix—irrespective of the long term impacts?
If you’re in sales, it’s because you know that time to market, happy customers and competitive advantages are essential.
If you’re a developer, maintaining your code might be some other guy’s problem when you move on to another role. But more likely, the pressure to release enhancements on deadline doesn’t leave you any other option.
If you’re management, plastered on enhancements and bug fixes look cheaper than refactoring.
The technical manager succeeds to the degree he or she cultivates a looong-term, multiple-lifetime, legacy-for-the-grandkids view of the code.
It’s the job of the technical manager to bar the door to chronic hacking and to mandate that time be taken to refactor when necessary; to illustrate clearly the long term costs from poor performance, poor scalability, maintenance issues, and so forth; to preach, teach, walk and talk long term sustainability of the code. Soon enough, the rest of the company will get it.