Hello everyone,
https://dev.to/6figuredev/episode-207-tech-debt-vs-cruft
This podcast in particular talks about technical debt in detail, as well as how to handle it. It introduced me to a term I had never head before called Cruft. Cruft being not traditional technical debt but specifically a type of debt where the developer who wrote the code did not make the effort to make the code clean and or work well. I never made the distinction in my own mind as to consider the possibility that the lack of best practices or simply writing the code wrong could be considered as that type of technical debt.
Now I don’t mean the developer was malicious or perhaps lazy, while it could be considered a possibility it seems to be not a scenario that happens enough to be something that requires a term like that. I also like having that extra terminology as technical debt as a definition can be left to an intentional design choice that leads to the creation of technical debt that most times are made in consensus rather than specifically one user not knowing how to code it or that user writing poorly designed code.
Cruft also gives a more specific term for a business to focus more on as it has the greater debt value for the company when needing to rework your product. If the code is rushed and written poorly, when errors arise the pressure is greater on the development team and will lead to failure or delays.
With Cruft as the core of that perspective on technical debt, regular technical debt can be just the debt that was planned and agreed upon allowing you to release and work on it later.
This podcast also introduced me to another great term that is separate to legacy code. With legacy code it’s old enough that it doesn’t meet the definition of Code Rot. Code Rot isn’t keeping up with older code so old as to be legacy code, but code that hasn’t been touched in a while and isn’t kept up to date with the newer builds and similar code design.
From this podcast it gave me an interesting mindset when thinking about a production cycle and acknowledging technical debt as kind of being inevitable and something to try to plan before sprints as apart of the team and being prepared for it. Cruft is really what I thought technical debt to actually be, because I was only really reflecting on code being written by one person. I for some reason ignored the aspect of working on the development team and it has changed my idea of development. Cruft really is just a more personal or workspace issue. One being fighting against the urge to take the easy way out and the other being a pressure outside what I as a developer couldn’t control but rather a business forcing the cruft to occur by forcing shortened deadlines.
From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.