Don't be a hero

The stack is just like a stack, although a bit old. But I still wanted to move and here’s why:

  • Slow code.

  • Memory leaks.

  • Bad DX.

  • Legacy technologies that are difficult to hire people for.

  • Problems with onboarding.

  • Long pipelines – deployment could take 1-2 hours.

Everything would be fine, but besides the reasons, we also had a reason – on December 31, 2023, support for Vue2 was stopped, which further aggravated the existing reasons.

Coordination

After discussing all this with the CTO, I came up with a simple migration plan:

  1. Cut out the old one.

  2. Updating dependencies.

  3. We're moving.

The task is understandable, but time-consuming, because there was a lot of stuff to cut out. For example, we didn’t want to move to Nuxt 3, because in general we don’t need it – the system is closed, SSR is unjustified.

After evaluating the plan, the CTO determined that it was a generally safe option, but potentially endless. Therefore, he suggested an alternative – simply create a new project and copy-paste the code there, throwing out everything unnecessary.

Adventure for 20 minutes

Adventure for 20 minutes

I'm a sucker for such things. They tell me that you can throw out the old and make a new one – I agree. Spoiler: in vain.

No miracle happened

No miracle happened

And to explain why the CTO even proposed this option, we need to make a few digressions:

  1. CTO is luckier than me. For example, we went scuba diving together. He felt unwell, he made a gesture to the instructor and they lifted him up. And I almost died that day (kulstories on request).

  2. CTO is a workaholic, best described by his own quote: “Finally, it’s the weekend, I can work properly.” When evaluating, he simply multiplied his efficiency by the number of people in the front-end team.

  3. The CTO didn't touch the front for over a year.

And this is my first mistake:

Ignored red flags when planning.

But the process has already started

I divided the move into 120 tasks, created a table in the wiki so as not to duplicate components, and we began the move. According to the initial estimate, a month should have been enough.

A month later, I reported on the successful completion of 80 tasks out of 120. Not a fountain of course, but we were approved for an additional month, so we continued the migration.

At this time I realized that a month was not enough for us:

  • People spend a long time fiddling with tasks.

  • It is difficult to conduct a review.

  • Some components are duplicated, despite the table.

And this is my second mistake:

The tasks are too big.

There was nothing left but decompose them.

And now, a month later, I report that we have completed 130 out of 160 tasks.

A month later there were already closed tasks 160 out of 200.

I won’t beat around the bush and say right away that in the end we spent 350 tasks on the move + a bunch more were spent on bugfixes.

A lot of tasks

A lot of tasks

We can't cope

At this point I started to burn out, because people Badly managed despite my efforts. To save the situation, I decided to throw all my strength into this and also started writing code:

Worked for three

Worked for three

And this is my third mistake:

Worked with code when needed to work with a team.

The move is over

Despite the pain, burnout and extended deadlines, we still completed the move. In total, it took 30 man-months instead of 8.

We got a new stack:

  • Vue 3.

  • Element plus.

  • Bootstrap (drank in the process)

  • amCharts 4 and 5 (almost everything is 5).

  • Vite.

  • Vitest.

  • Better bikes.

The indicators have also improved significantly:

  • Dev build in a second, not in 2 minutes.

  • Memory consumption is 2 times less.

  • Improved DX.

  • Latest dependency versions.

  • Deploy in 7 minutes, not an hour.

What have we learned

Just three simple points:

  1. Uninvolved people should not influence planning.

  2. Decompose.

  3. Working with people is more effective than working with code.

That's all?

Some conclusions are at the junior team leader level and from the category “Do well, but don’t do bad.”

Lenten crap

Lenten crap

What really happened? And why were other companies able to move much faster than us?

And the answer is actually very simple – because we were a startup quite recently. And startups survive due to such practices as hero engineering – when you work as hard as you can to solve any problem. Be it dropped sales or unrealistic deadlines.

And here we have a little flashback:

People Badly managed despite my efforts.

But in reality, everything was a little different:

People worked not enoughto complete the move on time.

And it’s even hard to blame these people. They weren’t the ones who agreed on the deadlines, they weren’t the ones who started such a long marathon in which hero engineering stops working because everyone is already exhausted.

And in general, this is a practice that really shoots you in the foot over a long distance. It's like having a person bailing water out of your boat 24/7, when you could have simply repaired the hole.

And this is my real mistake:

Play a hero to hide management's mistakes.

Present conclusion

Don't be heroes!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *