Feature Request - Estimate the cost

We can make a computer do almost anything. It’s what makes software engineering fun. However, some things take more effort than it’s worth. This section will help you contemplate how to assess the effort associated with a proposed idea.

What does the maintenance look like?

Maintenance can look like many things. Sometimes it’ll be something easy to identify, such as a known exception case that needs to be manually resolved. Merging data is another good example. In others, it’s less obvious; such as how often does a dependency get updated requiring you to revalidate it? Over time, you’ll get a feel for knowing how often something will need to be touched in the future. I’ve found a good indicator to be, the more obscure the logic and the more hacky the solution, the more often I will need to come back to it. Keep in mind, being high maintenance shouldn’t prevent you from implementing it. It should be weighed when considering what you’d like to be working on in the future though.

Does this impact other flows?

You should try to think of other user flows that will be impacted by this change. You don’t have to think outside the box, but the answers won’t be inside it either. It’s more of thinking along the edges of the box. Where does it touch other boxes? Cross-cutting logic like data access is easy to assess; it touches everything. Less easy is when the feature request proposes a new field on the update profile page, but mention the sign-up page. Does that need to be updated too? Or is this something that you’ll need to tell the user to fill out after creating an account? There are no right answers here. Strive to make good decisions with the information available now.

What are the exception flows?

Most feature requests will primarily talk about the happy flow. How something will work when everything goes, according to plan. And I have yet to find a happy path that doesn’t make sense. The trouble is that there are exception flows. What if the user enters a letter in the price field? What if the user tries to inject some SQL in an input? What if the user misinterprets the label “Name” to mean their name rather than the name of the object? Here’s where you need to think outside the box. Consider how things could fail from the user, to the network, to concurrent requests.

You are a technically knowledgeable person. The business will rely on you to imagine how things could break. They are also going to ask you how likely something will actually occur. Yes, AWS could experience an outage, but that probably doesn’t mean you should build redundant infrastructure to Google Cloud (unless you’re at that scale). But maybe you should plan on retrying a database connection if a db connection gets dropped on the wire.

Keep in mind that as a technically knowledgeable person, you hold extra sway during discussions. You can make any idea seem like a bad one if you bring up enough possible problems. This is being a bad teammate and colleague. Yes, you have the responsibility to educate folks on risks and difficulties, but at the end of the day, you’re there to ship features. Don’t be a curmudgeon but don’t simply go with the flow either

What are the assumptions and what happens when those aren’t true?

A great way to identify an exception flow is to take an implicit assumption, break it, then see how the feature holds up. A common one for the web is, “what if the person is accessing the application with a slow internet speed or a ancient computer?” Others may be around the accessibility of the UI. Is the contrast great enough for a person with a visual impairment? What happens if a user doesn’t know what your form labels mean? In that case, maybe you add a “help” link nearby that pops up a more thorough explanation.

Be aware, this can seen as playing Devil’s Advocate. You will need to balance how often you raise these concerns with others to avoid being the person who can only see the negative.

What are the error states and their next steps?

There will be times when you willfully write code that allows data to enter a state that only manual intervention can bring it out. There will also be times when you unknowingly write code that does so. Try to avoid the latter. It’s fine to require manual operations to manage an application. Please remember that it’s less than ideal to cause someone hours of customer service work because of an oversight.

Does this require monitoring?

This is probably an obvious answer given the nature of software to measure everything and collect as much data as possible. However, it’s still a valid question to ask. How do you know if those advanced filtering options that were added are useful? Or perhaps you’d like to remove a feature. It’d be a lot safer to remove it if you knew for a fact nobody would notice it’s gone. Or perhaps the feature request is proposed to refactor a subsystem because it feels slow. Find your evidence.

Will this remove or add technical debt?

If you’re not familiar with technical debt, it’s the idea that you write code now at the expense of making future code harder to write. In other words, you’re writing hacks. But hey, hacks pay the bills and make the world go around. Everything is built with duct tape and gum. Less jokingly, I think technical debt is accumulated because our understanding of the problem is ever evolving. How can you write debt-free code if the goal posts are moving?

When considering a feature request, you should imagine where could things change in the future and what decisions are being made now that are brittle? A good place to focus on here is the data model. Changes to the data model are difficult to implement in a mature app since it means everything on top of that layer may change.

On the flip side, is this change close enough to an area you know that needs refactoring? Maybe it’s asking to add a new field to a form that has some ancient validators that are due for a refresh. You’re likely in a unique position to know what the parts of the codebase the company should invest in to be more efficient. And sometimes, a change is just enough of a reason to finally do that large refactor that has been hamstringing your team for years. Those PRs are glorious to merge.

Does this unlock future solutions?

Most of the job is explaining why a change shouldn’t be made. It can be demoralizing at times. Then there are those days when the stars align, and you get the opportunity to explain why a feature request is going to revolutionize the project. Or at least how it’s the first step to revolution. Most of your job should involve the information and data you have today. Not the information and data you expect to have in a year. However, that doesn’t mean you can’t point out the positive side effects of a potential change. Folks don’t always recognize that features have entered the realm of possibility. When you make them aware of what’s possible, it can lead to further innovation and change. An easy highlight of my day is giving someone else reason to envision a better product in the future.