Notes from taming a hairy feature
Reflecting back on the 2 months spent working on an expansive feature gave me some new insights and also corroborated my beliefs in some existing practices.
TL;DR: Get all the help you can. Question Everything.
Despite giving due diligence to tech design, in hindsight, it still wasn’t enough. And hence, lesson #1 -
Get as many opinions as you can.
Even after considering several angles and trade offs, there were insights to better design that I got while working on the feature. These should have come up earlier. Reading through every area of possible touch-points in the codebase makes for a more informed estimate.
Estimating the feature got me perplexed about a final completion date. Drawing a map of everything on a white board helped a lot. Discussing tech design with peers became easier. Story break-down became evident. Chalking up a release plan became easier. So lesson #2 -
Break it down. Then forget about it.
Focussing on only the next task kept me from getting overwhelmed with the scope. Any other requirements that crept in were automatically put to the end of the queue.
I also found setting aside time to constantly assess the situation to be very helpful (Hence, these notes). I prefer to do this at the end of the day while not working. Listing down tasks for the next day and marking them by priority always helped me keep track of how productive each day was.
Some questions that helped this thought process — What is taking longer? What can be dropped or picked up later? Who do I need to ask for help/opinions? Who needs to be told about bottlenecks? Can any items be re-prioritized?
While wrapping my head around all the nuances of the feature I did not stop to find the small wins. In other words, asking -
What can users experience right away?
Yes, the feature was huge. None of it’s several individual pieces could be used without the other. But that is one saw I am keen on sharpening in future sprints. My action plan is fairly simple -
Question everything
Why does something have to be designed a particular way? Is all of it absolutely required in the first iteration? Can it be toned down? Are any important design decisions lurking around the corner? What existing experiences are disrupted for the user?
Release Often
Looking back, deploying to production often was immensely helpful. My colleague Vinod’s post describes better how delinking deployments and releasing to customers makes feature releases a non-event. It’s a different thing that celebrating is part of our culture… and so we did.
This helped getting code reviews in smaller chunks. And the effort of manually testing in production continuously also became manageable.
Nail the UI first.
The experience of the solution and the look-and-feel is what a user interacts with first. Not your API end point. Also, it becomes much more easier to make iterative improvements further down the line. Which also mean the more important share of UX review inputs come much earlier and you can take them on in little chunks along the way.
Test everything. Despite the urge not to.
Let’s admit it. We do face a lot of friction while TDD-ing code. Maybe that’s because we are still evolving our tools. And the know-how for testing every kind of scenario is not yet internalized.
But a part of me feels relieved when I make changes and several tests break. That’s a good sign. Even though it can get frustrating sometimes when all you want to do is forge ahead.
Thank you for reading so far. Back to work.
Originally published at inside.recruiterbox.com on May 25, 2016.
