jbrains.ca

Playing Well With Others: An Example

Wed, 15 Apr 2026 00:00:00 -0300

[I]f an application meets expectations and passes all external tests (functional and quality), should one care what’s inside? Development would consist of coming up with those tests: TDD

— Ken Pugh, in a comment on LinkedIn

I love comments such as these, because even though they are short, they act as a rich source of practice in various aspects of what I affectionately call “Playing Well With Others”. Analyzing comments such as these along with my immediate response to them helps me both understand and more-effectively use the various principles that form the basis of how I Play Well (at least Better) With Others.

TL;DR

Let me list the ideas, principles, guidelines, and practices I used to think about this comment:

The Law of Generous Interpretation
The powerful question template “What would have to be true for me to…?”
The Satir Interaction Model, also known as The Ingredients of An Interaction, notably the Interpretation part
Betteridge’s Law of Headlines
The risks of Best Practices thinking
The risks associated with the word “should”
Transforming Survival Rules Into Guides
Bringing assumptions to the surface in order to challenge them

That’s a lot! It’s a lot to do, to remember, to learn. I didn’t learn it all at once and I needed years to practise it all confidently and effectively. Would you like help learning and practising? because I know a guy.

Back To the Comment

Let me analyze the comment for a moment:

It seems like a rhetorical question, so I can interpret it as a statement, and using Betteridge’s Law, the answer is probably “no”.
It tries to identify a simple rule to govern complex behavior. Some folks would interpret this as a firm rule that one must always follow; others would interpret this as a guideline that one ought to keep in mind, but freely break.
It seems to promote a Best Practice, which always makes me nervous.
The word “should” raises many alarms.
The indirect statement “One should never care…” almost always stands in for the much more personal statement “I would rather never care…”.

That’s a lot for just a short comment!

Based on my analysis, the statement seems more like this:

“If an application meets expectations and passes all external tests, both functional and quality, then I would rather never care about what’s inside. I would focus instead on coming up with those tests, which I do when I practise TDD.”

This starts to sound more like a statement I could easily agree with, rather than a statement that I would quickly and easily tear apart. That sounds like progress to me towards Playing Well With Others.

The Statement Itself

When someone proposes an absolute rule, I tend to ask about the situations in which I would break the rule. When someone proposes an absolute rule with assumptions, I tend to challenge the assumptions or, at least, ask what would make those assumptions false. Let me try that here.

“An application meets expectations and passes all external tests, both functional and quality.”

I mean… it could happen. I guess it sometimes happens. Whose expectations? The “people who matter”, I suppose, whoever they are in the organization where we might apply this rule.

I get nervous when folks present these as binary assumptions/outcomes, but I can usually safely interpret that as shorthand for something closer to reality:

“An application meets the expectations of the people who matter well enough for their purposes and passes all external tests, both functional and quality.”

I note that the second part of this assumption contains evidence of the first part: I imagine that those tests include tests that encode some of the expectations of the people who matter. I feel confident that there are some Programmer Tests in there, too. Let me tweak the comment to make this relationship clearer.

“An application meets the expectations of the people who matter well enough for their purposes, as evidenced by passing all external tests, both functional and quality.”

I like that. Now: when faced with such an application, when would I care about what’s inside?

A Magic Question

What would have to be true for me to care about what’s inside an application that meets the expectations of the people who matter well enough for their purposes, as evidenced by passing all external tests, both functional and quality?

I don’t understand the tests well enough.
Even if I understand individual tests well enough, I don’t understand well enough how the tests work together to describe the system so that I can build a workable mental model of it.
I don’t have enough confidence in the tests being exhaustive enough to specify a system that does what we (the entire project community, customer base, and user base) need it to do.
I’m curious about what’s inside.
I want to build a similar application.
I want to extract reusable/recombinable components from it.
It’s often easier to build the system than to specify it with examples.
It is theoretically impossible to specify everything I care about a system from a combination of example-based tests and property-based tests.

I don’t consider this list complete, but I only thought about it for a few minutes. This provides enough to continue.

I judge some of these reasons as arbitrary and personal, such as my curiosity. I judge some of them as perhaps begging the question. For example, wanting to build a similar application: if I can regenerate this application from its tests, then presumably I also have the tools to generate a new application from similar tests. I judge some of these reasons as true, but useless. For example, it’s theoretically impossible to specify a system completely through tests, but we can usually get close enough to drive the risk down far enough for our purposes. None of this makes these reasons bad or pointless, but it merely reminds us that these reasons are not enough on their own to answer a clear “yes” or “no” to Ken’s opinion.

The question “What would have to be true (for me to behave (like that))?” engages my creativity to look for unspoken assumptions about the context, so that I can speak them, pay attention to them, and not become blindsided by being wrong about them. I find this question particularly powerful as a result.

For example: sometimes I’m just curious about what’s inside. I feel better when I retain the option to look and the skill to at least try to understand. Why not? I mean… you could pay me not to ask, but you don’t have enough money to make me not wonder.

The Claim Behind the Claim

Roughly speaking, I think Ken is claiming something like this:

“If you practise TDD, then you have the option to stop caring about what’s inside the application, as long as it passes all its tests and you have written tests that specify everything that the project community cares about.”

I’m taking liberties now, so I might have missed something important. Let me know. I tried to paraphrase and infer faithfully, interpreting generously.

Even in this form, I can’t quite agree, and for one key reason: it’s not theoretically possible to specify everything that the project community cares about through tests. We have been thinking about this for decades now: if we have tests, can we simply throw the production code away and rewrite it from scratch? Is this possible even in principle?

No.

We could get arbitrarily close, but then we would have another problem: eventually it would become “too expensive” to write those tests, even when we knew exactly what to write. I see two possibilities:

It would not be worth the effort, even if we did it perfectly correctly, or

It would become at least as difficult as writing the code. Getting the tests wrong would become as likely getting the production code wrong.

We would then need something like TDD to help us write the tests. The tests would become a new kind of production code, and we would end up back where we are now.

And all that ignores the fact that (some, many!) programmers (still) like to program (even though the industry seems to be trying very hard to stamp that out of them). Many of them would want to look inside; they would be curious.

Why Go Through All This?!

…over a LinkedIn comment? Rly?

Rly.

This feels so much better than merely telling Ken that he’s wrong in public. For twelve reasons, maybe fifteen.

I mean, what he wrote is wrong on its face, but there is true and helpful content in there. I prefer to focus on that part. Doing this makes me feel a lot better and makes me a lot more enjoyable to work with and to be around.

That’s my gift to you.

When You Can Safely Leave Sprints Behind

Mon, 13 Apr 2026 00:00:00 -0300

Two-week sprints are dead. I think Agile is dead, too. — Charles Fry in a post on LinkedIn

This doesn’t surprise me. When I first saw “Naked Planning”¹, I guessed that “weekly planning” or “iterations” or “sprints” would be among the first of the various Agile rituals for functioning workgroups to leave behind.² If we talk daily and release frequently, then there is no need to let an iteration be 2-4 weeks long, nor even a week!

