The Never-Ending Feature Party

A couple months ago, I was having lunch with a client who was so excited about some of the performance enhancements we had made to his app. His sales are soaring but his system couldn’t handle more than a few hundred users at a time. A little bit of work on our end and we got this slack message.

It’s conversations like these that make me fall in love with my job every day. It’s an amazing feeling to help folks grow their businesses by remodeling their software. So when Joe and I were at lunch to chat about how things were going, I shared with him my idea of how launching a new feature is kind of like throwing a party, which is a slight twist on the kitchen sink metaphor that “Uncle” Bob Martin outlines in his book Agile Principles, Patterns & Practices. Here’s the scene:

You start by throwing a party and invite some friends as a side hustle. It’s awesome. So awesome that your friends beg you to throw another one tomorrow. You know it’s just your scrappy group of buddies, so you don’t really bother to clean up after yourself or restock the shelves. Empty cans and crumbs are strewn around. Your friends still have a blast and ask you to keep throwing parties — only this time, they’ll pay to attend.

Now you have an opportunity cost to consider: When’s the optimal time to pause the partying so that you can restock and clean up? Well, it depends on who you ask.

Investors, especially those with a short-term exit goal, will want you to keep throwing parties as fast as possible. The people coming to the party (your users) might demand different things as you grow. When you start off with your first few friends, they’ll be much more tolerant of your “scrappiness” than people who are paying and weren’t in it from the beginning. And don’t forget your roommate: how willing are they to live in a constant mess? In this metaphor, your roommate might represent your staff or your support partners. How much do you want them to stick around? For example, in this example, if your roommate quits because you’re too messy, you’ll need to look for a new roommate while cleaning up and restocking before the next party. That will delay your next party even further.

At some point, if you want your party business to survive, you’ll need to allocate some of your resources to regular restocking and cleanup. Pretty quickly, you’ll find that if you wait until after the party’s over to start thinking about cleaning means a lot more work in the long run. So you hire someone to clean up right along side you. With this in place, you find that you can scale so much faster.

In the software realm, this “clean up and restocking” work is referred to as technical debt, a term first defined by Ward Cunningham in 1992.

”Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…The danger occurs when the debt is not repaid.”

In 2009, Martin Fowler shared his thoughts along with a helpful quadrant of when paying tech debt down is prudent or reckless.

Declan Whelan has a graphic where he uses the idea of a snowball to describe technical debt. His approach is to frame maintenance in a more positive light, using the term “technical health” to describe the state that you’re optimizing toward. For a deeper dive, check out my interview with Declan on my podcast: Legacy Code Rocks.

In the end, the goal is to scale to the point where you get a feature party that never ends. There are the folks who love throwing the parties (most folks) and those who would rather clean up. In the software world, I’ve started calling the party throwers “makers” and the clean up crew “menders.” The goal is to find the right balance for your business, at the stage where you are, with your particular context.

And if you need to add some menders to your team, hit us up. That’s all we do at Corgibytes and we absolutely love it. :)