Throw out your source code

People often wonder why software developers make the big bucks. We sit in comfortable chairs tapping clicky keys all day and enjoying a multitude of sparkling water flavors wherever we go. There is often a lot of watching of cat videos, and sometimes, there is the playing with the nerf guns. All in all it seems like an idyllic life.

That is during “The Good Times”. When people are attending The Status Meetings, and The Product is following The Schedule. I have sat in these meetings; where people with fantastic job titles throw around these words like they are religious incantations; capitalized and nearly without meaning. “How will this Change Request affect Quarterly Revenue” a high priest of product management may intone, not actually caring about the actual content of the change request. There is no greater incitement to violence in the soul of a knowledge worker than the presence of such monsters. If you have ever sat with me in a meeting and saw me staring at you white-knuckled and struggling to find words, I am sorry, yes, you are “one of them”.

It is not all ashes and debris all the time. I have met some great people in product management and marketing. I tend to cling to the good ones; they are deserving of my company. Especially when I can find the ones that understand one of the core principles of software development that is unspoken: You should always be throwing away your source code.

What madness is this you ask? Calm down. Breathe. Let me explain. Yes, I understand that there was a few million dollars or more invested in making “a thing”. Honestly, though, software development is not like building houses in a subdivision. There may be somewhat of a blueprint, possibly an architecture, but often software development is a steep descent into the hell of managed chaos, where people create staggeringly intricate connections between objects of increasing geometric complexity, often running into issues that were unforeseen.

Sometimes even people will get their product stood up and in front of customers before the geometric complexity manifests itself. Suddenly, the servers may go down, Product and Revenue will start to be Impacted. Of course this agitates the high priests and suddenly making sure this gets fixed becomes The Top Priority. It goes without saying that The Top Priority is still to make sure that all the other Top Priority items get taken care of too. Someone declared this code Complete, remember? And this is where we get into the big bucks part of the equation. Software developers are often required to make complicated trade-offs in order to serve these interests. Of course, this-is-the-way-we-do-things.

Is there an alternative? Let’s discuss.

The reason we got here in the first place goes back to that whole geometric complexity thing. Software development is challenging and trying to make sure we can manage all of the risks and the unknowns is never perfect. Yes, that is correct; software development has the unknown unknowns. We build many things and sometimes there are things that are not well communicated, and sometimes there are things that are not well understood. The sum of these things results in imperfect systems being created. How often does this happen? Only on days that end with the letter “y”.

There is some sort of zeal or enthusiasm for people to be able to create cookie cutter software magically the same way that you build houses or the same way you create store-bought stuffing. Gather the team, the ingredients, the blueprint and go. Over time, a well-run team may get to the point of having almost no new unknown unknowns while adding features to a software-as-a-service platform. To get to the point where this is a stable and mostly repeatable process takes more than one year. Does it take two? Does it take five? Quite often that depends on whether or not people are quitting, or dying for that matter, spiritually or actually.

Team stability is probably one of the most unappreciated things I run into on a daily basis. Now it is time for me to bring the point home about throwing away your source code. By the time I am done explaining, I am expecting you all to nod in amazement and wonder; I also expect a five star Yelp review.

Through the years of managing teams and shipping products there always comes a moment after a piece of software is built that a team member comes up to me and is agitated. They want to refactor something. 

Refactor? That is a scary word to the high priests of marketing and product management. It generally means random engineering tinkering under the hood that does not come with a Change Request. It may not be clearly attached to Quarterly Revenue, much less to Roadmap.

Sometimes the job of engineering leadership is to give that poor gentle soul a hug and a reassurance that everything will be okay; that this is not the hill to die on. Sometimes, that engineer will come back a few weeks later, more visibly disturbed. They need to fix something. It will go from “this is an inconvenience” into “this is a time bomb” with varying degrees of speed. Do you fix it? Do you forget it? It is not always clear. Sometimes you get the bear. Sometimes, the bear gets you.

