Moving house is like building software

September 18, 2022
by James Stanier
Leave a comment
Growth

I’ve not written for a few weeks because we’ve been busy moving house. 

In an attempt to turn my brain away from the lure of unpacking more boxes and moving more furniture around, here I am in front of the keyboard for a short while.

Dealing with boxes for a number of weeks has reminded me of a few concepts in software development: notably the power and pitfalls of abstraction, and the effects that deadline pressure can have on technical debt and efficiency.

Yes, there’s a metaphor in everything if you look hard enough.

Abstraction

One of the most powerful tools that we have in software is abstraction. Designing data structures, classes, interfaces and APIs well can have downstream effects on efficiency that are in the orders of magnitude: people want to use tools and systems that are understandable and easily composable.

Good abstraction, applied at the right time, prevents technical debt. Designing the right primitives in your system can be the difference between others wanting to build upon it rather than wanting to rewrite it as soon as the business logic starts to get more complicated.

When you’re moving house, boxes are a great abstraction to deal with, since you don’t need to worry about all of the stuff that’s inside of them, and nor does the removal company. 

The complexity of a house’s worth of items of different sizes are abstracted away into uniform objects that are easy to move around and stack in a way that the individual items cannot. Tessellation? No problem.

The idea of boxes and a removal van to take them somewhere is a simple concept: we abstract away all of our items, label them correctly, and then they are put back in a similar location at the other end.

But, as with most projects, it might be simple, but it’s not straightforward.

Technical debt

No matter how hard you try in any project, technical debt is going to happen. Here’s one of my favourite cartoons from MonkeyUser:

It always happens.

Sometimes you design something based on incorrect assumptions, or you end up with not enough time to implement something properly so that in the future it is extensible and easy to work with. Perhaps, like the cartoon, you just go too fast and paint yourself into a corner.

We started packing months before the moving date, as we are both working full time jobs as well as juggling all of the usual things that come out of a modern family life. 

The initial phase of packing is usually the easiest, as you can tackle all of the areas that have the least dependencies on day-to-day life: emptying those drawers that haven’t been touched for a year, packing all of the winter coats while it’s summer outside, and deciding that you can get by without using that slow cooker for a while.

Easy.

We also started in a well-organised manner. We had pre-made stickers for labelling all of the boxes, and we used a system design of grouping items by size and by intended location (kitchen, bedroom, bathroom, etc.). So, we certainly started out aiming to avoid any technical debt here, but like every software project, other constraints and project-related phenomena begin to get in the way.

Packing to move house, from experience, seems to be a manifestation of Parkinson’s Law, where the work expands to fill all of the time available for its completion. This may sound like the last software project that you did, and it will probably be like the next one that you do as well. 

When it came to packing, a combination of the difficulty of trying to estimate the amount of time that it would take (can we take a day off this weekend, or not?), plus the increasing dependencies as the packing went on (e.g. you can’t pack beyond the minimal essential daily items for each room, and everything packed increasingly uses up space needed for more packing and organising), means that lots of stuff just has to happen right at to the last minute, which is where your design starts to go out of the window and you introduce spoonfuls of technical debt.

Deadline crunch

In the crunch period in the final few days leading up to moving, you usually realise the following things:

  • Everything you haven’t packed yet is awkward in some way. Either you have the remaining items that didn’t fit nicely into boxes, or you have random bits from every room that don’t have clear logical box groupings, or they are breakable, difficult to manage, or just annoying. For example, should all cables be kept together as cables, or should they be taped to the item they plug into? What about all of the odds and sods that never got sorted out last time?
  • You haven’t got enough time to sort it out properly. Because the removal date is fixed, you know that there isn’t really anything that you can do. You can’t unpack all of the previous boxes because the resulting refactoring is too big and you don’t even know how you’d do it, let alone getting it done in time.
  • You start making shortcuts and hacks to get the project over the line. This is where you end up with boxes marked “stuff” or “decor” or “misc”, or where you begin labelling all of the random boxes with the same room destination because you feel that in the future you’ll be able to sort it out easily if all of your random boxes are in the same place.

