Changing the code base landfill into a lean and learning recycling center
Waste seems to be a simple enough concept: anything that does not add value should be eliminated. But what about the features that are supposed to add value and actually don’t? What about the features that are started working on as an idea or a quick win that we do to just get it out there quickly – MVP style but not really – that end up being thrown away or redone soon after? Afterward, no one denies those are waste, but how do we turn waste into something that can be recycled?
It reminds me of myself as an angsty child. I remember worrying that the world was going to fill up with garbage. Now this is not an unplaced worry, but I remember worrying specifically that it would fill up with Happy Meal toys. Specific ones too: the stupid Barbies with the one strand of hair you might be able to braid and the plastic skirts, the Disney ones for every new children’s movie, and perhaps worst of all the Ty teenie Beanie Babies that people would stand in line for hours to get their hands on. Glad they’re worth so much now #sarcasm.
Software waste is like that, too. Not that I worry that the world will fill up with software waste per se, but I am worried that we crowd our code base and our capacity with wasteful code and activities. Some of it, like the Beanie Babies, will eventually go away and decompose (because they’re cloth after all). Other waste though, like bandaged and taped together code will be like plastic and will take years to decompose if it ever does. It will clog up the system’s pipes and make it harder for other features to get through. It will infiltrate and contaminate parts of the system we thought it would never touch. It may melt and transform into something even harder to get rid of than it was when it was initially put there – think hot mess. But how do we combat the problem and recycle the code waste through the learning it provided?
We have to first empower the people making the decisions to make the correct ones. How many times do we hear something like “well we need to get this out now so we will do this quick hack.” Actually, at a company they used hack so much they changed it into the acronym STIP. Bad story because I don’t remember what it stands for – something like Short Term Innovative…Procedure? Regardless, there’s a bigger problem than what it is re-branded as. If we can’t recycle the learning from the STIPs, it becomes waste – wasted time, code, effort, and support. There’s also the opportunity cost that comes from building a wasteful product we don’t learn from instead of a wasteful product we do learn from – that learning can be recycled into our next product venture.
Secondly, besides empowering the people making the decisions, we have to liberate the ones implementing them – or being forced to implement them. The developers who are actually hacking this stuff together know it’s a bad idea. They are in the code every day and see how it is held together (or barely held together). They know the implications of these “solutions” and how it can and likely will negatively affect the entire code base in the future. And we need to really emancipate them and LISTEN to what they say. We can say they are empowered but when we don’t consider their opinions, or when we consider them and still do the wrong thing they are going to be less likely to bring them forward in the future. This leads to less learning and more wasted activities.
So how do we truly start to eliminate waste and instead recycle our learning? We need to have the hard conversations with the right people. We need to make the difficult decisions based on logic and value-add instead of those based on emotional attachment to a feature. We need to re-examine Lean principles and understand what caused us to stray from them in the first place. We need to be open to learning, failing, and understanding the implications of not doing so.
It is necessary to have an emotional attachment to an idea. That emotion drives passion and passion is contagious. Without passion, what is the point of creativity and seeing a solution through? But it must be a fine balance between an emotionally charged decision that drives passion and a logical decision with solid reasoning behind it. Let’s make sure to be passionate about delivering the right solutions and delivering the solutions right. Let’s be emotional and passionate about reducing waste and recycling learning so our code repositories don’t become unmanageable landfills that take over our products and our people from the inside out.
agile collaboration decision-making emotion empower empowerment Lean passion productivity recycle retro retrospective software teamwork value value add waste