A Perpetual Greenfield
Leave Your Legacy
So you’ve started that new greenfield project. Your project directory is empty; you get to lay the foundation. With your architecture on the whiteboard, you pick your favorite tech stack and then set off to the feature-building races. Your customers are thrilled with the feature throughput; everything is polished and delivered at or ahead of schedule.
Then, a degradation occurs. Maybe you’ve introduced an inheritance model that is becoming hard to work with. Instead of revisiting the model, you start to use sneaky inheritance tricks to continue delivering features. Maybe you’ve chosen couplings that have started to get in your way. Instead of breaking the couplings and finding more appropriate ones, you double down on the faulty couplings because you don’t have time to redesign. Whatever the case, you begin to sacrifice quality of features in favor of throughput.
Your choices start to hurt. Trivial additions to your codebase take far too long. Error rates are increasing. It’s hard to hold a conceptual model of your creation in your head. Your code base kind of starts to embarrass you. People start to refer to it as legacy code. The siren song of a total rewrite begins to sound pretty good.
I hope that you don’t recognize these anecdotes. But if you do, that’s okay. I do too. A crumbling code base will eventually prevent you from delivering value to your customers. What are some steps you can take to mitigate this risk?
Pay Down Technical Debt
The teams at Pluralsight pay down technical debt on a regular cadence. Much like financial debt, unpaid technical debt has a compounding quality that can be very hard to reverse if allowed to fester.
Some of the teams dedicate 25% of their time to paying down technical debt. Others spend every Tuesday improving the quality of their codebases. Some even freely delete portions of code in order to write it again using the knowledge they gained writing it the first time.
Our teams are encouraged to choose their own strategies for managing their technical debt.
Promote Excellence
Pressure is a funny thing. Being aware of pressure can keep you productive. Succumbing to pressure can be destructive. Deadlines are a huge source of pressure in engineering. If you cut corners in order to deliver against a deadline, you are deferring the proper implementation of something to a later date. All too often it seems that the later date never comes, the “cut corners” pile up and your ability to deliver anything slows to a crawl.
Some deadlines are necessary in order to coordinate efforts across multiple groups within and outside your organization. Other deadlines are totally artificial, deliver marginal value and do not reflect reality. We avoid the latter at Pluralsight. We don’t have deadlines, we have sadlines. That is to say that if we missed a deadline, someone has a sad. Occasionally we will take on a hard deadline if it makes sense to do so. When that occurs, we ensure that time is taken to pay down any technical debt that was incurred while meeting the deadline.
Embrace Mitosis
Part of our architectural strategy is to maintain small codebases. Doing so allows us to continue to deliver effectively, even in the face of fast growth. However, codebases grow. Successful codebases have a tendency to grow quickly.
But what happens when a codebase grows too large? Well, it might be time to split it up. Much like mitosis in cell biology, we like to let this occur naturally. When the size or conceptual model of any given component begins to get in the way of it delivering value, it is probably time to split. At that point we look for seams that have emerged in the code base and split along them. Not only does the code base get split, sometimes the team splits as well.
A Perpetual Greenfield
Everyone loves a greenfield project. They are easy to work with and value comes out of them without much effort. New patterns are easy to implement, you can try out and scrap ideas at a rapid pace. Over time these projects will wilt without proper care and the benefits of the greenfield project will be lost. At Pluralsight, we try our best to give that care in order to keep our code in a perpetually greenfield state.