Test Double Icon

Test Double

Great software is made by great teams. We build both.
testdouble.com • 4 Stories
All Sources

Test Double Icon Test Double

Understanding the Law of Demeter

I almost brought up the Law of Demeter on Go Time a couple weeks back:

That being said, sometimes you just have to follow the other person’s path until you realize when it doesn’t actually work for you. I’m totally fine with cargo-culting some sort of rule… I was gonna say the Law of Demeter, but that one’s too hard to explain. What’s a very simple – DRY, right?

See how quickly I abandoned ship there? Ok, it’s not that hard to explain. I just didn’t feel like taking the time to explain it when it wasn’t even my point. Good thing Double Agent Caleb Hearth did a nice write-up on Test Double’s blog about it!

Test Double Icon Test Double

Stop paying tech debts, start maintaining code

Jesse O’Brien from Test Double wants us to stop using the term “Tech Debt”

There’s loads of reasons why unmaintainable code ends up running in the systems our products are built on, but none of these fit the definition of debt.

Instead, I propose we drop the term Tech Debt and start talking about maintenance tasks. Maintenance is what we’re really talking about. When parts on our car or bicycle suffers wear from driving them around, we don’t talk to our mechanic about “mechanical debt”. (Go back and re-read that sentence, but replace things with “software” and “programmers”). We talk about maintenance.

This post starts as mostly a semantic debate, and I’m not convinced by his arguments there. I think the debt metaphor is useful when you’re talking about trading quality for speed. That’s what you do when you take on debt: you trade higher cost at a future date (principle + interest) to gain access to the money today (speed).

That being said, I really like where Jesse ends this piece talking about software maintenance and methods of going about it. Lots of actionable advice there and I’m 100% onboard with talking about software maintenance early and often. One of the first things I consider when somebody approaches me with a feature idea is ask myself: what will this cost to maintain?

Test Double Icon Test Double

Deconstructing the bike shed

A thought-provoking piece by Joshua Wehner on Test Double’s blog:

For the metaphor to work, at all, we have to have a shared understanding of what’s important and what’s trivial. Kamp is saying (1) color does not matter, and (2) the topic they are debating matters as little as if they were debating color.

For decades, software developers have been fine with this. And yet… Color is an amazingly deep topic! There are books on the history of color. There are fascinating stories about how colors got their names, how they were made, how they impact fashion, how they tell stories… until software emits smells, color will be one of the most important aspects for developers to understand when considering how human beings will interact with our software.

I never thought that color doesn’t matter, just that for the purpose of the metaphor color doesn’t matter in the context of a bike shed. This thought leads Joshua to another one:

Software developers—and other professionals who are oriented around quantitative thinking—have a tendency to dismiss more qualitative disciplines such as design, marketing, or management—which also turn out to be exactly the disciplines best-suited to mitigating the kinds of dead-end discussions the bike shed legend is supposedly built to address.

This I’ve 💯% seen in the wild.

In conference rooms and in online discussions, I frequently seen software developers deploy the bike shed myth as an attempt to minimize a topic they see as unimportant and to label that discussion as a trivial distraction.

I need to stop or I’ll end up quoting the entire article. Like I said, lots of thoughts being provoked here. A must-read, even if you end up disagreeing with his conclusions.

0:00 / 0:00