Know the problem you’re trying to solve
You sit down to start a new project. You start setting up the environment, maybe its a web service you're writing. As you're going along, you think, "what if I want to switch the database on the backend?" So you start to add in an abstraction layer there. You pack up for the night and promise to yourself to finish it tomorrow.
As tomorrow rolls around you think, "Gee, that DB abstraction is really boring to work on, so I think I'll work on something else." And this happens the next day, and the next…
Sound familiar? Maybe this happens to you at work too, you start designing a new service, and you make sure its scalable to 1000s of requests per second. But then your service is serving 10's of requests per day and you're already too late to the game.
This happens all the time, we get derailed with the technical details and totally miss focusing on the problem we were trying to fix in the first place. We take way too long to produce a solution, and end up either losing interest on a personal project, or bringing a work project to market way too late.
In my last blog, stop coding by coincidence, I detailed how we can bring the practice of mindfulness into coding. In this one, I'd like to dig into how mindfulness can help us with the problem of over engineering.
Over the course of nearly a year, I worked on a team that developed software to allow a doctor to beam in to a room in a hospital and facilitate a consult. We were replacing a system that was supposedly not keeping up with the demands placed on it, while also being difficult to change.
The team worked tirelessly iterating on the new product we developed. We laid out new designs with a nice micro-service architecture. We used AWS auto scaling groups to scale the product for the future. We built the product to be extensible for future use cases, building a platform rather than just a product.
We built a great software product, technically, the final product was leaps and bounds better than its predecessor. And then we brought it to users… and they liked it!
But (you knew the but was coming) when traffic started hitting our servers, it was very slow. We thought it would grow quickly, but the business contracts that were to be supporting the product fell through.
We had built a technical success that wasn't being exercised enough to make the effort worth it. And you can probably guess what happened next. Although we executed quickly, we were up against too tight of timelines to roll it out to other lines. The project pivoted, and much of the work that had gone into building the product felt wasted.
It wasn't all bad though, the product was able to pivot and get reuse in a different area. It still isn't seeing the traffic to justify the scaling engineering that went into it. And had we spent more time focusing on what was truly wanted by the users, perhaps we could have rolled out a solution quicker and more focused on their needs.
So where does mindfulness come in?
The thing is, this story is hardly unique. Stories like this one is why the agile movement picked up so much steam. But we were practicing agile, we produced working software every two weeks that we put in front of users. So even with the best efforts, this can still happen.
But there were plenty of moments to right the ship, and that's where I can see mindfulness playing a role. Many hours were spent discussing designs on a whiteboard. Architecting out grand solutions. Many code reviews were had that suggested better and more performant ways of doing things. These small day to day interactions provide all the opportunity we need to refocus ourselves.
Mindfulness doesn't have to be exclusive to coding, we can practice it any time. Those times at the whiteboard, it is useful to think to yourself, what are we really doing here, are we solving the right problems? And the same with the code reviews, thinking, is it worth investing the extra effort here, is this the correct problem to be solving.
This can also happen directly coding. In my last blog, I referenced TDD and how it focuses you on the problem at hand. I want to reiterate that sentiment. TDD draws the boundaries for you, enabling you to solve just the problem you're trying to solve. It can help you think carefully about whether or not you need to solve a grander problem. It allows you to be mindful of the iterative steps you're taking to solving that problem, and how much work is left to meet the real requirements.
There's more to do
Over engineering and focusing on the wrong problem are mistakes that happen every day. They happen for a myriad of different reasons in many different situations.
Of course, mindfulness is just part of the equation. It is no silver bullet for the problem of over engineering. In fact, it is really just the catalyst to get you started down the path of thinking about how to prevent it.
If we can be mindful of the small decisions we make day to day on our projects and how they'll impact us down the line, we'll all be better off.