It may sound like an overly pessimistic assessment of the state of our industry. My intention is not to sound cynical, however, I think we need to be honest with young engineers entering the field of software development: There is a real possibility, that a lot of the code that you will write during your career will go to waste. Nevertheless, this is not as bad as it might sound.
What I mean when I say “go to waste” is that a piece of code will never have any real tangible value in making anyone’s life better in any dimension. No one might ever click on that button you added or hit that API endpoint you worked on to solve a real problem. The reason is that for your code to have an impact, it needs to pass multiple important checkpoints. A lot of code is lost at each of these checkpoints.
The first hurdle that your code needs to clear is internal approval. Code can go to waste because of project cancellations and changes in strategic priorities. A factor contributing to code not clearing this hurdle is slow time to value: As long as it is unclear whether code is valuable or not, its fate hinges mainly on the goodwill of the management.
A second minor hurdle is technical obsolescence: Following a change in technology or a migration to another platform, a lot of code can usually be thrown out. This is a common “risk” for internal tools which can be replaced by existing off-the-shelf software.
Third, if your code makes it into a product that is released, it still needs to clear the market hurdle. A product rejected by the market without any commercial success is unlikely to significantly improve anyone’s life.
Lastly, even in products with commercial success, it may very well happen that the parts and features that you contributed to will not have any added value. Maybe users will simply not use the analytics feature that you have built because it is easier for them to simply export the data in Excel and run the analytics there.
Reviewing My Definition of Waste
The first thing I want to note is that waste may be an overly harsh label for code that failed to make a positive impact in anyone’s life. It is important to note that code also has information value: If a project fails to deliver commercial success, this could be an important data point about the problem space you are targeting. Writing throw-away code just to probe a part of the problem space can be seen as a valid strategy for product discovery.
Even if a project fails before any go-to-market attempt, you can still get learnings out of the experience: You might have picked up some new technology or at least understood somewhat better the inner workings of the organization you work for.
What will be important is to make some effort to capture these learnings lest this value is lost: At the very least there should be a blameless post-mortem reviewing the project. I do recommend writing down, both on an individual level and on a team level, what your takeaways are for future projects.
The Powerlaw Applies
From the responses I got talking to people about this phenomenon, I also suspect that there is a very uneven distribution: A lot of code that you write over your career may have little to no impact, but then there is this one project which might have a huge effect on thousands of people or more. Looking at it that way, this dynamic starts to look much less frightening: Not every line of code that you write might deliver a lot of value, but maybe all of these lines are necessary for that one line (metaphorically speaking) that will one day have a disproportional effect.
Hypothesis: Different Companies, Different Impact Rates
I have no numbers on this, but I would want to formulate a hypothesis on different company profiles and their track record concerning waste production:
- I would suspect that in your typical high-growth startup, the chance of your code having an impact is correlated with the overall chance of commercial success of the company divided by the number of pivots you can expect before going live. This is to say: Not very high.
- Big tech companies can throw a lot of projects against the wall to see which one sticks. Therefore I suspect that a lot of code goes to waste but the projects that do stick can have an outsized impact due to leverage.
- Companies that minimize the share of throwaway code are probably those that work on a project basis and very closely with their respective customers. However, this comes at the cost of a limited scale.
Furthermore, the risk of writing throwaway code is quite naturally larger on greenfield projects than it is when adding features to established products.
Concluding Thoughts
All of that being said, it is still curious that this is happening in an industry that shows an insatiable demand for engineers. At the time of writing, many companies complain that they are unable to find the talent they need to realize their projects. How can we square that with the observation that a lot of engineering work will end up going into the bin? Shouldn’t we first make sure we make efficient use of the work of the people that we do have?
While one factor may be that we don’t have the entire software project management thing fully figured out just yet, some waste is probably simply inherent in the process of innovative knowledge work: When the terrain is unknown, you also can’t anticipate all the obstacles ahead of time. In software projects, we are dealing with two uncharted terrains at the same time: The problem space and the solution space. As long as we capture our learnings in the process, trying out things may just be the most straightforward way of navigating these two spaces.
Lastly, I also need to underline that from a business perspective, throwing code away is probably a good thing as code as such is a liability, not an asset. Take the example of code that is obsolete: If you no longer need to maintain a piece of software because the underlying technology now solves the problem for you, then that is a benefit. You get the same result but cheaper.
For engineers primarily motivated by impact, all of this can lead to moments of frustration. I think the best way for those of us that like to see the fruits of our work being used is to zoom out and consider all the ways in which throwing away code is simply a part of engineering reality.
The Solution Space 