A playbook to building pragmatic software to deal with changes

“Change is the only constant”. This is not just a statement but it is the way of life. I have learnt this the hard way. The perfectionist in me used to analyze the product requirements in detail and try to make a product very generic and future-extensible in every possible way. The problem with this approach was that not only the product requirements kept on changing but the business direction kept on changing as well based on macro conditions in the market.

There are various factors that govern change like compliance guidelines, customer behavior, partner behavior, macroeconomic scenarios, change in org roadmap, competition, security vulnerability, etc. Hence it is important to take a pragmatic approach to software development rather than building software that can adapt to any kind of change.

What is pragmatic software design?

Pragmatic software design is the design approach where we choose the tradeoffs among various software characteristics in order to achieve business goals at a given cost. The following image shows the various software characteristics:-

The cost of software development could be money, manpower, or time.

Guidelines to build a pragmatic software

The following 4 guidelines can help in determining how to build pragmatic software :-

1. Identify the components which have maximum exposure to customers and design them in such a way that they can adapt to change quickly

In the software industry, a large number of change requests come from direct customers. If you are building a mobile application, the interface changes more frequently than the backend changes. Lots of experiments are done in the front end to understand what works best for customers. For example, during a festive season or running an offer for a product, we may want to change the theme of my app without changing the backend functionality. Also when a company does a re-branding exercise rarely is there change in the backend.

In order to cater to this process identify the changes and make them configurable so that no or less coding effort is needed when change is required. For example, apps should be built in such a way that themes can be configured rather than coded. Here, we have given greater importance to maintaining ability characteristics in order to react quickly to change.

2. Think of the lifetime of the product/requirement in mind before building it

Every product has a lifetime, sometimes literally. I remember we had to build a moratorium feature in our loan product at ZestMoney during the pandemic phase when the regulatory authority asked all lending institutions to offer this facility. This product was needed to make the borrower's life simpler but there was no revenue driver for this product. The time to market was more important than the scale or maintainability of the product. Therefore, we should always ask how long the product is needed and spend effort building it accordingly. If a product is needed urgently but has a very short lifetime or it will be rarely used then we can consider writing a script to set up an ops process to solve it rather than building full-fledged software.

3. Always remember that software changes are reversible

I have a few doctors and civil engineers friends and there was always one topic of discussion: how big is the impact of mistakes in our respective professions. In my opinion software engineers can take more risks compared to other professions ( unless of course the product is built for some very critical use case). We can always roll back or alter the product based on need. This does not mean that we do not put thoughts into all possible use cases but this means that we can take a balanced approach and sometimes even a riskier approach because we can always go back if things don't work out the way they should.

4. Think about it…do we really need to build it?

Well, we don't have to build everything that we need. There is a lot of open-source or paid software out there that can suit our needs. I follow a few simple rules to evaluate whether to build the software:-

1. Is it part of the core revenue-generating business or it is a supporting software that anyone can build and we can get or buy?
2. Does the team have the bandwidth to maintain it?
3. Does it follow all compliance and security guidelines?
4. Does the cost of building outweigh the benefits?
5. Is it the need of the hour or can I build it later?

Most of the time I am able to get answers by answering the above questions. For example, If we are a lending business we do not need to build a communication system as there are many third-party software which can build and maintain it unless there are some non-business factors around it. But, as a lending company, it might make sense for me to build a “Loan Management System” product that can offer various lending products as I can build various customizations on it that no one else can offer.

Conclusion

A pragmatic software design approach is refined over the years with experience. The approach I mentioned is not fixed and everyone will have a different take on this. But using these guidelines can help in improving throughput as you will be able to generate business value faster. Agree, in some cases, we will need to do tradeoffs on software characteristics but it is still worth following it as we will be able to conserve the resources of the organization towards the larger goal.