Code as Inventory

I recently read a ten-year-old blog post by one of my software heroes, favorite Twitter follows, and author of Working Effectively with Legacy Code: Michael Feathers. The post, called The Carrying-Cost of Code: Taking Lean Seriously, struck a chord with me.

In Lean Software Development, requirements are often seen as inventory.  If you spend a lot of time elaborating requirements for features you are not going to work on for a while your process isn't streamlined enough.  That's fair, but I think that the brutal reality is that we have something much more tangible that we can see as inventory: our code.

It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.

In my career I've heard people brag about teams that "cranked out code" and such phrases. I cringe at the idea that bringing new code into the world is inherently a good thing, and doing it really fast is an even better thing.

On top of the cost of compiling it, running unit tests against it, cloning it from a repository, and shipping it in DLLs, there's the conceptual overhead of keeping around code that we don't need. Every time a developer has to read the code, scroll past it when searching for something else—in fact every thought that occurs in relation to it, in perpetuity, is waste.

As Feathers concludes:

I think that the future belongs to organizations that learn how to strategically delete code.  Many companies are getting better at cutting unprofitable features in their products, but the next step is to pull those features out by the root: the code.

User Story or QA Story

"What do our QA people do at the beginning of a sprint before the developers have coded any user stories for them to test?"

- Every aspiring Agile team with QA people

Honestly, I'm not sure I've ever worked on an Agile team that did not struggle with this conundrum of keeping QA people busy early in a sprint.

I'm a fan of the maxim: "If you can lean, you can clean"—there's always something valuable to do on a software project at any given time. Here are a few ideas off the top of my head, but I'm sure a curious mind could come up with many others:

  • Automate the testing of user stories that were tested manually in previous sprints
  • Conduct exploratory testing not directly related to a particular user story
  • Training

In case none of these ideas are adequate, there's also the common advice from Agile literature that smaller user stories are better. This idea of smaller user stories is appealing to people who are struggling to keep their QAs busy, because the thinking is that smaller stories take less time for the developers to code, and therefore the QAs don't have to wait as long to begin their testing. Makes sense, right?

So well-meaning teams take an axe to their user stories in an effort to make them smaller by any means necessary. Give QA something—anything!—to test.

Work proceeds like:

  1. Write a specification of something.
  2. Write code that meets that specification.
  3. As quickly as possible let a QA person check if the specification has been accurately met.
  4. Forget whether the behavior specified solves any problem for a real user.

By following this path, it's amazingly common to see the goal of "keeping QA busy" become the central organizing principle of a software project. And before we know it, maximum utilization becomes the goal of our sprint, rather than delivering value to users at the end of our sprint.

After a while, it starts to look like QA is our user, not the actual user anymore. We're delivering stories for QA now, not the actual people who need our software.

Snap out of it! There is no user but the user. Value is only realized when the user has it.

It's like acquiring staggering piles of Monopoly money. That pile looks really pretty, but let's not kid ourselves about the "value" of what we've achieved.

We don't work for managers and we don't work for QAs. We work for our users.

Selling Technical Debt

I tend to see technical debt discussed in a hand-wavy, fuzzy way, in which it's taken for granted that everyone knows exactly what it means, and why it's obviously bad. I'd like to put the onus on software developers to quantify the impacts of technical debt and what the business impacts are of paying it off.

"It's going to be easier to make changes later."

How would we prove that it's "hard" now? Is the average number of files changed per pull request higher than it should be? How would we prove that it's gotten "easier" later? What will the average number of files changed in a pull request be after changes are "easier"?

"We can move faster."

How would we prove that we're "slow" now? How would we prove that we've gotten "faster"? Will the number of story points completed per sprint go up? Is that a valid way of measuring efficiency or productivity?

If you're thinking to yourself, jeez, it's really hard to quantify these things, it's going to be equally as hard to convince someone non-technical to fund our work on technical debt. Unfortunately, the hard truth is that as long as we're unable or unwilling to quantify technical debt, then we can't really complain about the business not wanting to pay us to work on it.

We developers tend to grumble that "business people" don't understand code quality, but we have to be honest and admit that in equal measure we probably don't understand "the business" either.

As Martin Fowler points out…

Sadly, software developers usually don't do a good job of explaining this situation. Countless times I've talked to development teams who say "they (management) won't let us write good quality code because it takes too long". Developers often justify attention to quality by justifying through the need for proper professionalism. But this moralistic argument implies that this quality comes at a cost - dooming their argument. The annoying thing is that the resulting crufty code both makes developers' lives harder, and costs the customer money. When thinking about internal quality, I stress that we should only approach it as an economic argument. High internal quality reduces the cost of future features, meaning that putting the time into writing good code actually reduces cost.

We, of course, know that code quality has real impact on users, but it's on us to dispense with emotional appeals and instead make the connection clear to economic outcomes.

User Story or Manager Story

A pet peeve of mine is when people say "user story" as a generic term for any discrete chunk of work the team needs to accomplish.

And I don't mean this in a procedural sense, like you forgot to write the requirements in the classic "story" format like:

As a [type of user], I want [some functionality], so that [some benefit].

There's something very revealing about how teams write their requirements. Some teams have a product backlog filled with "user stories" written like this:

When you click on the "Edit Account" button, show a modal dialog with the title "Account Editor".

The modal contains:

- A dark green button in the lower right corner with the label "Save Account"

- Next to the "Save Account" button there should be a light green button "Close"

- A field with the label "Account Number" is pre-filled with the account number

… 

At the surface level, you can see that obviously this work item is not written in the typical user story format. So you could say, hey, we should write the requirements more like this:

As an administrator, I want to edit an account, so that the account is up to date when information changes.

