Things learned from reviving a struggling project.
Last year, I was approached by two young grad students with an exciting idea for an online tool - something like a feature flag management. It seemed promising, so after chatting a bit, we agreed it would be a decent tool for CDC pipeline and orchestration engine.
We teamed up for a few months and got a lot done together. As the consulting architect, I helped guide us until we reached our MVP - the point where what we've built is ready to go live.
Back in May, we launched and received some amazing feedback. But then things started to get messy. We paused development to sort out everyone's roles in the project. Eventually, I realised it was best for me to step back, and that’s exactly what I did.
I won’t dive into the details, but everything turned out okay in the end. To keep it brief, those two students connected with me again, built a solid relationship with me, and now I have a project to kick off almost from the ground up.
A few months later, here are the lessons I’ve learned from this experience.
When one of the founders asked me to take over the project, I said “yes” almost instantly. I was familiar with what the project could do, its features, and the market. I had a rough idea about the potential maintenance costs (a lesson learned about dealing with someone else’s code!). Instead of letting it go to someone else, I decided to dive in. And I have no regrets at all.
It’s like a bad dream, honestly. It has over 50,000 lines of code - crazy, right? You really need a lot of patience just to understand what’s happening. On the bright side, the code is pretty clean. The downside? There’s zero documentation. The overall structure makes sense, which is good, but even with that, it’s still pretty complex.
So, I guess you’re getting my point. Figuring out what was going on from a programmer's perspective was a big challenge. But the upside is that, like waking up from a bad dream, once I understood everything, things started to make sense again. I’ll be honest, though - there were moments when I felt completely lost in my own forest of frightening code files.
When you take over someone else's work, it’s super important to keep communication flowing - both inside your team and with the outside world. For me, working on this project meant juggling a few different things. It felt a bit like a circus juggling act.
Luckily, I had the original programmer there to help me when I needed it, which wasn’t too often, and a really patient designer who was open to ideas. Honestly, I can’t imagine how tough it would’ve been if I didn’t have that support. Trying to untangle some of the code on my own would’ve felt like trying to crack a security system - something I’ve never actually tried! 😉
When I started this project, I came up with two scenarios - one was somewhat negative and another that was really negative. I didn’t need to imagine a positive scenario because anything else would be a win.
In case you wonder, I didn’t hit any of my scenarios. Which means things worked out pretty well.
From my experience managing various projects, I've learned a lesson that whatever timeline you set, it’s probably going to take at least two and a half times longer. It’s not about the team.. it’s just that unexpected things happen all the time.
This one applies to pretty much any big project. But it gets extremely important when you take over somebody else’s toy because it gives you time to adapt and adjust to their way of doing things. You can’t just dive in and expect to keep up right away - you need to take some time to understand your new surroundings first.
I had to really pay attention to what I did each day and how I was progressing. I kept a journal for this, which I love because it helps me stay productive. Looking back, some of my entries are pretty funny.
Well, that was it.
I’m going back to my routine activity for the day.
Peace out ✌️
Join RK on Peerlist!
Join amazing folks like RK and thousands of other people in tech.
Create ProfileJoin with RK’s personal invite link.
0
6
0