Even though you had a great plan, and you had plenty of time, inevitably it was too hard to estimate the real complexities until you got going, and the consistent marching of time meant that it was too difficult to keep the same design and implementation purity as you went along.

Does this sound familiar?

Testing in production

Even if you’ve managed to keep your well designed boxes to say, 80% of the total and your boxes of miscellaneous junk to around 20% (hello, Pareto), using a removals company is like the DevOps divide.

A removals company who you haven’t necessarily met before, will turn up with their truck and people on the day, and you haven’t had the ability to do any load testing or a dry run. You’ve assembled all of your containers and labelled them, but what happens next is out of your hands.

On the day of the move, just minutes after you seal the last box, the truck turns up and a squadron of operators start loading them based on different criteria that you used to pack, because you weren’t aware of their requirements, and they weren’t aware of yours. 

Here, the truck is organised in such a way that it needs all of the heavy and bulky furniture to be loaded first, because of the way that it is stacked and tethered to the sides. Then, the boxes are moved and stacked via an algorithm that was not part of your design. Because, of course, they’ve not seen your design, nor is it important to them.

Then everything travels to the destination. If you’re lucky, it’ll all get there in one piece. Then begins unloading, where you need to map all of the items to new locations in the new home. 

At the other end, not only is everyone tired, but the want to do everything perfectly is overridden with the want to just get the damn move done. You soon begin focussing on the end goal (i.e. finishing shipping) rather than the quality of the process.

This manifests in a number of wonky decisions.

For example, the mapping between the initial environment and the final environment isn’t always clear, so your labelling doesn’t necessarily translate across: which is the master bedroom versus the second bedroom? What exactly does “family area” mean? Depending on the individual, things may end up in different places. And I’m not just talking about the removals folks—people in your own family might not even agree on how to interpret the plan.

At the end of the day, when the door closes and you survey the space, you’re just glad that everything is there and you’ve managed to ship it all. Yes, it’s full of issues and a bit of a mess, but you’ll sort them out later. 

You consider the rest of the work to be on the backlog.

Technical debt realised

The next day, the technical debt that was incurred in the system starts to come back to haunt you. 

Walking around the different spaces that are filled with boxes, you can spot the ones that should have been stacked elsewhere instead, either through your own poor labelling predictions or from how you were feeling towards the end of the day. As you see the last 5% of boxes rolling off of the truck, you become more motivated to “just stick it there” rather than ensure that it’s in exactly the right place.

You also can’t help but notice the giant stack of boxes in one location that are all labelled ambiguously. Ah yes: your random pile!

You seem to have way more “decor”, “cables”, “electricals” and “miscellaneous” items than you can ever have imagined. And what was in them again? The issue is that you’re going to have to open all of those boxes and unpack them in order to discover where they need to go, and then repack them again to take them there.

The joy of technical debt. What a nightmare.

It’s all the same

There are so many parallels to software projects when you move house:

  • Estimation is hard, and the managers don’t know the details. When we knew we were moving, we had a sales manager from the removals company spend five minutes looking around our house and then came up with an estimate of the time and number of people it would take to do the move. They couldn’t see the place we were moving into, so went by our verbal description. We also roughly estimated how long we thought it would take to pack, and we were pretty far off in our estimates, regardless of being quite experienced at this now. The only time you have zero uncertainty in a project is when you’ve done it, which is obviously too late in the process to help inform an estimation.
  • You’re always fighting against Parkinson’s Law. Even if you had a year to pack to move house, dependencies mean that you can’t finish until right up until the last moment. Also, if you have more time than you think, you end up increasing the time that you spend on the design and implementation, often to the point of diminishing returns. It doesn’t matter that the contents of the box are expertly packed and grouped if the deadline crunch meant that you forgot to label the outside correctly.
  • If the people shipping your project aren’t the ones that designed it, you better hope that you have clear documentation. When you move house, the removals staff haven’t seen your old or new home before, nor have they seen any of your stuff. If you’re unable to provide them with clear documentation and playbooks, don’t be surprised if your things all end up in the wrong place, even if you know exactly where it should all go in your mind.
  • Deadline crunch will make you do terrible things. That last 24 hours causes countless boxes of “miscellaneous” to appear, and the amount of time that it takes to deal with them after the shipping date is exponentially higher than the amount of time required to deal with the boxes that were well-planned.
  • Technical debt is inevitable. In any complex process that is hard to estimate, it’s inevitable that there will be subpar decisions made, and it is never through malice. Either it comes through lack of information, understanding, or poor interpretation. Going into the process expecting that everything is going to be perfect on the day isn’t just the wrong thing to do, it can be harmful. That’s because…
  • You need time after shipping to clear everything up. After the deadline, you’re going to need time to get everything back in order. Things need to be tidied up, moved around, removed, or reconsidered. And that’s just a normal part of the process, rather than feeling that it’s as a result of failing to do something earlier on that you couldn’t have predicted.