That's better…maybe…but the real issue is not the format in which the requirement was written. The way a requirement was written can often indicate who we're hoping to please when the requirement is met.

When we approach software development as a series of user stories, we're seeking to please a user with each chunk of work that we deliver.

All too often software development proceeds more like a series of manager stories, in which we are pleasing someone in the team's management chain with each chunk of work delivered.

Some software organizations are set up like a feature factory, in which a management function beyond the development team decides ahead of time which things to build and the specifications of their design, and then parcels these chunks out to the development team on a sprint cadence. 

Feature Factory diagram via John Cutler

The optimum state of a software organization is one in which every person involved in the creation of the software understands the user's brain. Instead of thinking "what would my manager want me to build", think "what would our users want me to build".

Certainly many organizations get along fine as feature factories, but the real magic of the modern Agile philosophy is that we all take a user-centric approach to our work.

We call a chunk of work "done" when we all understand how it pleases a user's need, not just that our boss(es) told us to do it.

A user story is not just a format for writing a software requirement, it's the atom of a user-centric software organization.

How do we do remote work across time zones?

How do we work together when our people are spread across multiple time zones? It seems like this is one of the core questions that companies ask when they're getting into remote work.

I was curious about the "best practices" that are out there right now for handling the time zone issue, and how some well-known companies are thinking about it.

It's all about meetings

I found it interesting that almost every discussion on this topic is about how to schedule meetings effectively.

  • Do we have "core hours" in which everyone must be available for meetings?
  • Do we limit which time zones we hire in so that no two time zones are too many hours apart?
  • How do we inconvenience the fewest people when scheduling meetings?

On the GitHub blog, they talk about the importance of "overlap" for scheduling meetings:

We both have team members based all over the world, so typically we try to find times that overlap for various projects. A good rule of thumb is to create teams with four hours of time zone overlap, with the bare minimum being two hours.

The Dropbox team talks about their "non-linear" workdays:

We’re embracing what we call “non-linear workdays.” We’re setting core collaboration hours with overlap between time zones, and encouraging employees to design their own schedules beyond that.

The GitLab folks want to alternate who is most inconvenienced when scheduling meetings:

Synchronous meetings should be inclusive of those who want to attend and are in different time zones. For example, a team's recurring weekly meetings, alternate between a time which is ideal for EMEA and Eastern AMER (8:00AM Pacific) and a time ideal for APAC and Western AMER (3:00PM Pacific).

Why so many meetings?

In the post I wrote on this blog in 2014 about how I work remotely, the very first section was about the importance I placed on effective asynchronous communication.

Remote work requires a paradigm shift. Instead of thinking how can we go on working the same way we always worked without these pesky distances and time zones in between us, the best companies are starting at first principles. A true time zone-agnostic organization is one that, on a basic level, does not rely on meetings for collaboration.

GitLab deserves a lot of credit here, because they have written extensively on the topic of asynchronous communication, and it's a competency at the core of their organization. As the quote I included from them above indicates, they recognize some meetings as prudent, but they operate on an asynchronous-first model, with each meeting requiring a rigorous justification as to why it necessitates an exception to their default asynchronous mode of collaboration.

The easiest way to enter into an asynchronous mindset is to ask this question: "How would I deliver this message, present this work, or move this project forward right now if no one else on my team (or in my company) were awake?"

Instead of thinking about how to schedule meetings effectively when people are in different time zones, it's way more interesting to think about how do we…kinda…not need meetings?

Is Colocation Still Relevant to Agile?

As 2020 has undoubtedly been the watershed year for remote work, I've been thinking a lot lately about colocation and its relevance to Agile.

When the principles of the Agile Manifesto were written in 2001, the authors believed in the importance of colocation:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I was curious to know what Agile thought-leaders were making of the remote work phenomenon these days, and if the idea of colocation was still imperative to them.

Martin Fowler, one of the original signatories of the Agile Manifesto, makes the point that although face-to-face communication is more effective, a more important concern is to hire the best people you can and figure out how to make their collaboration more efficient later:

The first value of the agile manifesto is “Individuals and Interactions over Process and Tools”, which we should read as encouraging us to prioritize getting the best people we can on the team and helping them work well together. While we recognize face-to-face communication is more effective, that recognition cannot act to override the importance of individuals and interactions.

The fact that you can get a better team by supporting a remote working pattern has become increasingly important during my time in the software business and I expect its importance to keep growing.

It's interesting to think about this topic in the "necessity is the mother of invention" vein. When we all presupposed that a daily commute to the same physical building with your coworkers was the normal thing to do, we had best practices that presupposed that requirement.

In the current climate, we're all presupposing that work will carry on as normal with no one commuting anywhere and all communication being digital. What best practices will emerge in this world? Will the primacy of hiring good people quickly obliterate the former primacy of physical proximity in these conditions, with the world quickly moving on?

¯\_(ツ)_/¯

The Golden Rule of Interviewing

We've all heard the Golden Rule, which goes something like:

Treat others the way you want to be treated.

Well, my Golden Rule of Interviewing goes something like this:

Treat candidates the way you would want to be treated if you were the candidate.

Here are some corollaries to the Golden Rule of Interviewing:

  • Don't ask a question you couldn't answer yourself if you didn't already know it was coming.
  • Don't ask a question you wouldn't want to answer yourself.
  • If you like to ask trivia questions about your favorite subject, think how you'd fare if the candidate asked you trivia questions about their favorite subject.
  • Don't give a candidate homework you wouldn't do yourself.
  • Don't ghost a candidate unless you like being ghosted.
  • Don't require more preparation from the candidate than you're doing yourself.


You're a busy, high-status, well-paid professional. And so is the candidate you seek to hire. Do unto candidates as you would have them do unto you.