Even so, I never quite bought the whole “sprints are dumb/waste” meme. Just because you don’t need it, doesn’t mean nobody needs it. Just because you aren’t making good use of it doesn’t mean that nobody makes good use of it. 🤷

When Iterations/Sprints Help

If your group needs to establish heartbeat-type habits, then you’d probably benefit from iterations/sprints as a way to build those habits. Habits such as:

replanning as you learn about your group’s capacity to deliver
talking to each other throughout the day or throughout the week
reviewing each other’s work more often than merely when you think it’s ready to publish
showing partially-completed features to stakeholders to check that you’re on the right track

Once you have these habits, you might find timebox iterations superfluous. You might even find that they hold you back!

If your group needs to establish the habit of actually shipping features, rather than merely making progress on them indefinitely until someone gets tired and gives in, then you’d probably benefit iterations/sprints as a way to focus on finishing work. Of course, WIP limits can also do this job, but I like letting 10000 flowers bloom. Once you have this habit, you probably don’t need an arbitrary deadline to remind you to ship something.

Do you need iterations/sprints? Maybe.

I think it’s slightly better to do them and not need them than to need them and not do them. Even so, I sometimes help groups realize that they have the habits they need under their fingers and can stop waiting until the end of the month or a 4-week boundary to run their retrospective and update their planning boards.

Arlo Belshee introduced me to this idea in the early 2000s and you’d likely recognize it today as the Kanban Method: WIP limits, visualization, and a single “express lane” for expediting urgent, unplanned work. One item at a time fits in the express lane.↩︎
Similarly, if you actually talk to each other daily, then do you really need retrospectives? And if you actually talk to each other throughoout the day, then do you really need the Daily Standup? Maybe and maybe.↩︎

Your Inbox As Options, Not Obligations

Mon, 23 Mar 2026 00:00:00 -0300

I’ve heard this many times over the years:

… getting everything out of your head into a million projects and tasks feels like you are asked to do a little of everything.

https://bsky.app/profile/deejaygraham.bsky.social/post/3mfu3lh7oe22n

This leads to conclusions that I don’t share, such as “Getting Things Done pushes people towards multitasking [and I agree that multitasking is generally a mistake]”. I understand how reaching this conclusion can sour a person on Getting Things Done, but I see that conclusion as both a pity and avoidable.

The Apparent Moral Goodness of Never Saying “No”

You might have been conditioned to do (maybe literally) whatever people ask you to do. Some well-meaning adults might have taught you to do this when you were too young to question it. They taught you the virtues of helping, of being of service, of doing for others what you hope they would do for you when you needed it. Entire populations are taught the undeniable moral goodness of behaving this way. Religion aside, all this generally guides young people to become helpful, reliable members of society.

Sadly, it also risks teaching young people that they can’t say “No”. They grow up with a vague, unexplained, visceral, undeniable aversion to rejecting people’s requests to do things for them. They feel over-responsible for disappointing people, so they keep committing to more and more and more. And this becomes why they need a system such as Getting Things Done in the first place!

Folks struggling with Too Much To Do and Constantly Disappointing Everyone (Especially Themselves!) have a big, messy Inbox in their head: a master list of things they need to figure out when they’re going to do. Some of them also have some structure in their mind resembling Projects and Next Actions. Mostly, however, they have a jumble of too many tasks that they are constantly expediting and constantly forgetting and rediscovering. It feels really painful. It saps their energy. It sends them back to bed. Or worse.

Along comes Getting Things Done, which encourages them to start by bringing order to the chaos: write everything down and put it in The Inbox. Gather everything into The Inbox. Once you’ve got things safely in The Inbox, you can begin to figure out what you’ll do when, in what order: how you’ll manage to follow through on your commitments. It claims that this is a path to no longer having deadlines sneak up on them. It helps them stop letting important tasks fall through the cracks until they become urgent (and expensive!). It allows them to forget safely, so that they can focus on one thing at a time until, almost like magic, things are routinely getting done.

Sadly, it also risks freaking them out when they realize just how much they’ve committed to doing. And since The Universe keeps asking them to do things, they see The Inbox growing and growing and growing. The more they work The System, the farther behind they fall! They conclude that Getting Things Done hasn’t worked.

If you’re in this situation, or worried about this becoming your future, I have a proposal for you!

Options, Not Obligations

When you look at The Inbox and your Projects and Next Actions, what do you see? I suspect you see long lists of commitments, stretching as far as the eye can see. Commitments. Future Broken Promises. Obligations.

Guess what? You can choose.

It probably doesn’t feel like it, but you can choose. Over time, you can learn to see what’s in your Trusted System as options, not obligations. I suggest you start with The Inbox.

Detour: Software Development and Backlogs

In the world of software development, they talk often about Backlogs as a fundamental tool of planning. They have Product Backlogs (what we have to do in order to ship the product) and Iteration Backlogs (what we have to do in order to declare victory over the next 2 weeks or month). They probably have other kinds of Backlogs that they didn’t even read about in a book. These Backlogs are glorified, vaunted, revered, and feared shared “to do” lists. The details don’t matter much for this discussion, it might shock you to learn that these Backlogs are a source of significant confusion, debate, and dysfunction in the world of professional software development. I help clients with these problems. Many of those problems are problems of their own creation. (No shade; just facts. The struggle is real.)

Just like you and seeing The Inbox as frightening, painful obligations.

One big problem for software development professionals is that they see the Backlog as an immutable list of commitments. Once they put items in their various Backlogs, negotiation stops. They don’t adjust the plan to match emerging reality, such as workers quitting, getting sick, or going on vacation. Or learning that this key feature that we bet on is not going to sell. Or learning that that key feature is going to take 4 times as long to build as everyone thought, because technology. In professional software development, they cling to the misguided notion that they first plan, then they execute the plan, then they profit. In this environment, they turn Backlogs into immutable plans. Backlogs become constant reminders that they’ve bitten off more than they can chew. They feel like prisons.

Software development professionals use some of the tools of planning, but they forget to plan: to adjust their expectations as they encounter unpleasant surprises, to change their minds as they find out that their plan isn’t going to work, to react to the changing personnel and cash flows and market pressures.

This Is Not About Software Development

Maybe you do this, too. You intend to volunteer at your child’s school, but then you find out that it takes 3 times as much time and energy to do as you’d expected, and now you’re stuck. You tried to clean the garage last weekend, but once you started, you found out that it would cost way too much money to haul away all the stuff you wanted to donate and you didn’t have the heart to throw it all into a landfill, so you gave up. You keep staring at the piano, imagining how much fun it would be to play for an hour (or two!), but then you see the stack of papers on your desk and can’t justify the self-indulgence. And somehow you don’t take care of the papers, either. Who has the strength? I’ll watch a movie instead.

Stop the world. I want to get off!

Ceci N’est Pas Un Backlog