Is it any surprise that we struggle to estimate and deliver software projects reliably?

Anyway, back to unpacking I go. I consider this to be the clear up time after hitting the deadline.

What are leading and lagging indicators?

August 20, 2022
by James Stanier
Leave a comment
Q&A

Last week I wrote some thoughts on managing my energy better at work, through the lens of leading and lagging indicators.

When I was writing that post—judging by the amount of times I had to check and recheck the definitions—I realised that I often get them muddled up.

So, what better way of making sure I understand something than writing about it for a large audience?

Here we go…

Q: What are leading and lagging indicators? Why are they easy to get wrong?

Whether you are building a product, running a team, or managing a company, understanding the relationship between your inputs and outputs is essential for your success. 

In each of those scenarios, you are creating a function that accepts inputs, transforms those inputs in some way, and then, hopefully, outputs something of greater value.

We can think about what this looks like using some boxes and arrows. 

Let’s use building a product as an example. Any product that you build is going to have inputs and outputs.

Product inputs fall into categories such as:

  • Installs, such as the number of downloads, or purchases from a physical store.
  • Usage metrics, such as the number of daily, weekly and monthly active users.
  • Engagement metrics, such as the number of successful actions that have been performed in the product (e.g. ads created, workflows completed, amount of newsfeed items read, or number of tickets booked) or the amount of time spent in each user session.

These are all of the numbers that are feeding into the box. 

Then there are the outputs, which are important things like:

  • Stickiness, which is typically measured as a ratio of daily active users to monthly active users, giving you an idea of how often users are regularly coming back.
  • Retention, which is a longer term measurement of whether your users are continually active over meaningful periods, such as yearly renewal cycles or monthly billing periods.
  • Revenue, which is, well, revenue. It’s the amount of money that you are making—probably the most important metric of them all for any commercial product.

These inputs and outputs are what we call leading and lagging indicators. The inputs are leading indicators, and the outputs are lagging indicators.

Leading indicators

A leading indicator is a metric that allows us to better understand how something is going to perform in the future.

In our product example above, the leading indicators are the inputs into our box. 

We could reason that the number of installations that we are seeing of our product from week to week is one reasonable predictor of how it is going to perform in the future. After all, if nobody is installing it, we’re not going to make any revenue. The more people that install it, the greater the chance that we have of our revenue going up.

As per the examples in the previous section, there are often multiple leading indicators at play in any system. Exactly which ones you should pay attention to is something that can only be decided by you in the context of the system that you’re measuring.

The great part about leading indicators are that they are:

  • Quickly measurable, often in short feedback loops. For example, you can measure leading indicators daily or weekly in order to get an up to date view on your system.
  • Able to be affected by you, often in a short space of time. If your leading indicators are starting to drift outside of bounds that you deem acceptable, then you can make immediate changes to address that drift (e.g. make changes to the sign-up page).

Let’s take this example beyond a software product. 

Imagine that you were thinking about leading indicators for the performance of the engineering team which you are managing. 

