Making the Complexity Case

Most minutes of most days, a software engineer is solving a problem. It may be a massive problem, a small problem, or a local or a global problem that all engineers are facing. There are always problems to solve. What I can't understand is the complexity we choose to inject into the solutions.

I was recently looking at a process in my work day that was overly complicated. All we needed to do was grab pricing for a product. Before I found the end, I was multiple levels deep and over three API calls into spelunking. My goodness, what a mess! Many of these solutions were old and built up through time; however, this particular solution is mission critical to the complete business system.

I'm not ignorant enough to think that people build complex solutions just because they grow over time into spaghetti monsters. What is often discussed on teams but not often executed on is the untangling of the spaghetti into something neater and less risky to change. One struggle I have attempted to resolve, but have not made much headway is building a strong enough case to clean up this complexity or remove it altogether. One of the major struggles? Gather sufficient data that tells the story of the complexity. Then, using that data to define a cost.

Perhaps this is my call for help. There are always new findings in a large codebase that have the hidden cost of complexity. If you have readings to share or advice on how to make the business case, I would love to hear it. Send me a direct message on LinkedIn.