How to build an MVP (Minimum Viable Product) so it becomes an MUP (Maximum Usable Product)!

Imagine you are sitting in an armchair at one end of a farm that is about to give a great yield! How would it be if you could look at your software similarly? Did you try to do that? I did. I see a lot of learnings from that which we can put to software development and be able to feel the same kind of satisfaction when we look at our software! Here are my thoughts.

I am going to cover about crop’s yield which we all heard or have some understanding. The strength of the next crop lies in the seeds from the current crop. I would like to develop the same thinking for building software architecture that can scale with growth.

Building an architecture that scales has many dimensions to it. I am going to touch upon most basic intuition of visualizing versioned products. Let’s say we are targeting to build an MVP, like a season’s first crop, it is short-term but has long-term impacts. Ensuring that the “seeds (architecture base)” produced by it are strong (resistant to undue stresses and strains from the ecosystem) gives more “yield (new features)” without wasting energy in rebuilding the existing product to match new market needs. While it is the first crop, all the aspects have to be well addressed to ensure that the full yield is profitable.

At the start of a crop, field is structured into contours based on type of crop, land surface, water flow etc. We can also start dividing the product into modules. Modules should be derived based on domain’s logical boundaries, replicating near real time communication flow, role-play scenarios, reusable technical modules and data/message flows. The natural flow of any user request will then be intuitive like water flow in a field. This helps us measure and optimize the time taken for new feature development and know what/where the hurdles are.

Once you have modules, think next about appropriate data, persistence, UI, interactions between modules and other systems. While doing this, rely on wisdom that is prevalent in the form of design patterns, well defined API contracts, efficient use of third-party libraries etc. Just as we plan multi-crop farming with independent needs for each crop, we can cater to the design needs of each modules independently yet contributing to a combined benefit. In this diverse yet connected world, understanding re-usability and co-existence are essential.

Weed management plays an important role in yield improvement. It is an unavoidable natural phenomena in farming as well as software development because of diversity in resources. Weeds are spotted by looking at field rather than digging a hole in the field. The system architecture diagram should be like field of modules. We must get habituated to looking at system architecture diagram, domain model, interaction diagram, data flow diagram, ERD etc. rather than source code (it’s like digging a hole!!). Domain knowledge and best practices, like understanding the whole system from the view of each module, help in identifying and removing any unwanted components. This results in efficient consumption of resources for the intended outcomes.

Along with best practices, strong test automation helps us prevent recurring “bugs”. All these act like “pesticides”. They help us in improving the yield by reducing the “bugs”.

Well thought balance between modularity, design aspects, best practices (contour structure – fertiizers, weed management – pesticides) will give better yield in time to go to market with an architecture that can be scaled with time. As we know, winds change. Yet wisdom acquired over several iterations enables deciding on the right tuning of each of these aspects. This is where science meets art!