I propose you start here: The Inbox is Not a Backlog.

Instead of treating The Inbox like a list of commitments, treat it as a list of options: ideas, possibilities, things to reconsider later, idle thoughts to spend 10 minutes thinking more deeply about on Friday, potentialities… but not obligations. You need to make it safe in your own mind to put things in The Inbox without assuming that you actually have to do them!

I tell my software development clients to do this, but they often struggle, because there are many people in their project community, each with their own needs. They have competing objectives. They have differing philosophies. They care about different things. Any change to their working environment requires consent and getting that consent takes effort. Some people simply don’t feel ready to try to treat their Backlogs as anything less than obligations to do things under threat of losing their job. And, you know, their managers and executives routinely remind them about this threat every week!

You have an advantage: it’s just you in there! You can choose. You can experiment with making it safe to see The Inbox as options, not obligations. Nobody else can see inside your head. You can try and fail and try and fail and try fail until you suddenly succeed. Until you feel the click. Until you start seeing The Inbox as a collection of options, not obligations.

Feeling Safe in The Inbox

When you see The Inbox as options instead of obligations, it becomes safe to capture everything in The Inbox. You’re not going to do it all, anyway. You can’t. You don’t have enough time, energy, and money to do it all. You’re going to have more ideas and you need the freedom to sit and think about them. To mull them over, even when you’re not in the shower. You’re going to need to negotiate with The Universe regarding what you can reasonably commit to and what you can’t. You’re going to need to make room for doing things for yourself, because if you don’t, then you will run entirely out of energy and everything will stop! (We call this “burnout” and even “depression”.)

When you make The Inbox a safe place to capture every little idea, these big things happen:

You let yourself have ideas without fear of having to do anything with them. Your creativity kicks into high gear—or at least springs back to life.
You build a daily practise of scratching tasks off your list. You literally practise saying “No” to The Universe, but inside your own mind, where it’s safe because they can’t hear you and you don’t have face their disappointment. You can build confidence in your “No”, so that you can say it when you need to say it.
You focus more deeply and fully on the tasks you actually do, so you complete them sooner and with more energy. Sometimes you even have fun doing them!
You do more of the things you want to do and fewer of the things that you don’t. (No, really!)
You feel more confident in the commitments you keep, because you have increasingly clear evidence of what you can do and what you can’t do, of what you have space to do and what you don’t. You become the reliable, helpful person that those well-meaning (or maybe not) adults taught you to become.

As the saying goes, if you can’t say “No”, then your “Yes” means nothing. I prefer to say this:

Once you make peace with saying “No” to folks, you recapture the purest joy that comes from being able to say “Yes!” and meaning it.

And that starts with seeing The Inbox as full of options, not obligations. You can choose.

Getting Started

Spend 10 minutes with some paper and a pen and write all your uncompleted tasks (and projects) down. Just write. Write down anything you’re worried about forgetting. Don’t edit anything yet; just write. Write down the things you’ve always wanted to do, but never found time to do. Write it all down and don’t read any of it. Write down all the little things, too. The obvious things. The mundane, everyday things. Just write. This is The Inbox.

How do you feel now?

Once you have The Inbox, you can decide what to do with those items: scratch some off, put some deadlines or appointments on your calendar, set a reminder for Friday to spend 20 minutes thinking more about That Project You Maybe Want To Do, and then pick some things that you’ve already committed to, or that you want to get out of the way, or that you genuinely want to do today. (What? Meeting my own needs? In this economy?!)

Now put The Inbox away. You don’t ever have to look at it again, unless you want to spend more time processing it. Maybe what you’ve done now is enough to clarify what you need to today, for the rest of the week, and to begin next week. Maybe on Monday you can spend 10 minutes with some paper and pen and do this all again.

This is enough to get started. You’re doing Getting Things Done! It’s happening!

At some point, rewriting The inbox every Monday is going to become annoying. Or you might need to do it more often. Or less often. This means you’re ready for the next trick. Maybe then you have the energy to read the book. Or to come back here for the next trick. Or to send me a complaint or ask me a question, so that I can write about it.

Epilogue, or Future Work

Once you feel comfortable seeing The Inbox as options, not obligations, then you can imagine seeing your Projects and Next Actions as merely options, not obligations. (🤯?)

Gabor Maté, The Myth of Normal. Very young brains seem to behave a lot like adult brains in a hypnotic trance. If this is true, then you were literally hypnotized to believe what adults told you when you were a small child. This would explain why those Survival Rules seem automatic and impossible to ignore!

Deadlines As An Act Of Love

Fri, 20 Feb 2026 00:00:00 -0400

When you think of deadlines you likely think of deadline pressure. Most business environments make deadline pressure part of their culture. Moreover, as we talk more about folks having difficulties with executive function, we have become more aware of the challenges they have with deadlines, resulting in more acceptance but also more stigma. Given all this, the larger We has a complicated relationship with deadlines.

Fortunately, we have the chance to reframe this situation to make all this work more with us than against us. Join me!

I propose deadlines as an act of love. (I’ve made this sound saccharine and grandiose on purpose, so that you might remember it, but I also genuinely believe it to be true.) You might resist this and see deadlines as an attempt to control, a way for some folks to exert power over others, as an imposition on others’ time on one side of the transaction or as an unfair demand on the other side. Let’s reject all that!

(I mean, yes: some folks will try to wield deadlines as a weapon, but we don’t have to optimize for those folks, even if our financial situation might require us to tolerate and even accept them.)

I want people to give me clear deadlines for some straightforward reasons:

A deadline allows me to schedule my work.
A deadline allows me to judge reasonably accurately whether I can fulfill their request or not.
A deadline helps me infer something about how the requester sees the urgency of a request, if that’s not already clear.
A deadline helps me decide whether I can accept the cost of missing the deadline as compared to the cost of hitting it.

Framing the situation this way, people are doing me a favor by giving me a clear deadline!

I want to give other people clear deadlines because I want to give them the same clarity they give me. We can really decide to let it be that simple.

Beyond this, I can refer to the mounting experience of folks with executive function difficulties who need and even embrace the controled motivation associated with deadlines in order to actually get around to the task I’m asking them to do. This seems especially true when I’m asking them to do something that they would not otherwise do spontaneously, voluntarily, and happily.

In order for this to work, however, we need to reframe deadlines more generally.

I propose that we treat deadlines as statements of value or vulnerability about constraints, not as demands. The more of us who agree to do this, the better the whole system works, and the more harmoniously we can work and live together. You might notice that I’ve used words like “request” and “ask” here, rather than “requirement” or “demand”. I do this because, no matter how much you have been conditioned to believe in deadlines as demands and requirements, they are always requests and statements of value. “I need this by Friday” means “If you can’t do this for me by Friday, then I need to find someone else to do it, because its value to me after Friday drops to nothing”. Something like that. A person who gives you a deadline for a task is showing vulnerability by sharing with you something about the value of completing the task to them or about the constraints they face if they fail to deliver their work to someone else. They are trusting you to help them reach their objectives. They are hoping (often desperately!) that you will be able and willing to help them.

