.jpg)
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.
.jpg){kind=link}