Three months get estimated. After six months the team actually finishes the job. Known pains were traded for unknown ones while business-relevant features had to be put on hold.
You’ve watched this movie. You may have pitched it once or twice. I certainly have. The promises of “just imagine that pain being gone” are too tempting. It feels like a long-term solution to “finally get this right”.
And it’s also a trap. It’s a now solution in a long-term dress. Nobody can guarantee that after the rebuild things will be better overall. Worse: nobody can say in what way things will be different and thus what things will be worse.
Because some things will be worse.
You still reach for it. Because it feels like control. It feels like empowerment to get to do big changes. To change fundamental aspects of an app. It’s exciting.
It’s easy to imagine a world where that specific pain of that component is just gone. Imagination stops here, because it’s hard to deal with unknown unknowns.
Why it’s hard to be the one who says no
At a Series B/C scale-up, typically three roles can say no: the CTO, the PM, and the iOS lead.
For most CTOs and the PMs, iOS technicalities are a black box. From the outside, it’s hard to find different approaches to address the feeling the team has.
For the iOS lead, the pain might be real. Either because they themselves feel it or because their team complains. It’s either directly personal pain or a no might be perceived as criticism of the team member.
The feeling usually is right that something needs changing. And rewriting is usually not the best solution.
The feeling that something needs to change
One important thing about this: it’s a feeling. It’s not the brain talking. So it’s important to get it back into the discussion and to put it where it has the biggest lever:
Not how to do the rebuild. Whether to do a rebuild and what other options there are.
That is your job as a lead.
How to find out whether it’s actually a good idea
There is one central question: has the code base hit a provable limit?
That can come in multiple shapes. E.g.
- A feature on the roadmap can simply not be done.
- A load bearing dependency is dying.
- Adding a new feature would end in a “shotgun surgery”.
- The company’s business model changed and the app still makes old assumptions.
Those are good reasons to consider a rebuild.
Considering means: can you verify? Can you prove?
Actually verify
Admittedly this is hard. It’s hard to challenge a belief that has found roots. Your own or your team’s.
Don’t do it to harass the team. Be upfront that you’re not questioning their competence, but to get fresh ideas in. That you want to do things right.
Some things don’t need a lot of proving. If CocoaPods is getting sunsetted, that’s it. Others do: what does it mean when you say “a feature can’t be done”? How much impact are you talking when you say “shotgun surgery”? What do you actually mean when you say “technical debt”?
What happens when you skip it
I once watched a team go the rebuild route. They asked for three months. After six they were still not done and asked for an extension. The PM got worried and asked two engineers from another team to take a look covertly. They had a hunch that building a feature without the requested rebuild surely must be possible and were curious to see what they were missing. So they decided to build the feature to understand the problem and the rebuild rationale. They finished the feature in two weeks. No rebuild. That was a big oops to communicate to the client.
Don’t skip verification.
And most probably you’ll end up with the following conclusion: a rebuild is not the only way to go.
Here’s what to do instead:
Move from solution-thinking back to problem-thinking
You and your team are facing pain and jumped to the idea “what if we remove the pain”.
A “rebuild” is a solution. “Component X is fragile” is a problem. What’s your problem?
In this example: why is it fragile? What’s the smallest possible change that changes the picture? What happens if you iterate on that thought instead?
Just saying “we need a rebuild” signals a lack of imagination. Find ways to get it back to the table.
Don’t fixate on a solution early. You don’t know yet whether you can come up with something that’s even better. Hold that thought and use that way of thinking to make that process exciting.
Bring the excitement to a small solution that otherwise might look boring. Help your team get on board. Part of the allure of a rebuild is the feeling of having an impact. Even an objectively better solution might get less support in the team if they feel like they can’t do big changes. Yes, even “rational engineers” are driven by emotion.
For the rare case when the rebuild is valid
Once you have confirmed that yes, a rebuild is a valid option, how do you make sure you don’t make the new solution just as bad, but different?
Something to be aware of: the same people who built v1 are now planning to build v2. Yes, things were learned. It’s reasonable to assume the result is better. But will it be good?
To avoid a blind trade, use the same thought process from above. Think about alternatives. Evaluate them. Find the drawbacks.
Can you show a paper trail if the CTO knocks on the door and wants to know why things are taking so long? Can you migrate slowly and thus keep on delivering business value?
Yes, I’m asking you to add effort to an already big topic. However, not doing those things will throw away a big learning opportunity. And you’re likelier to get sign-off if the team keeps shipping value during the transition, not just rebuilding. And you probably will only get one chance in rebuilding this part of the code base. Make it count.
Back to the two engineers from above
They shipped the feature in two weeks. Instead of chasing a distraction, they asked what the rebuild was actually for, and then went and checked. That’s the job. Being and staying curious.
The version that worked was boring. Or exciting. Depending how you look at it.
Your choice.