Steve McConnell, CEO and chief software engineer at Construx Software

Technical Debt
Ship Now, Deal With Consequences Later. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt.

Quick and dirty software release, which will require some modification in the future VERSUS the late software release, which has a better design, but will take more time to implement. In development, releasing code as a quick and easy approach is like incurring debt - it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future. Taking the time to refactor the software is equivalent to paying down principal.

Software developers are typically rewarded with bonuses for delivering quickly their assignments. Well this shouldn’t be the problem, but ONLY if quality assurance team and code reviewing team have not done their job well. Creating technical debt and shipping early beta quality software into production subsequently evolves into serious problem.
They are pushed by clients and managers and have incentive to go as fast as possible and therefore often take shortcuts when delivering code. But not all code that apparently works fine is PRODUCTION QUALITY software. However, since everyone is incentivised to keep shipping new features at fast pace, engineering teams won't have any incentive to step up and pay back tech debt.

Tech debt isn't always a bad thing and in The Art of Computer Programming  Donald Knuth claims: “Premature optimization is the root of all evil in programming.”
Knuth's principle was originally is a foundation of the Agile methodologies, applied by so many engineering teams at multinational software companies. To avert the repugnance of premature optimisation is often the correct choice. Your clients, users or stakeholders usually, WILL Blame You even if your intentions were honest. So be careful with the legacy code that has not been reviewed, debugged, and re-factored.


We all understand that often the market dictate terms on how to deal with the legacy code-base.
Thorough examination?
Why someone should play a bad cop and devil’s advocate with a pessimistic attitude. It's part of a quality assurance role. And don't forget to provide Bug Bounty bonus for quality assurance. IT IS AN IMPORTANT INCENTIVE.


Accruing technical debt is unavoidable on any real software project. Sure, you refactor as you go, and incorporate improvements when you can -- but it's impossible to predict exactly how those key decisions you made early on in the project are going to play out. All you can do is roll with the punches, and budget some time into the schedule to periodically pay down your technical debt.

The time you take out of the schedule to make technical debt payments typically doesn't result in anything the customers or users will see.

Steve McConnell, CEO and chief software engineer at Construx Software, has been among those who have led the effort in clarifying the concept of technical debt. In this interview he reflects on the boundaries of the metaphor, its usefulness in bridging communication between technical and business staff, and challenges in managing accumulating debt. From IEEE Software's November/December 2012 issue: http://www.computer.org/csdl/mags/so/...

------------------------------------------------------------------------------------------
Data First
------------------------------------------------------------------------------------------
Quality data sources. Your production data sources, including files, databases, and data feeds, should be high quality assets that are easy to work with. When it comes to data sources of record it is particularly important for them to be of high quality so that they are easy to work with and evolve. Unfortunately this is often little more than fanciful thinking in many organizations. With a Disciplined DevOps mindset teams realize that they should be very careful about increasing the technical debt within their data sources, and more importantly invest in the effort to pay down any technical debt that they find.


------------------------------------------------------------------------------------------
Documentation in advance
------------------------------------------------------------------------------------------
Specification Documentation Must Be Created!
Detailed documentation available on web to everyone must be readable and quickly accessible. It is always better to keep everything in a written form and well documented and open for reviewing like Wikipedia.