Simplicity
Making things simple is actually one of the harder things you do in software development. Usually as you grow in your career you will be exposed to at least a couple systems where you are left wondering “how did they ever let it get this bad”. The “bad” we have many words for. Often times, it gets to that point because we don’t prioritize Simplicity enough as leaders.
It starts off Simple, it just doesn’t end that way
Often times things start off simple. We’re starting a new website and we just need a web server. Maybe it needs to be load balanced, in the cloud, in front of a CDN, nothing fancy. Its usually not difficult for engineers to start off with a simple mindset, but even at the beginning there can be pitfalls. The start of a project can introduce complexity in subtle ways.
I want to build this project in the hot new language
The hot new Thing
You will hear this… all… the… time. It’s not even necessarily a problem per se. Innovating can often times include using a brand new language, or toolset to give you fresh ideas on how to solve problems. It can lead you to amazing results. As a leader, though, you have to temper that with the drawbacks. Starting a new language means that your team isn’t going to be experts in that language. That means they aren’t going to write the best code. They will create technical debt much quicker than they normally do. You have to curb that if you choose to go down this road. You have to give them time to learn and pay back the debt. Some times the cost of this is too much for a project, but other times it can be fine. If you ignore it, though, it will always come back to bite you. That cool new project that everyone likes in the beginning, 6 months in becomes the side project everyone hates because it’s too bloated. It becomes that because it’s too complicated. The team doesn’t have discipline around simplification. Simplifying solutions is what pays off tech debt. It’s what takes what you’ve learned from a new project or a new language, and hones it into something more streamlined, something more easily understood.
It should only be as complex as it has to be
Software Development is hard. We have a tendency to make it even harder than it should be, though. Simplicity is about recognizing that and being disciplined enough to look back and realize you made something harder than it needed to be, and spending the time to address it. That means you have to dedicate time to the process. Every cycle of development you should allow your team time to focus on this discipline, so they always have an opportunity to recognize when they made something too hard and have the chance to turn it around. Often times teams look at technical debt as this insurmountable hill that isn’t worth spending any time on and should just be kicked down the road for someone else to deal with. My view is different.
Technical debt doesn’t really exist
What does exist is complex code that your team knows is too hard to understand. The question for you, as their leader, is are you going to create a culture in your team that allows them to simplify that code so that everyone knows how to use it. It should only ever be as complex as it has to be. If you are building an ecommerce site and your team is writing code that looks like they are launching a rocket, then you have some simplifying to do. Code for an ecommerce site should only be as complicated as buying stuff. You and your team need to know the difference in complexity between code that handles payment transactions and code that launches a rocket into space.