Yes, even when they are yelling or barking orders to take advantage of their positional authority over you. The yelling manager is often covering for insecurity about something they’re trying to deliver to someone else. If we show them compassion now, maybe they will learn to show us compassion later.

This feels different to me than it does to consider deadlines as a cynical attempt to extract more output from me sooner. Again: some folks will try to do this, but if you sense this, then you can fall back to this classic adage:

When you owe the bank $10 thousand, that’s your problem; when you owe the bank $100 million, that’s the bank’s problem.

At some point, the person standing before you barking orders at you increasingly loudly, threatening you with deadline after deadline has to understand that they need you more than you need them. You can tell them this, even gently, but you can’t learn it for them.

Nonviolent communication practice encourages us to make clear requests to others so that they have enough information to decide safely and accurately how able they are to help us. This frees everyone up to act freely, to choose consciously, to say “yes” or “no” based on real constraints and capacity, rather than based on their mental relationship scorecard of accumulated unbalanced favors over time and the need to exert power over others in order to feel more in control of one’s own life. Clear deadlines represent a way to talk to each other more honestly and gives us more space to react consciously.

We can turn deadlines into an act of love, but it starts with choosing to see deadlines as an act of love, even if buried under crusty layers of controling motivation and contempt. It starts with recognizing that a deadline is merely helpful information when we negotiate with someone to do a task for us. It starts with remembering that “no” is always an answer we can accept. (Right?)

That seems to me like a modest concession for a huge shared victory. What do you think?

Adopting Tricky Design Concepts Safely

Thu, 15 Jan 2026 00:00:00 -0400

Quick question, if you want to implement a design that leverage a particular tricky concept but it’s a good technical decision for the software you’re building, what should you focus on?

What kind of “good” is that good technical decision? Who will need to change that code after you finish writing it?

An example that immediately comes to mind would be something like writing Front-End components using the Atomic Design Pattern. It makes writing modular components simpler but the pattern can be difficult to understand at first and apply properly at first.

Would mostly apply to Front-End & UI Devs

If I can see how to refactor safely from What We Typically Do to the Desired Future Standard Design, then that would make it safer to advocate for the DFSD while falling back to WWTD. Yes, it takes time to refactor, but in exchange, I don’t have to view the dilemma as all or nothing. Meantime, it’s hard to say where I’d focus, but I’d always be prepared for the group to decide that they’re just not going to accept the DFSD yet. Then I can decide which strategy to adopt: enlist a trusted colleague, demonstrate a pilot project, extract a Warm Dry Place with freedom to choose…

Typically, when technical leaders treat such a dilemma as “all or nothing” and “now or never”, then they get into trouble. This often creates more problems than it solves. Decision making like this is either an ongoing negotiation or a dictatorship. Pick one. (I can respect both choices.)

BTW: I didn’t know about Atomic Design, but I made some guesses, then I read a few articles. I mostly guessed correctly. This approach is not new. It has been proposed and discarded several times over the last 3 decades, especially during the Early Mainstream Adoption of OO design.

I believe (based on evidence from similar discussions in the past) that the conflict lies mostly in viewing software design as an activity of “First figure out the correct boxes, then carefully put each line of code in the correct box, and get it right the first time.” Even when programmers don’t say this explicitly, their objections and complaints reveal a bias towards deciding every little thing correctly the first time. Notably, they view changing decisions as “mistakes” and “avoidable rework”.

I propose that we radically change this attitude.

This is why I promote understanding how to refactor towards patterns such as Atomic Design: when we feel competent and confident doing this, then we are free to “get it wrong”, secure in the knowledge that we will gradually converge towards a reliable pattern as we need it.

I find patterns and styles such as Atomic Design more helpful when I know how to break them without disastrous consequences. Sometimes, we need to break the rules for a while, to achieve some other goal, then later bring the design in line with our established patterns and guidelines.

When programmers feel the freedom to change their minds, they can live in the best of both worlds: the security of a reliable pattern or guideline or framework without seeing those things as prisons that prevent them from Getting This Simple Stupid Thing Done Sooner.

One more thing: when we resolve to refactor in the direction of the pattern, then we stop arguing about “how to apply the pattern correctly” and instead simply nudge the design in the direction of the pattern relentlessly. We’re more likely to get there with less drama.

A Central Conflict in 'Readable' Code

Thu, 04 Dec 2025 00:00:00 -0400

I have written before about why I don’t like to label code as “readable” or “unreadable”, but sadly, this has not stopped the world from doing this. I have lodged complaints with the appropriate departments.

I believe that programmers generally want to spend less energy trying to understand code. Since humans are energy-conserving machines, this feels like a reasonable belief. Programmers, then, want code that costs less to understand so that they can change it safely and accurately. “Costs less” can be (somewhat) measured by time, energy, or even money. I’ll assume, for the rest of this article, that we share the goal of making code less expensive to understand. I might even call this the primary goal of “software design”.

In order to make code less expensive to understand, you have two key strategies: simplifying it or becoming more familiar with it.

By “simplifying” code, I mean reducing the number of things you need to know in order to understand the code. This tends to mean things such as moving irrelevant details out of the way and making relevant details easier to see. Becoming familiar with code usually only happens by spending time engaging with the code, such as by reading it or testing it or trying to change it.

It makes sense to try to simplify code, because this activity both reduces the amount of code you need to become familiar with and is itself an activity that causes programmers to work with code and become more familiar with it. The act of trying to simplify code helps programmers understand code sooner both by reducing the necessary investment and by also being part of making that investment. It seems like a win-win.

This is why we refactor, remove duplication, improve names, introduce abstractions, add tests… all the things that we have been talking about and debating over the decades.

What’s the Catch?!

Sadly, in order to simplify code, we risk making it less familiar. This happens because we:

introduce libraries that not everyone knows
introduce abstractions that not everyone has participated in choosing
need to name new design elements and we’re not excellent at naming

Not only that, but while we are in the relatively early stages of learning to do these things, we have to overdo them in order to form the judgment to do them correctly and appropriately and judiciously.

Simplifying code therefore risks making it less familiar. When we do this, we are betting that the savings from simplifying will be greater than the additional costs of losing familiarity. We’re also betting that it will become cheaper to invest in restoring our previous levels of familiarity.

When we simplify code in a way that makes the code less familiar, then I recommend focusing on improving names to make the code more familiar to your intended audience. In the process, according to The Simple Design Dynamo, you would iterate through removing duplication and improving names until you reached a new balance point where you judged the code as “good enough” to move on. When does this happen? Probably when the act of simplifying the code has given you a chance to become familiar with it again. Your subjective experience of becoming familiar with the new design informs your choices to remove duplication and improve names in a way that helps the code be more familiar to the other programmers not actively involved in your work.

In short, you’d start by focusing on simplifying the code, then you’d gradually transition to making the code (more likely to seem) more familiar before declaring victory and moving on.

So What?!

And here is the key point: we must be prepared to make the code less familiar for some time in order to simplify it. I believe the real power of the work lies here. If we are not prepared to let the code be less familiar for some time, then we will only ever simplify it when there is a clear, obvious way to simplify it. That can help, too, but I believe you would miss out on powerful opportunities to improve the design if you stuck with such a conservative, passive strategy.

Many of those programmers arguing heatedly in meetings about refactoring are objecting to changes (or refusing to merge PRs) only because the code has become less familiar to them. Their reaction seems perfectly reasonable to me, but I believe it is ultimately self-limiting. When you add to this situation the tendency to conflate complicated code and unfamiliar code as “unreadable”, those arguments become nearly impossible to resolve without resorting to dysfunctions such as deferring to the Highest Paid Person In the Room or the Loudest Person In the Room. You need another tool to avoid this fate:

If you want code to become less expensive to understand over time, then I argue that you must be willing to risk the code becoming unfamiliar; otherwise, you will miss your best opportunities to simplify it.

Do you struggle with technical leadership issues such as this one? Do you want to take advice like this, but feel emotional obstacles that you don’t quite understand or know yet how to deal with? I believe I can help. It’s not free, but software development professionals are getting the help they need as part of The jbrains Experience.

In the Age of Generative AI, Better Design Remains Up to Us

Mon, 01 Dec 2025 00:00:00 -0400

As we use LLMs to generate more code, Common Practice will become even more common, which creates an amplifying feedback loop entrenching Common Practice, even when what people are commonly doing seems unwise.¹ This means that we’ll see more code with more code smells that could be improved. More opportunities.

As we rely on LLMs to generate more code, there will be mounting pressure to do more with less. Programmers tend to react to that pressure by writing more code sooner (so let the LLMs generate it) and feeling pressure to look less carefully at the results (even when they know they need to monitor what the LLM produces quite carefully), even when that’s (clearly) unwise (and they know better). This means that we’ll see more code with code smells that simply won’t be improved, even in spite of everyone’s best efforts. More people will have less time (and less energy!) to seize the obvious opportunities in front of them.

The optimist in me hopes that the companies with “better” designs² will realize the benefits that come with “better” designs and stand out even more from the crowd with their ability to adapt to changing market forces. They would pivot sooner and more easily, feeling less resistance to make difficult business decisions and to take reasonable, calculated risks.

I am worried, however, that there will merely be a bigger population of mediocre companies for the average companies to (barely) outpace. As a result, those average companies will still have designs that mire programmers in frustrating busywork, rather than allowing them to better meet the demands of (reasonably) impatient stakeholders and customers.

Where Have I Heard This Before?

Patrick Lencioni wrote that teamwork was the business world’s richest untapped competitive advantage. Even decades after he wrote this, from what I can tell, not much has changed. Not enough folks understand the power of teamwork and find themselves with the combination of influence and opportunity to demonstrate its power. I think we’ll be writing in similar terms and more intensely about “better” software design in the next ten years or so.

I only know that I enjoy my programming work more when I get to live in habitable code. Maybe that’s how it will be: we will meet each other from time to time in warm, dry places where we invest in our own comfort and joy, whether our employers like it or not, as much as we can, for as long as we can.

Same as it ever was, I think.

See you there.

In a LinkedIn post, Joshua Kerievsky pointed out the proliferation of design risks (“code smells”) in the code that LLMs were generating. He raised the example of discovering a race condition made worse by polling, where it would probably help more to introduce explicit events to handle the concurrency.↩︎
I don’t like to refer to designs as “better” or “worse”, because that glosses over the complexities of software design. Even so, we occasionally need to resort to shorthand for brevity, such as I’m doing here. When I write about “better” design, I mean organizing the source code in ways that reduce the cost of a human understanding it so that they can change it safely and accurately.↩︎

Blue Tape and Inbox Technique

Thu, 20 Nov 2025 00:00:00 -0400

Michael Lopp’s article, “The Blue Tape List” reached me today and I feel very glad that I took the time to read it. (I, too, have a backlog of thousands of articles waiting for me to read them.) While I read this delightful article, I noticed how much I liked the metaphor of Blue Tape and how it immediately sounded like something I teach regularly: Inbox Technique.

Inbox Technique boils down to writing things down so that they don’t distract you while you’re trying to focus on a task. I teach this to programmers as a centerpiece to working effectively, as I described in detail in “Avoiding Distractions While Programming”.

Putting blue tape on something that needs fixing sounds writing down a particular kind of item in my inbox: “Do something about X!” (or probably just “X!!!”)

From here, the corresponding parts of the Blue Tape metaphor and Inbox Technique/Getting Things Done start leaping to mind.

While working on a task, when a distraction comes up, write it down (add blue tape). Writing it down is not a commitment to doing the new thing, but rather a commitment to at least consider (address) the new thing. During this task, you will complete some of what you’ve added into the Inbox, and then when you can pause, you need to do something with what’s left in the Inbox. Do what?

Delete, defer, delegate, or do. (All ways to address the items.)

What Happens Next?

When I teach Inbox Technique to folks, I primarily want them to experience the feeling of focus, but they tend to worry first about what to do with their Inboxes. Not every item that I write down becomes a new task, so it doesn’t always feel obvious what I ought to do with these inbox items, since I can’t always responsibly delete them.

Over the years, I’ve learned strategies such as converting these items into certain kinds of tasks that I put into my Trusted System. I find it helpful to phrase those items as tasks, which means that when I read them, I need to know how to do them. I phrase them as actions. Let me provide some examples:

“Spend 10 minutes deciding whether to do X.”
“Choose when to start working on Y.”
“Decide once and for all whether to bother doing Z.”

Each of these provides an example of how to address the blue tape without assuming that we actually have to fix what the blue tape is alerting us to. As Michael points out:

You will notice my homework to new hires did not commit to fixing everything they saw, I committed to addressing it. This could mean fixing the issue, but it could also mean responding and clearly explaining my reasoning why I didn’t think fixing the issue was the right move.

Similarly, you are not obliged to do everything that you write in your Inbox. I consider this point critical, because if you thought of Inbox items as commitments to future projects, then you would gradually stop writing things down out of self defence. You would feel too afraid of overburdening yourself by overcommitting. And if you didn’t write these things down, then you’d never feel the freedom that comes with truly, deeply focusing on the current task. You would be missing the point of Inbox Technique in particular and of Getting Things Done more generally!

Whether you think of this as Inbox Technique or Blue Tape doesn’t much matter to me. I merely want you to feel this power of focusing on the current task because you trust yourself to handle future tasks as you need to and when you need to. That’s the power of Getting Things Done. And if you need to internalize this as a Blue Tape list to get those benefits, I’m happy. The only rule is that it has to work.

What’s New in Blue Tape?

