The great Angular to React migration - technical debt

In photo: Saraswathi Mahal Library (India's oldest library)

The success of Homo Sapiens vis-a-vis their close cousins Neanderthals or Homo Erectus is to some extent attributable to their ability to retain collective knowledge/wisdom and pass them over generations. Needless to say the ability to communicate, document, and make a journal possibly increased the likelihood of survival and favoured by natural selection.

And at Fabrik over years powering through deliverables, we have utterly neglected this one evolutionary advantage that Sapiens have. Until recently we trivialised the need for documentation, nominally using AI to cursorily write and document for us. And used more tools to summarise the writing and documenting - because who's going to read all that.

Introducing Fabrik's technical debt

(More knowledge debt really), where we are paying the price for using old frameworks, generally poor documentation, limited testing and performance benchmarking. I focus more on software development here, but it's true across all functions within the company. This particularly hit us hard when we reorganised ourselves as a part of The great Angular to React migration exercise when we realised knowledge transfer and ramp-up is painfully slow! This was soo bad we had to push out all releases by 6-8 weeks just to standardise knowledge management process (define how we will correct this over the next 3 months) for effort we've put over the years in building Fabrik.

Why? Two words: laissez faire.

In the beginning, we did not know better and knew we were doing a bad code job, but speed and delivery was everything. The laissez faire approach of get stuff done and let our future selves' worry about consequences works really well. It works upto a point, but debt starts collecting if this continues for a longer time. And combine that with the attitude of looking down at anything dull, tedious, and (in our minds) boring because startups are the exact opposite and we have debt.

Startups are supposed to move fast, break things, and ship yesterday, making them inherently risky and cool. It attracts misfits and rebels, the last-benchers who want nothing to do with process or structure. I am one of those and I don't mean this is a negative way, we are the square pegs in the round holes and do not fit anywhere. We grew up with the traditional structure and process route, and we don't want to be there. I had to maintain a passing grade of 60% in school, 60% in pre-university, 60% in undergraduate (no backlogs) to be eligible for placements. I know peers who could not attend placements because they were sick and scored 50% in school - that's process and structure in my mind, and not my cup of tea. And hence we gravitate to startups - small teams, larger than life goals, and few rules. The reward at the end is quite attractive too. And so startups tend to abhor any semblance of structure, and actively work against it because that's not how we do things here.

The heady days

In the beginning, we moved fast and built great software fast with extremely limited resources. We had phenomenal speed and delivery on new gadgets with latest software. The latest and greatest generally have little or no documentation (highly relateable) and puts us on an even footing with the biggies in the sector. It is exhilarating to be one of the early movers delivering solutions. And because it's a new category with a new way of doing things, you are generally excused for not having a good process. Getting that one additional customer, one more user, and one more validation with on a shoestring budget kept us going. We move soo fast, nothing much is documented and this approach works creating technical debt. It's all in the mind.

The debt catches up

Fast forward 12-18 months, with traction and a few customers adopting one of the few experiments that worked, it is the first real chance to add a couple of zeros to the valuation but more importantly, an opportunity to make a difference. As we hold on to the opportunity with dear life, we are no longer the square peg in round hole, we are the first-benchers respected and admired for innovation and foresight of the future. With that comes scaling the solution to a larger audience, and the very anti-establishment mindset that worked until this point melts away.

Rebel without a cause

At this point, we had two choices:

1. Continue to operate the way we've always done - easy (not anti-establishment but anti-process or anti-structure or anti-testing or any other villian),
2. Or begin the painful process of transformation - incredibly hard.

Not hard to guess what we did - we chose the first one. With traction and a slightly larger team, we had to build a better organisation, and take a structured approach to all our activities with some measurable metrics. But we said "eh, screw it." and continued our laissez faire attitude. The correction here was far less painful than today. As we continued to scale, we added more features for more customers in different forms of deployment, but did not have clear guidelines on things like:

1. What works?
2. Why did we get here?
3. How things works?
4. Why this? Why not that?
5. Can I read about it?
6. How can we test?
7. What happens when libraries upgrade?
8. Can you benchmark performance against so and so?
9. Why should we choose you versus so and so?
10. How can I ramp up quickly and start delivering for you?

And for everything, our answer was "Here's our codebase, you have 2-4 weeks. That's our trial-by-fire, this is the real world and get used to it. Good luck.".

Things still work ofcourse, we were still not far away (time) from what we wrote and we can still patch things up while the team ramps-up - it usually takes a few hours while the new team takes a few days. In the meanwhile, the new team we've onboarded is under pressure to deliver and apply more band-aids on code that's barely holding up just to keep up. All nighters and last minute coding spree still saved the day for on-time delivery.

We skirted around the obvious during introspection time - talking more about not doing enough "donkey's work" and "snowflakes" find it hard to catch-up, or blaming the Gen-Z, the graduates from the pandemic era, and our ability to hire, compensate, and retain quality talent. There was more of"What's he/she doing?" and plenty of other blame to go around. And none of this worked, we stopped the process of introspecting as well with every person working on their own assuming everybody else is just freeloading. We stopped the tough conversations because we got tired of confrontation and hurting others' feelings.

Breaking point, when the fatigue sets-in.

Our breaking point was when fatigue set in. We saw our competitors moving faster, we couldn't move fast enough, not as fast as the early days, we had the feeling of the our best being behind us. With a lot of redoing and fixing the same thing over and over again we resigned to the fact that the team just cannot ramp-up and it's a waste of time training them (I think this is when a solodev is born). On the flip side, sales was having an easier time with increasing customer traction, more use-cases, and a shorter time to market. Customers ask for custom deployments in different environments, minor feature requests, and faster turnarounds. Every change or fix from sales is long-drawn debate since that requires incredible code changes on the platform, requiring more testing, more process and documentation. It is almost impossible to ramp-up new teams to take over, and existing teams known for speedy execution take weeks to deliver capabilities that looks like a few days of effort from the outside, and these deliverables barely hold up. At the end, everybody is tired.

The second-order consequences: With our inability to match speed showcased in the early days, customers lose confidence, delay subsequent orders and impact payment cycles disrupting cashflow and revenues. We don't meet our revenue milestones blocking our ability to raise outside capital, and the constant firefighting in operations and deliverables exacerbates this situation.

Fabrik's funk in 2024.

This has been Fabrik's 2024. We would've done well to learn from peers, bigger companies, or just about anytime in our childhood where we stuck with a structured program for almost everything we did. And through this year, we constantly believed we do not have the right tools (a better CRM, a good notes sharing app, etc.) that's making this job harder, especially in this day of AI-powered everything. We naturally assume people are busy doing many things in parallel that they don't have the bandwidth to put this together. Tools are not the problem, it is the intent and the willingness to transform from the plucky, punch above your weight startup into a plucky, punch above your weight business becoming more organised, structured, and process-oriented.

2025 and beyond.

As I write this, we have started with the second path (the painful process of transformation) and we are far from being a well-oiled machine, but I think the structure and paper trail is needed to enable a larger team to move faster. The internal reorganisation will create clarity in our minds and defines clear handoff points between different teams identifying owners (instead of "it's too hard for him/her, I'll do it myself."). Combine that with a strong knowledge capture mechanism with robust testing, performance benchmarks, automation, and accountability should evolve the platform to stay competitive in the upcoming years.