Technical Debt and Legacy Solutions
The best I’ve seen to-date on coping with spaghetti wiring harnesses or spaghetti code, or any legacy tangled up technical debt in hardware or software, is pasted below from an email exchange earlier this week. To set the stage, the working definition of Technical Debt for non-software or software I use is currently: Anything that reduces the cost to make change. This is typically poorly architected solutions, difficult to understand solutions, and brittle solutions that we put in as a quick-win or test. In order to speed back up the pace of new development (change) they need to be replaced with more durable, elegant solutions that are comfortable to build upon, easy to test or self testing, and easy to swap in and out.
For coping with technical debt, I’ve seen teams have regular improvements without getting overwhelmed or missing the new feature dev by “refactoring in place”. I’m a big fan now. They pulled this off by making sure whatever area of the code (or in hardware or other work, that module of the solution or service) was refactored and made compliant with elegant architecture and their current definition of done. That meant as they developed new awesome, they improved the code base a section at a time. By ramping up the pace of new development they even ramped up the pace of beautifying the legacy solution. That gets my respect and applause.