It is important to set aside time for this clean up work on any project. In video game development, especially for a brand new game, I make it very clear up front that prototyping work is intended to be 100% throw away. This is important. You have to take stuff and throw it away. Do it over. Do it better.

We learn things in making software, we build things to test out hypotheses. It is important that this research and development work gets its properly allocated share of Research. It is important that it leads to time to do additional Development. Quite often people will consider The Research as The Development. This is a dangerous, deadly, dark path. Just because someone has written a thing, you must not necessarily assume you should ship a thing. The amount of cartoon stink lines emanating from it may vary.

Fighting the fight to refactor code, and to throw away code that-must-not-be-shipped is a significant struggle and super important to the stability of your team.

The more luxury you can afford your team to go and do the good work of making sure they have the best code possible, the more likely you will end up with the best product possible. There may or may not be studies on this. My empirical data on this has made me a firm believer; I carry this torch and shield with extreme vigor.

Long term, if you can fight this good fight, even if you lose it from time to time, your teams will stay with you. They just want to do their best work. They want their best work to be respected and appreciated. What happens next? You will continue to see them delivering their best work again and again. When people are on a team like this, it is the greatest feeling imaginable. I was on a team like this a few times and I miss it so much it hurts. It is why I am in the process of building a team like this right now.

However, if you sacrifice your teams on the altars of Roadmap and Revenue, I have some bad news for you. This will murder the gentle delicate souls of your best people. It will crack their insides and deaden them to the feeling of joy. Invariably, it leads to people considering the insidious whispers of Recruiting. You heard me correctly. If you do not give your knowledge workers the space to “work” with their “knowledge”, you must understand that they will want to leave.

I went through this whole article trying to avoid the words Refactor and Technical Debt. I was mostly successful. These are the words that engineers use when they feel The Light die a little; these are their impassioned pleas to the monocle-wearing cloud-people in leadership that they want to feel joy again, to breathe and be free. These words become dirty to the high priests within The Company at the peril of your team; when they become part of the Doctrine of Next Sprint, and that Next Sprint never comes, your best people will promote themselves to the lofty title of Not Working Here Anymore. Congratulations! You have earned a rank of Churn! This Churn will affect Roadmap. So we will need to replace them with new people. These people will likely not have all of the skills and experience needed to thrive on day one, many of them will take time to get ramped up and acclimated to their new world.

Of course, since the people who wanted to clean up their code so badly never got a chance to, this next generation of knowledge workers that comes in finds themselves neck deep in a world that is filled with brokenness and hurting.

This starts a vicious downward spiral of decreasing code quality, and it is a sadness in the hearts of all who behold it.

The best code bases are made by the best teams and the best teams get the luxury to rewrite their code bases when it is necessary. To deny your teams the ability to have the best code bases you will no longer have the luxury of the best teams.

What you wind up with is a code base that does not age well, and a handful of people who feel obligated to maintain it until such time as it can be taken out behind the shed and put out of its misery. If it is code in a successful product, this is a process that can take years and is horrifically painful for everyone involved.

Just about every software system needs some level of rewriting. If it is good code it may not need much, if it is bad code, it will need quite a lot. The question is, do you want to make the time to rewrite the bad stuff when you want to rewrite it? Or do you wait until the time arrives when you urgently need to rewrite it? The number of people who wind up doing the latter may totally shock you!

In conclusion, I boldly state it is important to let your people throw away their code. Do it over. Make it better. Throwing away code improves things in many ways. I am not going to bother to go into all of them in much more detail, because the most important thing about letting people throw away code is that it means you value them as people and you value the whole of your team.

If you need more convincing than that, I honestly wonder if you deserve your paycheck. If you are ever in a meeting with me, I assure you I would be giving you a quiet Greta Thunberg stare with the blazing intensity of a thousand angry suns for the duration of said meeting, and it would be on repeat for all of the meetings we would be required to have together afterwards.

To the rest of you, thanks for reading! I hope you enjoyed this voyage into the thoughtfulness of leadership and the importance of throwing away code!

As always, like me on the socials, share me with the connections, and feel free to indulge in an attempt of creating meaningful social reciprocity.