As a developer, feature requests are a fact of life and one’s stress level may vary based on the complexity of the requests you receive. So what’s the best way to handle a feature request? Well, I’m not sure if there’s a best way, but here’s how I do it.
Understand the Need
The first step when I tackle a feature request is to thoroughly understand what the request is really about. People rarely have the ability to articulate exactly what they need, but are great at giving you just enough details — in small bursts — to figure it out if you carefully investigate their use case.
If you’re unsure of what they’re really trying to accomplish, ask for clarification. It’s better to spend more time up-front finding out what you really need to do than it is to rewrite your changes later. If you find yourself frequently modifying new code based on additional requests shortly after writing it then you may need to work on your communication.
Slow down, ask questions, try to get it right the first time. It’s not always as simple as a specification document (assuming you have one).
Understand the Code
Now that you understand the request, it’s time to analyze the code. Let’s be real, very few people can keep their entire codebase in their mind. Read through your code. Like a book. Follow function calls, property setters, everything. Make sure you understand what you’re modifying before you proceed, and look for the areas you’ll need to modify.
Sometimes this is much easier than others depending on the complexity of the project. And take notes! This step is especially important if you’re working on Other People’s Code (OPC).
Understand the Path
Next, develop a plan. Since you’ve read through code and, presumably, developed some ideas on the best way to implement, develop your own specification for the change. Give yourself time to fully work out the new implementation — I use private notes in my support system for wrapping my head around everything, which has the benefit of giving me greater insight if I need to come back later for some reason.
Work out the path forward before you ever modify any code by noting where you’ll make changes and what those changes might entail, keeping in mind that your previous functionality should continue to work as expected. This might involve creating new code paths specifically for the new feature to ensure that you don’t break old, working code. It’s also important to note things outside the scope of the new feature that you’ll need to test afterward to be sure that you didn’t break anything.
Build the Road
After you have a plan, it’s time to start building. If your strategy has been adequately outlined and you enjoy writing code, this is probably the most fun part. Follow your plan and make changes as you’ve outlined them. Be on the lookout for edge cases or caveats that you may have missed in your specification notes, chances are that they do exist.
Test Everything
Finally, testing! Don’t just test the new feature, test the old functionality as well. It’s common that feature requests require modifying existing systems and you don’t want to push out that new release with a cool new feature only to have existing functionality break. Your work will look rushed and careless, and that’s worse than it taking a bit longer to complete.
Bonus Tip
Know when to rewrite. Over time codebases can become monolithic and overly complex based on continually adding features that were never considered when the project or features being modified were first created. If you find yourself spending more and more time trying to understand your code paths or fixing old functionality that new features break, it may be time to develop a new project specification and start from scratch. Don’t be afraid of tossing out something that causes you endless headaches to modify.
Conclusion
Whether working in a team or solo, a slow and methodical approach to feature requests will ensure that your changes last and customers are happy. Don’t rely on code reviews to catch issues or multiple requests after the fact to get everything right. You’ll make mistakes and miss things, but your work will be much better received with a little additional care.