How not to lose sleep over product customizations & codebases

I once heard Spiritual master Sri Sri Ravi Shankar say: “ Pain is inevitable but suffering is optional”.

I could immediately connect with this, as I was struggling to manage the consequences of trying to extend/customize Spaghetti Code, and I strongly felt that much of the struggle and pain was avoidable when it came to Product development and customizations.

So many times we have seen how as an Enterprise software product gains traction with more customers, the Product Engineering team often faces a situation of having to take tough calls on how to cater to the evolving Product roadmap and Client-specific customizations.

Let’s see the example below:

So you have a great idea for a product, let us say in the Banking domain.

And you get Org C1, a leading company in the domain interested in what you have.

And Org C1 says it could work well if you make a bunch of customizations (of fields, validations, and business flows) not all of which are in your Core product roadmap.

You agree since this is the first customer and a big one at that.

All goes well, it works great and soon enough the second customer (C2) is interested. However, C2 doesn’t want the exact same features as C1 and of course, there are some unique C2 specific customizations. Your Engg team starts working on the existing code base, inserts a few If—else clauses, and hey it starts working for C2!

And then comes the 3rd and 4th customer together, each one with their own list of customizations! This is great news for sales, for the business, but what about the Product engineers? They smile outwardly but dig a little deeper and you can see why they are worried. They are slowly coming to grips with the complexities that lie ahead.

The choices they face are:

• Retain a single code base: They can add more If—Else clauses and somehow meet C3 and C4 requirements, the risk here is the code becoming more spaghetti with time OR
• Create a copy of the code base for C3 and C4; i.e. have 2 codebases for the same product version serving 4 customers.
• Each path has its own set of medium to long-term risks.

The enormity of this becomes apparent when more customers are onboarded. Very soon. – there is either one giant spaghetti codebase or there are a bunch of spaghetti codebases for different customers.

And the following situations keep recurring:

• a change made for C3 impacts some feature that was working perfectly for C4!
• a bug is discovered in the core functionality that impacts all customers. The fixes have to be introduced into all the different codebases which are usually not straightforward and from time to time compromises need to be made to the product roadmap.

Slowly but surely, the Engg team is pulled into a maintainability minefield as tracking changes in each codebase and the customer becomes progressively complex.

Is there a solution?

Yes – with Flexbase – Core-Industry-Client feature,  

The unique patent-pending layered approach to coding facilitated by Flexbase – helps ensure that the code for the Core product features is separately encapsulated from the code for any Industry domain-specific features which are separated from individual Client specific customizations. 

Thus any bug with the Core or Industry-specific features will only need to be fixed in one place. And customizations for each customer are in their own distinct encapsulations thus simplifying the maintenance.

With this:

• Core product roadmap need never be compromised nor is it at risk of becoming messy because of inconsistencies in code bases.
• Customizations for customers are decoupled from each other and it is easy to be creative with each customer without worrying about the impact on other customers.
• Any customization that is common for several customers can be moved into the Core codebase.

Then even when you get more customers, your Engg team will be all smiles genuinely!!

But wait, there is more….

What if you realize that there is significant potential if you were to apply your product core to another Business domain – say Insurance.

With Flexbase it is super easy to create another Industry layer for Insurance that will encapsulate the Insurance domain-specific customizations. And subsequent insurance customers when they are onboarded will just seamlessly use the Core with the Insurance Industry Layer with their own customizations!! Thus the same core is used across the Banking and Insurance versions seamlessly.

Interesting isn’t it!!

For the first time ever, Product engineers can confidently tackle growth-related challenges without having to worry about their product codebases! And the Sales team can confidently go about winning customers without having to worry about Product stability!