Your backlog is a fridge.

Take a look in your fridge. It probably looks pretty familiar, and a little cluttered. It might be hard to find certain things. In many ways, this is similar to the backlog for your software team. And while useful, both might stink.

And you could probably categorize their contents in similar ways, too.

Fresh & Ready to Eat

Of course you eat all this first, especially if it’s already prepared. It’s why grocery day is the best time to snack. There are too many choices!

In a software project, these are the normal stories you pick up and the bugs introduced by recent changes. You know all that code well, so you pick them up and complete them efficiently.

In terms of the fridge, a few days after shopping, you’re wondering what you possibly bought with that $200 at Whole Foods because there’s nothing to eat.

But, of course there’s not really nothing to eat, is there? There’s a whole lot there consuming precious fridge space. Let’s continue to categorize.

Food No One Wants to Eat

In your life, this is an aspirational purchase that is probably healthy or novel. Say, drinking vinegar or a superfood smoothie mix that sort of tastes like dirt (but hey it’s adding decades to your life!).

In your software project, this is a thankless task that touches parts of the system no one knows about. It’s got “Rat Hole” written all over it. Maybe you’re not even convinced it’s worth doing but didn’t want to rock the boat during sprint planning to challenge it. So of course you pick up that simple bug or fun new UI story instead. And everyone else skips over it as well so all the other work is taken on until it’s left all alone in the unassigned lane.

Fancy Ingredients

You saw a recipe for three greens ribolita soup on Pinterest with beautiful photos and told yourself, “I’m gonna make this!” So you buy all of the ingredients, including some type of chard you never knew existed. The day comes to make it, but it’s been a long day at work. So you give in to temptation and order something oily on Postmates instead. And so the ingredients sit there for while, and you’re still convinced that tomorrow for sure going to make it.

Eventually, if the ingredients are perishable, you’ll toss them and feel guilty for wasting food and money. However, what if you bought a container of something with a really long shelf-life, like miso? That goes right to the back of the fridge. You’ll probably find it when you’re moving out of the apartment.

In a software context, these tend to be the big “we need to rewrite submodule X” or “add tests to Y”-type tasks. They usually come from someone on support who spends hours wading through a mess of code and eventually patches it to fix an immediate issue, but then realizes that if the team just rewrote this messy module (or replaced it with a lib or some other sweeping change) then a future dev wouldn’t be forced to go through what she just went through. So she files a task to do just that. And then rolls off support and forgets about it completely. And then when another support person does the same thing for an issue with that code, if they’re lucky they’ll find her original task and +1 it or something and then go merrily along. Or, more likely, since the backlog is immense, after coming up empty after a cursory search, file an essentially duplicate ticket and pat themselves on the back as well.

Don’t be fooled. Think of when you’ve successfully carried out a big refactoring or rewrite? Did it come about from someone perusing the backlog? If so, what made it stand out from all the other similar tasks recorded with good intentions?

In my experience, any significant refactoring only happens opportunistically, as part of some planned roadmap item. It’s an easier sell this way.

“We’re about to add a big feature to Module X. The way it’s written, it will take forever and introduce tons of regressions. Let’s do the right thing and refactor first so we can implement the new feature in a sustainable way.” This is a rational decision, one that a PM would get behind. But if Module X works and is not impeding any present work, even if it’s total spaghetti, then why work on it? No reason. And you never will.


In your fridge right now, there’s probably some dried-up rice in a takeout container. Ditto that last bite of your sandwich from four days ago. In your backlog, this kind of stuff is your story-specific tech debt.

It’s all those TODOs you left in the code. They are often just a subcategory of good intentions, to make yourself feel better about your imperfect (aka shippable) implementation. However, it’s worth noting here that while there was barely any chance you were ever going to make that soup or rewrite module X, there actually is a chance you’ll eat your leftovers or finish some of those TODOs. However, like real food, the likelihood of success is greatest immediately after it goes in the fridge and plummets thereafter.

In the software context, this is why a transient medium like a sticky note is much better medium for capturing these tasks. While you’re waiting for the build, or QA to check out your work, you just might cross a few TODOs off. If so, give yourself a real pat on the back.

But be sure to toss that sticky at the end of the day (or week if you’re optimistic). Don’t litter the backlog or the code with TODO comments under the misguided belief that those will somehow make you complete them.

What experience in your life led you to believe Future You will be any less busy than Present You?

My own experience has shown me that Future Me will take far longer to finish any of the TODOs than Present Me, due to lost context, and will even be less likely to bother trying in the first place.

What can we do?

In some ways, a software team’s backlog is infinitely more annoying to manage than a fridge.

  • Fridges can only be so big. Digital backlog tools are essentially limitless, which is another word for bottomless. Like a pit.
  • Spoiled food will stink up the whole works. But tech tasks that reference issues that no longer apply look the same at a glance than ones you created yesterday. Any Good Intention task that references the outside world will become dated incredibly fast.

