Reworking features

It’s a real pleasure to work on “someone else’s” code — the underestimated feature produced by your coworker, who, as everyone in our industry, worked under time and inner pressure. Usually such features are delivered with the last drop of energy — so end up with many bugs and corners cut. The code is messy, probably lack many tests and with tackled dependencies. But working with this code is a pleasure for real because you already know more…

Let’s retrospect what happened from the very beginning of the feature till now.

1. Business saw a pattern in their analytics, gut, sign from God or whatever which became draft of the feature.
2. The MVP of feature was specified, its KPI defined
3. The MVP was delivered with least possible effort, turned out to meet some of the user’s expectations.
4. So feature is honed to meet those expectations. Of course it’s iterative, but somehow it was estimated to be X days at the beginning, and end up with 5X.

Most of the time both business people and developers didn’t know what’s the actual feature, how much is it worth etc. And now you know it. It may be predicted how much money your work will add to the company. You can also see some refactoring opportunities and wider architectural context of this feature.

Yes, you’ll get your hands dirty, find some stupid bugs and sometimes spend too much time reverse-engineering tests, but still you’re the lucky one. You can use your skills, craft in your hands and make this small piece of the system better place. If it’s worth it.