A few weeks ago, I reviewed my son’s C code that he and a classmate developed for their college first-year computer science class. The assignment required them to use a linked list to simulate shuffling a deck of cards, finding pairs, and exchanging cards between players.
They struggled to debug their code, and running it produced inconsistent results and null pointer exceptions.
So here I was, looking at C code with long procedures and hard-to-follow naming conventions. There was no logging, error checking, or code-level documentation. They had never heard of log files, but they assured me they would document the code before submitting the assignment.
My initial thought was, “Jeez, no wonder we’re still creating mounds of technical debt in our code.” Why weren’t professors teaching engineering students basic coding practices before getting into more complex data structures and algorithm design?
What is technical debt
Alas, it brought me back to chapter 2 of Digital Trailblazer, where I talk about the tech debt meaning in digital transformation, my stories of developing spaghetti code, and how technical debt is now your problem. Because as engineers graduate from hands-on roles to team leads, delivery managers, and transformation leaders, they have to take ownership of the growing tech debt problem in their organization.
Here’s what I say in the book:
Bad code comes in many flavors, sizes, and impacts. And every time I walk into a new job or am involved in acquiring a company with proprietary software, I open my nostrils to sniff out where the code smells bad and what impact it’s causing.
Bad code signals tech debt agile and scrum teams
And in the author interview series with Ginny Holden, I answered her question about what bad code smells like, a term used by many dev teams. My agile teams used it whenever they wanted to alert me about technical debt, and when the coding issues became so bad, here’s what it smelled like:
Bad code smells like rotten cheese. It’s like when you open the refrigerator and get that faint smell of stinky cheese going bad. Your instinctive reaction is to close the door– I don’t want to have anything to do with this problem, and you leave it for your housemate or roommate to deal with it. But of course, they don’t touch it, and so that cheese just gets worse and worse. Now the whole house smells bad, and you don’t know where it’s coming from, and a small problem gets harder to find and fix.
I can envision developing tech debt metrics that equate the magnitude of the business impact with a rotten cheese descriptor. Maybe funky, rancid, rotting, reeking, and putrid. So if the scrum team must refactor poorly written code to develop a new feature, the code may be rancid. But if that code is causing performance problems, then it’s reeking, and if there are known security holes with it, then I’d call it putrid.
You can watch more in the two videos about Chapter 2 embedded below. In the first episode, I get in the weeds on how Digital Trailblazers must prioritize which areas of tech debt to fix. In the second video, I discuss communicating and partnering with product managers and stakeholders on fixing tech debt.
The two videos are available on the Driving Digital Standup videocast. You can get early access to the full video series by signing up for the Digital Trailblazer Community. Community members also get access to chapter-by-chapter reading lists, a career checklist, and a copy of my vision statement template.
Leave a Reply