More than providing another way to understand Inbox Technique and Getting Things Done, I really like Michael’s explanation of the special context in which these distractions are coming to mind: you’re in a new context and you are constantly seeing things that you will eventually start to ignore when they become more familiar. Michael’s invites you to make use of seeing these things while you so easily notice them.

It’s a surprise when a month passes, and you review your blue tape list and discover how items that seemed urgent at the time now seem entirely irrelevant. You are learning so much every single minute of a new gig; you are gathering so much context. You are continually updating your understanding, your context of the team, your role, and the company. Your understanding after three months of work isn’t remotely complete, but it is exponentially more complete than at the end of month two.

You still address every item on the blue tape list. Every item gets a response. If you’re planning on fixing the issue, explain how and when. If you’re not planning on fixing it, explain why. If you still aren’t sure about relative importance, think about how you might find it.

A large new context is uncomfortable. It’s an emotional time because that which was daily familiar is now wholly foreign. The high alert your brain defaults to is stressful, but it’s a lens that allows you to see defects the old guard can no longer see.

I see this as part of what makes Inbox Technique powerful: it allows you to notice things without feeling weighed down by them. When you feel weighed down by noticing things, then you train yourself to stop noticing, which destroys the value of noticing. I want the benefits of noticing, so I make it less expensive and less painful to notice things.

This last point corresponds directly to one of the points underlying Extreme Programming theory: feedback has value, but only when we get it in time to do something with it, otherwise it becomes merely painful in the form of regret. And we generally don’t handle regret well. Accordingly, we seek feedback not because “it’s good for us” or “someone wrote it in a book somewhere”, but rather because we have a strategy for doing something with it. I use Getting Things Done as one of my strategies for making use of the feedback that I give myself in the form of distractions surfacing while I’m trying to focus on a task. Without Inbox Technique, I would merely be distracted, feel uncomfortable, make more mistakes, and work more slowly.

As Michael points out in his article, when you know your brain will be sensitive to distractions, it helps to have a system for making use of those distractions. Blue Tape, Inbox, whatever you call it, I encourage you to build a system for letting those distractions be as they are, such as by making them constructive, rather than by trying to push them away. When you push them away, they tend to react by never, ever leaving you in peace.

An Alternative Formulation of Getting Things Done

Mon, 30 Dec 2024 00:00:00 -0400

It’s easy to see Getting Things Done—both the book and the concept—as being only about making lists and setting reminders. They are the easiest parts of GTD to describe, which makes it easy to find articles about them, but they’re not the most powerful benefits. Unfortunately, when we write and talk about Big Picture Issues, such as figuring out what you really want to do in life and cultivating “the courage to say ‘No’”, we run the risk of sounding like Woo Merchants with Big-Sounding Ideas but Nothing Helpful. I’d rather not do that, so I’m considering a different question.

What would happen if you practised GTD? What could you expect that goes beyond making lists and setting reminders?

Getting Things Done Milestones

When I practised the techniques I learned from Getting Things Done, I noticed at least two significant milestones along the way. These are skills that I cultivated by practising GTD. Skills that I didn’t even realize I needed, would come to rely on, and would eventually dearly love.

safely forgetting
safely ignoring

The list-making and reminder-setting habits helped me learn to safely forget things, so that I could balance concentrating on finishing tasks with thinking about the wider picture. Doing this over the period of a few years freed up both the time and (mental, emotional) space I needed to reach the next milestone. My attention turned naturally to whether I truly needed to be doing all these things. This helped me learn to safely ignore things, such as projects that I could leave to someone else or that didn’t need to be done at all!

Some folks write about these abilities as your latent superpowers and when you’re drowning in projects, it can seem like pure fantasy to imagine reaching a stage in your life in which you could say “no” to people and focus on what you care about, rather than what the world demands of you. Reading their article, you could be forgiven for feeling like they’re blaming you for not taking control of your workload—like they’re telling you that you’re Doing Life Wrong. I don’t want to do that. Instead, I’d like you to know that practising the tedious techniques of making lists and setting reminders, along with the other techniques from Getting Things Done provides a path towards developing the skills, the confidence, and the courage to get there. You don’t have to have been born with it. You don’t have to have learned it by luck. You can cultivate these skills, starting with simple tricks such as the Two-Minute Rule and Inbox Technique.

You can do this and you can find straightforward places to start. It won’t be easy, but imagine how it would feel the first time you forgot something safely, with confidence, and without consequence! How would your life change if you knew how to forget or even ignore certain tasks or projects or things? If you could do these things safely? If you could do them responsibly? If you could do them openly in a way that didn’t feel like a temporary vacation or a guilty pleasure?

That’s what I believe you could learn from Getting Things Done. I imagine there are other ways to get there, but I suspect they’d all go through these milestones eventually: safely forgetting, along the path towards safely ignoring.

How I'd Like Automation Engineers to Support Delivering Features

Fri, 18 Oct 2024 00:00:00 -0300

Hi, I’m a Quality Engineer at my organization and I recently watched your video about integration tests being a scam.¹ We’re rearchitecting a lot of our system and exploring ways to better automate our testing to ensure we can deploy faster and with more confidence and I’m exploring ways the quality team can support this. How do you see a quality team working in a world where integration tests aren’t helpful in reducing bugs/mistakes? If the focus is on low level unit tests which are often better facilitated by developers, what can automation engineers do to support the product?

I’d like to start by clarifying a key point: I find integrated tests helpful in reducing bugs/mistakes, but I rely on them less than other people do. I tend to avoid mistakes with mostly microtests and integrated tests at the boundaries. I tend to use integrated tests to explore unexpected problems, then I tend to replace those integrated tests with microtests as I pinpoint the source of the problem.

All this means that if an integrated test finds a defect, then we ask, “Why didn’t we find this defect with a unit test?” And we ask this question in an open way, not in a blaming way: most of the time, we notice that we missed a unit test that we would have written if we had had all the time in the world, but sometimes we find a defect that nobody saw coming, and that’s when we feel grateful for the integrated test.

I say this not as a form of “well, actually…”, but because explaining that provides some context that makes it more convenient to answer the question.

How do I prefer to work with automation engineers? First, let me describe how I prefer to work with human testers, then how the automation engineers act as a bridge between programmers and testers.

Behold the Human Tester

First, imagine the role of the human tester. In The Bad Old Days, a programmer would write code, then throw it over a wall where it would land on a human tester. The human tester would then run some “tests”, probably by following a Test Script or a Test Plan, to do what we now call “routine checking” in the Michael Bolton² sense. Some folks saw this testing role as waste, so we decided one day that programmers ought to become testers and we called it “Test-First Programming”, which later became known as “Test-Driven Development”. From that point forward, the programmer took primary responsibility for routine checking, leaving the human tester to do… what, exactly?

