Only Degrade Your Code Intentionally

June 3, 2006 — Posted by Al Shalloway

I know this sounds like a funny thing to say - only make your code worse when you mean to. But think about the alternative - make your code worse without meaning to!

To explain this, I must mention a concept I heard from Ward Cunningham - code debt. Code debt occurs when you go in and hack something into your system. The next time you come into the system, you have to spend a couple of minutes figuring out why you did it this way, or maybe you know you were hacking, but it still takes a little longer because it isn't clear what you did. Hence, you've increased the debt of your code. Everytime you want to make an improvement, you have to pay a little "interest" before you can get to the improvement. Enough debt and your software is bankrupt - you have to re-write the system.

Now, does this mean that you never put debt into the system? No. There are times you in fact, have to hack something in. However, you should be consciously aware that you are not writing quality code - you should be making a conscious decision that refactoring is required yet isn't taking place. There are (few) good reasons for this. A conference coming up, and I am sure something else.

However, the point is, you should not be writing code without paying attention to whether you are adding debt to your system. If you have to increase the debt, do so knowing there is a compelling reason, or the debt isn't worth worrying about (although it almost always is).

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban