Deliver the Bare Minimum

It’s back to that mantra: Keep things as simple as you reasonably can.

There is always talk of doing things the simplest way when it comes to software engineering. You are pushed to focus on the minimum effort possible but with the most functionality. Entire philosophies are builts around MVP (minimum viable product) where you give just enough to the user to make them interested but no more because to do more when introduce too much work as well as possibly doing things for no real reason.

The challenge with this though is that sometimes you don’t really know what needs to happen when you are starting. I value the role of tinkering within projects very much. It’s something I enjoy doing and something that I find helps me get to the end goal the fastest. For some it might be writing down a design, drawing some boxes on a whiteboard and then attacking the code. For me though, it’s getting something up and running, seeing where the problems might be, seeing where things aren’t quite so simple and within that knowledge, start to peel back the layers even more.

It would be much too easy to start to abstract things away at this point but that would be way too premature. Instead, you get the little project going, maybe it’s connecting to a Kafka cluster and then writing the data somewhere downstream. Maybey you need to figure out how to get this new architecture running within the Cloud or with a new system of deployment. Trying to do all those things at once will cause an infinite number of problems and make it difficult to debug. Instead, one thing at a time, first get the flow running in such a way where you can see the source ending up in the destination. Then move on to the Cloud or the deployment. These things are not always straightforward and sometimesy you’ll go backwards and take a little longer but in the long run, you will be much happier, your code will be tigher and the project overall will be better.