Reducing Technical Debt - My code, my responsibility

• Let's get the core functionality implemented and tested first and in later release we can retrofit and concentrate it on quality...
• Coding standards?! But, I always used to write in this way..
• I have already developed 90% of the feature during the spike itself, it is just matter of promoting it to integration...
• We discussed this during code review, but since functionality was working we just avoided to touch the code..
• I was in hurry...
• What difference does it make anyways?
• This piece of code doesn't need to follow the framework, it is a "different" functionality...

Sounds familiar...? Yes, I too have come across this and may other so called "genuine" reasons when I see some features getting dragged for iterations or even PIs (Program Increments) together. Unfortunate, but true.

Now how do we address this? Simple, by educating them on basics, be it "software engineering" practice or basics of agile principles.

Here are some questions to ask ourselves or teams on how do we avoid or reduce technical debt -

• Prevention is better than cure... yes, first step is to prevent it from happening or reduce the possibility of it happening it to maximum extent. Gather the team, architect, SMEs etc. and ask them - How to avoid creating technical debt in first place rather than dealing with it at later stage?
• Does the team understand (and have access to - this is funny but I have to mention it explicity) application framework and coding standards?
• Does my team understands the overall architecture of the system as well have fair idea about enterprise architecture? Is team align and following the same architecture?
• Is there anything already developed that can be reused?
• Is my System Architect collaborating with the team?
• Is System Architect aligned with Enterprise architect?
• Was the estimation done by an individual "bright" member or by the team?
• Do I have good DOD (Definition of Done) in place?
• Is team aware of NFRs (Non Functional Requirements)?
• Is team working on too many user stories in parallel?
• What are the software engineering practice that team follows?
• Was the design reviewed by someone else as well?
• Is my code structured and looks simple or complex to understand?
• Am I applying any design pattern thinking?
• Am I learning from past.. say retros, defects etc?

... and list can go on and on and on... Sometime team or the member involved can be bit in hurry or unaware or even lazy and would cut corners; but reducing technical debt is not a matter of choice, it is "responsibility" and we have to inculcate this habit in the team.

Here are some prevention-cum-cure tips:

• Get the entire team involved - Ensure that team has awareness of system and enterprise level architect - and proposed solution is aligned to the same
• Publish coding standards, guidelines to follow
• Ensure that team is collaborating with architect
• Help team identify the strategy - MBSE(Model Based System Engineering) or Set Based?
• If it is getting overwhelming, dedicate iteration(s) to address technical debt
• Encourage collaborative design
• Identify and suggest best software engineering practice
• Help team to develop a strong a clear and DOD for each delivery unit - be it user  Story, Feature or even Epic 
• Look back, refer to retros, defects past discussion and improve. Identify the defect patterns.
• Keep the WIP (Work In Progress) limits low.
• Plan the code/test coverage (TDD-Test Driven Development, BDD-Behavior Driven Development) better
• Level of automation planned and keeping the automation in sync with development
• Effective and frequent code reviews, preferably reviews of small chunks of code rather than taking it up as a last activity once the feature is developed
• Encouraging design pattern thinking
• Clear understanding of NFRs (load, response time, concurrency, security etc.)
• Simplifying the code rather than making it complex and unstructured
• Promote pair programming and share your insights about good and bad code and promote the learning about preventing the technical debt rather than fixing it later. 

There could be many more... and I welcome readers to add them in comments.

As uncle Bob says -

“Go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills” –Robert C. Martin , president of Object Mentor and agile methods author.