The human tester no longer needed to do routine checking, because the programmer was doing it. This meant that the human tester could turn their attention to more interesting risks in the system. We use names such as “Exploratory Testing” and “Soap Opera Testing” to describe a kind of extraordinary testing, the kind that goes beyond the kinds of routine checking that “even a programmer” could be trusted to do. As a programmer, what I then need from the human tester is no longer to automate routine checks, but instead to explore the product, to challenge assumptions, and to subvert expectations. Instead of playing the role of parent cleaning the child’s face with a wet cloth, the human tester now has the programmer’s back in a fight (presumably against the defects in their system?). The programmer feels comfortable doing the routine checking, confident that the human tester covers their blind spots. They communicate; they compensate for each other’s weaknesses; they complement each other.

Enter the Automation Engineer

Now we come to how I ask the automating engineer to help: establish a pipeline for automating the human tester’s work when they uncover a test that the programmer would like to adopt as a routine check. The automation engineer helps the human tester avoid falling back into the trap of mindlessly running routine checks. True: these new routine checks are more interesting and more powerful than the previous ones, but the purpose of automation is to do repetitive things so that humans are free to become even more creative.³ The automation engineer plays a pivotal role as an agent of the human tester, relieving them of the burden of executing the same checks over and over again. The human tester explores the system and as they find interesting behavior, the resulting tests transform gradually into checks. The automation engineer automates those checks, so that the programmer can benefit from them as an ever-improving pool of change detectors.

Moreover, I’d like the automation engineer and the programmer to work together to transform bigger-scope (integrated) tests into smaller-scope (micro-) tests, because the automation engineer understands enough software design and testing to bridge the communication gap. The programmer doesn’t have to become an expert tester, nor does the tester have to become an expert programmer, but rather the automation engineer understands both groups and facilitates the transition from larger-scope extraordinary tests to smaller-scope routine checks.⁴

Moreover moreover, the programmer is allowed to focus on unit tests, so they write more of them, which strengthens those tests as a mechanism for finding defects and supporting refactoring. Consequently, the tester is less-often distracted by silly mistakes that the programmers really could have found or avoided on their own. The tester has more time and energy to devote to finding even more interesting problems before the end users do. In this way, the testers become free to act as agents of the end user or customer. They can think more about the system as a product from the end user’s point of view, rather than being relegated to treating the system as a bunch of bug-riddled software components in need of constant attention. Over the longer term, the tester develops a greater understanding of how the product might satisfy the customer—and even delight them!

Everyone wins. Let’s go!

I strongly strongly strongly prefer people to watch this version of the talk to any of the previous versions of the talk. And if you’ve seen one of the older versions, then please watch this next.↩︎
No, not that one, and not that one, either, but this one.↩︎
Something something generative AI something something.↩︎
The mediator between Programmer and Tester may be the Automation Engineer.↩︎

Making Use of 'Silly' Advice: Part 3

Fri, 02 Aug 2024 10:00:00 -0300

“We didn’t need it, therefore you don’t need it, so don’t do it.”

⚠ Caution. ⚠

When someone posts this, they might mean well and they might be very misguided. When you read this, I encourage you to look beyond the words to what might lie behind them.

I can think of at least two very different possibilities:

They are falling prey to damaging “Best Practices” thinking.
They have recently discovered that they could freely and safely stop doing something, because it was no longer necessary, and they want to remind the rest of the world to be aware of such opportunities in their context.

I find it difficult to tell the difference from here, outside their mind.

(I should mention now that if we spent another 15 minutes, we could probably find a few other ways to interpret those words, but I think these two interpretations make my point well enough, so I stopped.)

✅ Try this instead: ✅

Pretend they said or wrote this: “We didn’t need it (any more), therefore you might not need it (any more), so consider not doing it (any more)!”

The word “consider” stands out most to me.

We build habits in order to reduce the cost of helpful behavior. Unfortunately, habits often work best when they become autonomic, which means that we stop thinking about doing them. And we always risk habits becoming empty rituals. When the ritual becomes empty, the behavior stops helping us. At best, it merely gets a little in the way; at worst, it actively hurts us.

For that reason, we remind ourselves to inspect our ways of working every so often. Doing these inspections, we reconsider what we need to do, so that we can stop doing whatever has become unnecessary. And that’s how these words can become helpful: “We didn’t need it, therefore you don’t need it, so don’t do it.”

You can think of them as a somewhat unskillful way of saying “Do you really still need to do that? Does it still help you? Has it outlived its purpose? or did it never live up to its promise in the first place? What would happen if you stopped?” By interpreting those words more generously, we’ve turned them from apparently-mindless “Best Practices” thinking to a helpful reminder not to fall into the Grace Hopper trap: “We’ve always done it this way.” Even unskillful acts can help, if we remain open to how they might help.

Whenever you read or hear advice outside its context, I encourage you take it seriously without immediately assuming that you ought to follow it. I also encourage you to join me in resisting the impulse to tell them how wrong they are, because they’re often (but not always!) right in their context, even if they’re wrong in your context. It works even better to interpret their possibly unskillful act as a well-meaning attempt to help you. At some point in the future, you’ll probably wish that they’d interpreted your unskillful act that way.

Forecast Costs Responsibly

Wed, 10 Apr 2024 10:33:00 -0300

I think the typical software development group (team, department, …) has many more urgent matters to attend to than forecasting when tasks will be done. I don’t think it’s a bad idea to try to forecast more accurately; I merely believe that most organizations, most of the time, would benefit more from addressing other issues and letting this particular issue be as it is.

At the same time, almost everyone all the time wants to know when it’ll be done, for all kinds of meanings of “it”. And it therefore seems reasonable and urgent to try to forecast more accurately. This is merely a trick that the brain plays on us. We would have to train ourselves to resist the temptation to act on this source of false urgency.

I urge you not to bother trying to forecast the cost of tasks, even features, more accurately, but instead to work on other ways to improve. I can help you figure out what to focus on in your context, but maybe you’d rather start doing that on your own. In that case, start with the question of what’s interfering with delivering value to customers, then start chipping away at those obstacles. What’s valuable and when is it well and truly finally delivered? As you deliver more value to more paying customers, you’ll have more resources (including cash!) with which to figure out where to improve next. There’s more to it, but that’s a particularly helpful place to start (on average).

And if you insist on trying to forecast costs more accurately, then read Mike Bowler’s recent article on the topic.

Slack's Role in Managing Software Projects: Revisited

Thu, 28 Mar 2024 11:28:00 -0300

I remember reading Extreme Programming Explained, the second edition, and being surprised by the advice to put extra stories/tasks into the weekly iteration plan to use as ballast in the face of unplanned work. It seemed to me at the time like sandbagging—intentionally doing less than we could actually do. I didn’t understand the purpose of it.

At the time, I thought, “If we’re going to add more items into the weekly plan, then why not merely add the next stories in the priority list?!” Why would we choose to do anything but whatever would come next, especially since we assumed (thanks to Yesterday’s Weather) that we almost certainly wouldn’t get there anyway?

I didn’t understand much at the time about the psychological factors involved.

Now, I think of it like this:

