Your business decisions are going to change!

“Let me just hardcode it right now, it’s not like this feature is going to have a sudden change tomorrow.” I thought to myself as I made a small compromise on the quality of the code I wrote.

I was working on a product I was building for small scale institutions that made it easier for them to teach coding to their students. Ironically enough, the requirement that I thought was not going to change anytime soon changed just two days later when I demoed the product to a few potential customers, turns out I had misinterpreted a need and I was out of luck until I changed the use case to match the customer’s needs.

Due to the compromise I had made to get something done quickly, the same decision backfired when I spent over a day just trying to get the change done which, if I had taken the longer route previously, would have been a one-liner change.

This post is about convincing you that no matter how written in stone your business use case or product requirements seem, they are bound to change at some point in time down the line. It’s inevitable.

It is also a post where I request you to not be associated with just one specific niche, it’s great companies’ ability to venture out into different domains that give them a competitive edge over others while not being judged for doing something that would have been in their comfort zone.

Changes don’t take time to be thought of, they take time to be implemented.

A change to a business use case does not take more than a second if management deems tomorrow that turning an app it had spent two months building for a Business to Business use case into a Business to Consumer use case will be more profitable or will get them more users and in turn more revenue to show to shareholders, it will do that. Now, the people managing and developing the app have to shoulder the burden of actually making the shift happen. This change of decision could come to people on a Friday evening, and make the weekends of all the people who had hardcoded the app from a Business to Business use case, really stressful.

Whenever you are faced with a decision of whether to make a compromise or a “quick-fix” for the short term, prefer the longer route and make it scalable. There needs to be a balance of “Don’t Repeat Yourself” and “You Aren’t Gonna Need It.” Trust me, you’ll thank yourself.

Let me give you an example, the web app I was building for institutes teaching coding to their students during the Lockdown, didn’t gather much attention, why? Because I was trying to chase perfection in it and had added a lot of functionalities the end users didn’t need or had completely missed the ones they needed because I hadn’t done my research properly.

Now, I realized the web app would work well with individuals that needed a way to teach coding to students, in a single moment, the whole basis the web app was based on, had changed, and I had to figure out how to get the shift done as soon as possible, which was, of course, made even more difficult by the fact that now the compromises I had made on code quality were hindering my ability to change anything considering how tightly things were coupled inside the system, and how one compromise led to another compromise.

There is a term for this in the software engineering world, Technical Debt, you have to repay it at some point or another, or watch your product meet doom as it gets harder and harder for it to adapt.

Sunken Cost Fallacy

Once you or the management have decided on a change to anything that you deemed was written in stone, the team or you immediately set out to change, in the process, there’s a chance that human psychology will kick in, and just the way compromises or quick-fixes were made in the initial stages of setting a project up, there will be compromises making the change as well because everyone including you and the management wants the changes to not take a lot of time.

After some time, a little progress is made, but the process is still stagnant because there’s just so much coupling to the process. But the changes can’t be reverted now since the team has put so much effort into it, hence, the Sunken Cost Fallacy (“We can’t turn, we have put in so much effort into this already!”) kicks in.

Slowly, you get the changes up, but the process is much slower now. Don’t get into this situation in the first place, you will thank yourself.

Don’t be afraid to venture out

Apple does not have “Computers” in its name anymore because it didn’t want the perception that it was limited to making computers. Imagine this, the technological landscape changes almost completely in a span of a few years, your skills today are not going to be extremely relevant to what the industry needs in a decade or so, just ask all the Backbone or Angular.js developers, they still have demand, but the needs of the industries have been changed by newer technologies.

So is the case with businesses, if a business is based on a niche, the niche will go out of favour sooner or later. Apple makes most of its revenue selling iPhones, not MacBooks even though a MacBook is closer to an actual computer that Apple started with than an iPhone, it has shifted into different domains through the years, and so do all other great companies like Samsung (Don’t even get me started on how many areas they are present in).

Conclusion

In conclusion, this post was a story of personal experience, as well as similar re-callings of a lot of organizations. You might think that apart from the surface stuff, the core ideas of a product or organization might not change that often, and you will be right, they don’t change often, but they do change, and when they do, teams need to be prepared for it.

This is to tell that don’t develop products or build companies where ideas are carved in stone, where a change or pivot tomorrow might require massive amounts of effort, or worse yet, be infeasible because companies do, and will need to pivot at some point or another.