One leading indicator could be the amount of critical production bugs that you are facing. This is because every time there is a critical bug, your team has to get interrupted away from what they are doing in order to triage and fix that bug, which in turn reduces their ability to get their current work done. I’m sure you can think of others.

Now, to another example. Imagine that you are gradually renovating an old house. 

You know that the energy efficiency of the house is poor (imagine that it is in the UK and has an energy rating of G—the worst!) so you look at a leading indicator which is the amount of windows that are in good repair and double glazed. 

That metric currently stands at 20%, so you decide that you are going to invest in replacing the windows over the next few years. The number of high quality insulated windows are your leading indicators of your energy rating.

Lagging indicators

A lagging indicator is a metric that allows us to better understand how something has happened in the past.

Looking back at our previous examples, we identified that:

  • Revenue was a lagging indicator for a product. If it has been doing well, then it will hopefully be making money. 
  • An engineering team’s lagging indicator could be shipping their milestones on time. This is because they’re happy, empowered and not getting interrupted by production issues.
  • A house’s energy efficiency lagging indicator may be an energy rating of A because it is well insulated and has no current structural issues that need fixing.

The tricky part about these lagging indicators is the inverse of the great part about leading indicators:

  • They require measurement over long periods of time to fully understand. For example, you might not know if your team is going to ship the new operating system on time until it has been finished in 3 years time.
  • You can’t directly affect them, since they’re an aggregated effect of leading indicators. If you make changes now, you might not see an impact in your lagging indicator for months or even years (e.g. think of annual billing cycles for software and your users churning at the end of the period).

So the art of bringing it all together is that you need to ensure that the leading indicators that you are affecting are proven to be responsible for the lagging indicators.

Bringing it all together

For many situations, this involves a combination of intuition, research and trial and error. 

You need to work out which of the leading indicators have an effect, and those that are red herrings.

Back to our box diagram:

There can be a lot to learn from prior art. 

For example, if you’re building a B2C SaaS product, there are lots of resources that can give you a head start in defining your leading and lagging indicators. Sequoia Capital has a detailed article on measuring product health which I also consulted while writing this article.

However, defining leading and lagging indicators gets more challenging when you are either measuring something that hasn’t been measured before (e.g. you are building a product in a completely new category) or you are dealing with a system that is hard to measure in the first place (e.g. what actually is the output of a good engineering team?)

This isn’t all bad, though.

Leading and lagging indicators can be the foundations of some valuable discussions within your team. For example:

  • What does it actually mean to perform well and to have great outputs? 
  • How can those be measured as lagging indicators, if at all? 
  • What are the leading indicators that contribute to those lagging indicators, and how can you be aware of them on a daily, weekly and monthly basis?

Why not go and chat to your team and find out?

Oh, and while you’re at it, why not try and apply leading and lagging indicators to other parts of your life? 

  • What are the leading and lagging indicators of healthy personal and family finance? 
  • What about your diet and your health?
  • What do leading and lagging indicators mean for the health of a community or city?

Leading and lagging indicators are a great model to think about how systems work in general, at all scales, shapes and sizes. All it takes is a box.

Extra bits

Before I go, I have a few extra bits to share.

I had an excellent article recommended to me by a reader after last week’s post about managing energy levels and burnout. 

It’s called “How to know when to stop” and it’s written by Andy Johns. It has some great models that cover our ranges of tolerance, career progression and life progression. It’s well worth your time.

If you’re interested in what the remote onboarding process is like at Shopify, then I published an article over on the Lead Dev blog that highlights my experiences of joining the team last year. Our onboarding program is fantastic. I outline what happens in the first few weeks in a way that will allow you to replicate the success at your own company.

And lastly, I’m really excited to be hosting and curating one of the tracks at QCon San Francisco —and virtually at QCon Plus—later this year. 

We’re going to be exploring the new world of hybrid work with a fantastic line-up of speakers:

If you’re interested in signing up, then you can get a $75 discount by using the code JamesSQSFPLUS2275 (yes, that’s quite a long code). 

The first 5 people to register with the code can get a free copy of my book, Effective Remote Work. Neat!