But, just like a real fridge, here are some practices that may help:

  • Be ruthless about what you add. Does this sound like a recipe you’ll never make or something simple that you would make on a weeknight? Only capture work that you feel is worth doing and you will have time to do in the near future. Stack rank it against other items in the backlog. If it belongs toward the bottom, it should probably be removed.
  • Get a smaller fridge. This will force you to be more selective. Gradually ratchet down the size of your backlog. To add something new, challenge yourself to throw something out. It’s a great way to actually retain important tasks while avoiding the waste associated with keeping around stuff that you’ll never do.
  • Write expiration dates on everything. On several backlogs I’ve managed, we had short term parking and other sections that had finite lifespans. The current version of JIRA shows little red dots on tickets as they age which is a nice visual indicator that you’re either neglecting important work or this work wasn’t so important after all.
  • Piggyback on planned work. Just like it’s useful to have a “kitchen sink” recipe that easily lets you use up fragments of random veggies in your fridge without having them end up in the compost, purposefully look for opportunities to attach backlog items to upcoming high-priority work streams. It’s a good time to practice your selling to management skills.
  • Clean it out frequently. If you can’t quickly find what you’re looking for in it, chances are it’s already too big. Give the team an ultimatum. Has it already survived three cleanings? It’s time to pick it up once and for all or trash it. You’ll quickly learn the kinds of tasks that never get picked up and stop adding them in the first place.

Thanks for reading and keep those fridges and backlogs clean and fresh!

Since WordPress comments are so spammy, if you have questions, comments, etc about this post, please talk to me on Twitter at @immutabill.

Special thanks to fellow Goodreaders William Cline, Morgan Russell, and Eric Lin for their insightful feedback on this blog. Also thanks to my good friend Monica, who reminded me that my last blog post was older than her daughter. It was a nice prod to finally get this out in the world.

In Search of the Ideal Employer

I’ve had a great run working on the Mingle team for the past few years, but, as they say, all good things must come to an end. I’m looking at other opportunities both within the company and elsewhere. And because of this, I’ve had a bunch of discussions lately about the kind of place I’m looking for. As I troll the job listings, I’ve developed a rough scale of what domain the companies are in and therefore how much my personal values align with their missions.

Which brings me to:

Bill’s Organizational Scale of Social Impact (B.O.S.S.I.)

The core activities and products of the company…

  • (+3) explicitly improve the world for the less powerful elements of global society (Samasource, Codestarters)
  • (+2) explicitly improve the world for everyday first world people, perhaps by enabling the sharing or green economy (CityCarShare)
  • (+1) improve the world, perhaps as a byproduct of their primary goal (GoodreadsVeganCuts, HipCamp)
  • (0) don’t improve the world, but would broadly be seen as worthwhile. Perhaps the product is a tool that can be used for doing good, but not necessarily so. (Mingle, many companies in the U.S.)
  • (-1) don’t harm anyone directly, but probably the money and brain power expended, both by the employees and customers, would be best spent on something else. (far too many startups in S.F.)
  • (-2) encourage behaviors that may be anti-social, misogynist, excessively consumerist, exploitative, and so forth (the entertainment/pornography industries, casinos)
  • (-3) explicitly harm society and/or individuals directly and should really not exist. (the for-profit health system in the U.S., energy companies, defense contractors, &c)

In this simplistic scale, I have intentionally not addressed large companies, e.g. Sheinhardt Wig Company, that likely have elements of each in their various divisions.

What about you? Where does your company fit? What matters to you about what your company does?

The Fallacy of Agile Transformation

Last summer, I attended Agile 2013 in Nashville. Many of the talks were focused around the idea of “agile transformation,” where an organization following a traditional waterfall software development process switches to an agile methodology, almost always Scrum.

But how does this occur? Does it start small, from the bottom up, and evolve gradually over time? Not usually, or at least organizations following this approach aren’t talking loudly about it.

Instead what seems to happen frequently is that a leader in the organization, presumably fed up with late deliveries, cost overruns, or other issues where the blame could be pinned on the software development methodology, decides that it’s time to get with the times and “Go Agile!” They then seek out a new tool and its associated training to roll it out to their teams as if it were a new time card entry system.

At its worst, it all goes nowhere, vast amounts of time and money are wasted, and the “forward-thinking” leader is eventually thrown out along with their tools. People doing actual work learn the lesson that change is bad.

When it’s called a success, what happens is that teams adopt some of the popular practices, like standups, and they use new terminology. However, since they were told of the new way to work, rather than working it out on their own, they seldom internalize the underlying values. When they run into trouble, they assume they must be doing the sanctioned process wrong and seek out process-oriented solutions from external sources of information.

So if the results of these transformations are not usually ideal, why do organizations follow this approach? It seems to me that the people who conceive of and orchestrate the transformation treat the entire undertaking like a waterfall project, because that’s the world they know. They create a plan, mandate a particular process and/or tool, and set a date for completion. The alternative, empowering their teams to change the way the work and improve over time would take an uncertain amount of time with uncertain results.

As an example, there was an idea board posted that asked attendees to complete the sentence: “Agile will fail at my organization because…”

