Chapter 11 — Bankruptcy for your code base

A fable about bankruptcy and your code base, written in collaboration with Gustavo Freitas.

Disclaimer: all views expressed here are our own and do not represent the opinions of our current employer or any entity whatsoever with which we have been, are now or will be affiliated.

Let’s face it — trouble is here. Your code base is a mess. It's hard to maintain, it's hard to evolve. The team keeps hacking around to make sure the release happens when they are expected to.

You hire experts. Change technologies. Containerize. Move to the cloud. Move to Mars. Still not enough.

People invest money in your codebase. Right? Useless code is wasted money, so please call it like it is: technical debt. The bigger your tech debt the smaller your tech net worth.

Now, would you agree you are tech-bankrupt?

There is no good way to put this. As much as a company with a stable revenue and a negative cashflow slowly sinks by becoming paralyzed and in debt, unless the problems that caused the negative cashflow are solved, a tech organization with constant velocity and a huge tech debt can’t get out of the red zone without stopping, understanding the problem and attacking fiercely.

You need to act now — doing nothing is a choice that will end up being much more expensive than fixing it now.

— You ask, Who the hell do you think you are to say that?

We answer — been there, done that. More than once. More than twice. And we ask people about their experiences, and their stories sound just about the same.

So let us describe the path to tech-bankruptcy and you tell us you’ve been there, done that. Or not — in this case, send us an outline of your trajectory and we will write a second version based on it, so other people can try to avoid the same patterns, too.

The path to tech-bankruptcy

• communication breakdown, it seems people don't speak the same language anymore, failures to communicate when trying to solve any given problem
• ownership and accountability are only words flying around the office, who does what? it's surely much more than just build it
• company goes: let’s solve all our problems with automation, automate everything please
• techniques which reinforce thought and reflection are seen as time consuming or bureaucratic (analysis, story kick offs, testing, etc)
• testers and developers as separate roles, creating silos, which reinforce diverging motivations and plays against shared knowledge
• deliverables are greater than team capacity (okay, Houston, we’ve had a problem here)
• phase out all manual and exploratory testing because now you got automation, so what could go wrong?
• when shit hits the fan, quality is always somehow sacrificed, which means code base is constantly patched — just make the build green please!
• PANIC attack

Debt free, just ahead

First things first, admit that there is something wrong. According your product objectives, define what the problem is; prepare for a work proposal.

1 — List your assets (codebases, builds and teams)

Point out the time ($) that goes down the drain fixing the mess, the level of satisfaction each of your individuals with respect to the quality of your code base. If you don’t have that, talk to your team about it and run a few iterations trying to measure the impact on your team (you can ask each one of your folks to list what and how long each of the problematic areas ate out of the time they took to complete something)

2 — Define how you measure success

Get someone to be the sponsor, or your bankruptcy administrator (someone who is passionate about fixing things, they could be responsible for overseeing the existing codebase for example).

3 — Get your team together and create a strategy

Define a plan of attack: what is the ideal state, what state are you at now, what is on the way. This includes technologies, layers, everything you have and want to replace, or want to keep, and what is your nirvana.

4 — Create a roadmap

Find the time ($). If money for the entire thing won’t happen, break down in smaller actions and prioritize; give it to the sponsor (bankrupt admin) so they can work with people to run the plan in tasks that are part of what they already do.

5 — Profit (back in business)

Lastly, keep communicating your success metrics. When they reach the goal you are out of bankruptcy. You are free and back in business. Ready to spend all your money once again? Let's go easy this time.

This article was heavily inspired by an official US Courts manual.

“This chapter of the Bankruptcy Code generally provides for reorganization, usually involving a corporation or partnership. A chapter 11 debtor usually proposes a plan of reorganization to keep its business alive and pay creditors over time. People in business or individuals can also seek relief in chapter 11”