It’s wise to put some items in the weekly plan that we don’t feel confident we can finish, just in case we get lucky and finish early what we expected to finish.
It’s risky for the extra items in the weekly plan to be items that the stakeholders care deeply about, because we’re setting them up for constant disappointment when we suggest that we might finish items that they care about, but routinely don’t finish.
It’s therefore wise for the extra items in the weekly plan to be items of significance that are not yet urgent, because there is a small chance that we might get to them, and if we don’t take advantage of that opportunity, then we might never get around to them… until they become urgent problems for us.

It would probably help everyone if our stakeholders never treated our weekly plan like a commitment, but that’s not how most people behave. Even the most attentive, caring, and collaborative stakeholders are humans and humans are easily disappointed. We react more sharply to loss and remember it longer than we do getting more than what we expected. I think it’s wise to choose an approach that reduces the likelihood of disappointment, all other things being equal.

After all, we always have the option of changing our minds and squeezing in a high-value story at the end of the week, thereby delighting some of the stakeholders. That sounds helpful, no?

Making Use of 'Silly' Advice: Part 2

Tue, 12 Mar 2024 10:06:00 -0300

To avoid arguments with strangers who are wrong on the internet, consider the following substitution in your mind as you read.

“You shouldn’t do X” or “Don’t do X” or “Stop doing X”

becomes

“You might not need to do X (especially merely because some book seems to recommend it). You might still choose to do X, but ask yourself whether that was a conscious choice, and if it wasn’t, then reconsider.”

Not as pithy, but much more accurate. And no need to correct internet strangers. That’s probably quite close to what they mean, anyway.

Some Theory

You probably remember a parent or other authority figure telling you that you can’t change them, but you always have the power to change yourself. I offer this trick as an example of how to do that.

You might feel annoyed that they don’t express themselves more precisely, resorting to blunt instruments such as “Don’t do X” when they really mean something much more nuanced. I understand that impulse, but I have found it helpful to imagine that they struggle to express themselves that way, even though it seems pretty easy to me. I know that, in moments of great stress, I fail to express myself with such emotional granularity as I can ordinarily do. Perhaps they’re under that kind of stress right now and that’s what motivated them to write about their advice, anyway!

What have we seen at work here? It depends on how you learned about it. I know these phrases and labels.

blaming stance
giraffe ears
emotional granularity
“Under stress, we fall back on our training.”
I am entirely responsible for my own emotional state

You don’t need to believe in or agree with all these, but perhaps one of two of them speaks to you.

Enjoy!

Our Collective Struggle Over Technical Debt

Wed, 24 Jan 2024 00:00:00 -0400

The term “Technical Debt” has changed quite a lot in general meaning over the years, but one fact remains: it is not a sensible goal to eliminate all Technical Debt, at least when you are truly trying to deliver software incrementally.

Wait… what?!

Fine, I’m being provocative for marketing purposes. Let me clarify:

I’m using the term “Technical Debt” as it is commonly understood these days: the accumulation of artifacts (code, documentation, …) that interferes with our ability to deliver the next valuable change.
Most projects would benefit from reducing Technical Debt.
Technical Debt tends to accumulate if we don’t train ourselves to attend to it.
Technical Debt is an unavoidable and normal consequence of delivering software incrementally.

A Problem

The confusion about Technical Debt typically comes from the apparent contradiction between “Technical Debt is unavoidable” and “We should reduce Technical Debt”. This happens when we act as Maximizers. Hilariously, some of this reflects the success of XP: “If this thing we do is good, then why not do it all the time?!” That’s the “X” in XP.

Even so, maximizing everything creates suffering. We often encounter tradeoffs, where two benefits oppose each other and so trying to maximize one hurts the other. We often fail to notice tradeoffs. We often disagree whether two forces are trading off or we can safely maximize one of them.

It’s Complex.

Why This Problem is a Problem

When we assume that we should maximize…

“Technical Debt is unavoidable” transforms into “There’s nothing we can do about Technical Debt” becomes “Our current level of Technical Debt is not only fine, not only expected, not only normal, but there’s nothing we can do about it, so let’s just ignore it.”
“You (almost certainly) should reduce Technical Debt” becomes “We need to relentlessly push for less Technical Debt” transforms into “We need to push for zero Technical Debt, and any goal less ambitious than that is a moral weakness and doomed to fail.”

I’ve exaggerated for effect, but not by as much as you think.

What Now?!

I claim that these two statements are true at the same time:

You almost certainly would profit from reducing Technical Debt.
You almost certainly would profit from embracing Technical Debt.

Technical Debt is the price you pay for delivering increments sooner. Eliminating Technical Debt would mean delaying the delivery of features.

Technical Debt compounds so we must agree to reduce it. Without that agreement and a strategy to reduce Technical Debt, the compounding effect would cause it to pile up until it overwhelmed our capacity. Letting Technical Debt grow uncontroled would mean delaying the delivery of new features.

Unfortunately, we don’t know how to measure “the right” amount of Technical Debt for you—at least not directly. As far as I can see, the best we can do involves looking for delays related to delivering features and diagnosing them as “cleaning up too much” or “not cleaning up enough”. We need to adjust our behavior continually. We can’t simply “set it and forget it”. Like I said, it’s Complex.

The (Bigger) Problem Behind “The Problem”

And we’ll probably disagree loudly about whether we’re not cleaning up enough or cleaning up too much. And different people will have different preferences about how much to clean up and when. And different people will have different needs, so optimizing for the individual would create even more conflict for the group. And Survivorship Bias guarantees that some people will assume that whatever they did in the past is the right strategy for this (other) group and this (other) project. And Confirmation Bias guarantees that some well-meaning, caring, opinionated folks will keep coming back to the group with article after article supporting their opinion. And it will probably never stop.

Resolve the Issue By Not Resolving It

This is yet another case where Best Practices thinking is likely to let you down. This is yet another case where there is no solution. If you want to deliver changes incrementally and sooner, then you will need to manage Technical Debt. Forever.

Don’t let it run wild and don’t resolve to eliminate it. Don’t squelch the arguments about it. Indeed, arguing about Technical Debt is the way forward. It’s how we continually adjust. It’s how we decide to clean up a little more here and a little less there. It’s how information flows about whether we’re doing enough or too much.

Of course, you probably prefer to argue more constructively and more harmoniously than you have the opportunity to do now. Your experience of trying to argue about this, whether with co-workers or random strangers on the internet, has likely felt more damaging than helpful. You’re probably afraid, maybe even terrified, of what would happen if you tried to argue openly and freely with your co-workers. It feels so much safer to retreat to Best Practices thinking or to give up on managing Technical Debt altogether. I understand.

Our collective struggle over Technical Debt seems much more to me to have been a clear signal of our collective trust deficit than a signal of our competence as software developers. I think we need to trust each other more to make any meaningful progress here.

What do we do about that? The answer fills bookshelves. One of my favorite places to start is Patrick Lencioni’s The Five Dysfunctions of a Team. If you have a favorite first resource on the topic of increasing trust, then share it with the world!