An organization who has realized that predictive approaches have limitations and decided to experiment in more adaptive ways of building software would not frame the question this way. A team that is learning how to be better every day as it incrementally delivers value is already succeeding, whether they are on day one or five years into their journey.

Unsubscribe me!

Tonight I checked my email inbox and found about 100 useless emails I didn’t even plan on reading. So instead of just deleting them as I usually do, I went on a marathon unsubscribing spree. This isn’t the first time I’ve done this and I’m sure it won’t be the last. Seeing many different interfaces for unsubscribing in quick succession made it apparent what makes for a good design.

Why is this important? While businesses might not directly care about someone unsubscribing since the unsubscriber is less likely to buy from the business again, it seems to me that making the unsubscription process painless makes a good last impression.  This in turn makes the unsubscriber more likely to become a customer again one day or even recommend the business to a friend.  To take myself as an example, just because I’m unsubscribing from the promotional emails from an online t-shirt store doesn’t mean I’ll never order from them again.

Unsubscribe Do’s:

  • Do make it a single click from the bottom of the email (no questions asked, no login needed, no retyping my email )
  • If you have different frequency options or types of mailings, make a giant button that gets me off all of them so I don’t have to read all the options

Unsubscribe Don’ts:

  • Don’t make me tell you why I’m unsubscribing (but an optional form after I unsubscribe is acceptable if you really care)
  • Don’t make me reply to the email to unsubscribe
  • Don’t make me send an email to a weird randomly named email address to unsubscribe (yes I mean you Conde Nast!)
  • Don’t make me notice that while your website is pretty, your email system is run off of a cgi-bin folder on a forgotten mainframe.  It should be polished and branded the same way you would any of your public content.  After all, it’s your last chance to convey the impression of professionalism and trustworthiness to me.
  • For god’s sake, don’t send me an email to confirm my unsubscription!


Experience at SOCAP12

SOCAP12, which stands for Social Capital Markets, was held this week at Ft. Mason, the rehabilitated military base overlooking picturesque San Francisco Bay.  It brings together organizations and individuals interested in social entrepreneurship, the idea that you can build a sustainable and profitable business model with a socially beneficial mission at its heart.  The company I work for, ThoughtWorks, believes strongly in this idea and its reflected in our Three Pillar Model (originally from Ben & Jerry’s).

While the conference mostly focused on social entrepreneurship in general, I mostly attended the tech-focused sessions.

 Continue reading

Highlights from SF Disrupt 2012

This past week I attended SF Disrupt 2012, a conference put on by startup news site TechCrunch.  Thirty or so startups presented their ideas, many for the first time publicly, to the audience.  These were trimmed down to finalists and then a final winner.  I only attended the first two days so I missed the excitement of the final voting.  However, I wanted to capture interesting ideas I saw while at the conference in this post.  This attempts to be more journalistic.  If you want more of a rant my feelings toward its startup culture, see my other post.

 Continue reading

The Status Quo Culture at SF Disrupt 2012

Despite its focus on disrupting the status quo, in many ways Disrupt was a reflection of the current culture rather than a message from the avant-garde. For example, the winning startup is solving the First World Problem of being too busy to take your car to a mechanic. However, if you watched carefully there were glimmers of hope from a parallel culture, one building solutions that will truly improve the world.

 Continue reading

Continuous integration equally applies to your dependencies

Preface: I don’t think I need to explain why continuous integration is A Good Thing.  If you don’t understand that, look elsewhere for nice explanations.

Continuous integration is a very beneficial process.  You integrate with every commit against the other devs working on the same codebase.  However, what about your application’s dependencies?  What about integrating with the Rails developers? Or the jQuery developers?  Don’t the same benefits apply?  I’ve been on quite a few teams and it seems like we treat external libraries very differently from our own (or our own organization’s) code.  We fit the mold of what the Build Doctor calls “reluctant integrators.”  And I think this is actually a really dangerous process to follow, for many of the same reasons that practicing discontinuous integration is a bad idea with your own codebase.  It might seem nice and comforting at first, but over the years you’ll end up under water with regard to technical debt.

As an aside, it’s worth mentioning at this point that if you’re lucky enough that your codebase lasts long enough to feel the downstream damage from discontinuous integration with external dependencies, then congratulations.  Maybe it’s the short lifespan (planned, anyhow) of most systems that has meant this problem is not talked about as often.

For all of your libraries, you should have a periodic schedule to check for new versions and update to them.  The alternative is to postpone and magnify the pain of doing so, in the exact same way it would be for not pulling in your teammate’s commits.  But should you practice continuous integration with them, meaning upgrade to every public release?

I spent some time thinking about it and it seems like you should.  Commonly, people mention lack of stability as a reason not to.  I would then ask why you are using a library that you cannot count on the quality of.  Many projects have stable, long-term support or other more conservative packages to meet this need.  You can always use those if the developers are a little too experimental for your taste.

When a new version comes out, pull it in.  After all, if your build goes red you can always revert.