Six months of work down the drain
If you’ve worked for enough time there’s a pretty good chance you’ve encountered this situation. It is a near certainty that we all have to experience it eventually. Sometimes more than once. But the most important aspect is how you handle it.
Let’s go back in time to early 2017. Someone comes up with a brilliant idea to improve the responsiveness of the android app we’re working on. He works on a prototype, it looks ok, and together with the manager we create tasks to implement the solution on a part of the application. This is by no means an easy task, there’s a lot of refactoring involved. I’m super excited about the endeavour and I get to be the lucky one implementing it.
Our release cycles are pretty short and the team I’m working in has a lot of features lined up beside this one. I talk to my manager and together we come up with a plan to implement this in parallel with the features, because if we freeze the code it will stop at least 10 important product changes from being delivered on time. I estimate the tasks to take 2–3 release cycles and get started coding.
All is well, refactoring somehow gives a sense of calmness and pride. Like when you’re cleaning out your garage and organise your tools, put everything where it belongs (now you can call your friends over and not be ashamed of the dirt that’s been gathering on the selfs for the last 5 years).
Suddenly reality kicks in when I’m merging changes from master back into my refactor branch. Whoooa! I need to resolve these conflicts. No problem! I’ve dealt with worse, I just need to understand what this code does first. I learn what I can about the feature that was merged before my refactor, resolve the conflicts, and reimplement the feature with the new structure.
Over the next couple of release cycles I repeat the conflict resolving routine. Lately, I don’t even do anything new, just keep up with the new features until the refactor is merged back.
It’s finally merged! Now I can start working on the feature itself.
Another release cycle goes by fixing issues reported on the refactor. It’s been six months. The feature is in place, the AB test controlling it is off for now until some minor wrinkles are sorted out. Everyone originally on the planning team is anxious to get the impact report that shows users are happier with this new version.
Moving on to the next feature the whole team realises that we’ve been working on this big refactor for nothing, because the newest set of features are incompatible with the optimisation.
Bummer…
Normally, any sane developer would insist that their solution is better than these new features.
I didn’t even realise how bad this is until my manager tiptoed around the subject hoping I won’t be mad about it being dropped. Colleagues pointed out in some discussions that I won’t be happy about it being removed, even after a couple of months.
I learned a lot during this time, like how to manage big refactors in parallel with feature development, and really trying to understand other’s code. Of course, I wish we had the insight not to get started down this path, but that’s the beauty of life: you never know what’s next.
Most importantly I learned that I stopped being so emotionally invested in what I build, I don’t even know when. If it’s good and it satisfies product requirements, I’m happy. If it turns out that product requirements changed so much that it’s no longer needed, at least I had fun building it.
Being proud of what you’ve built is great, just don’t let it dominate your judgement, and learn how to let go when necessary.
Time is never wasted.
