Feature Request - Initial steps

When you’re working with a team on a software project, there needs to be some type of process to determine what gets built. If you’re on a larger team, people who don’t deal with the software will want to see changes made. This section is tailored towards helping you understand how to initially approach those situations so that you can build the correct software. Fair warning, it’s all about communication.

Understand the customer’s need #

Start with understanding the customer’s need. Misunderstandings lead to most problems and misunderstandings come from miscommunication. I’ve found that being consistent with using the same terminology is a good starting point. From there ask questions, repeat answers and confirm your assumptions. If something seems a little odd, follow up on it. A fifteen-minute conversation now is much better than throwing away a week’s worth of work.

Keep in mind the feature being requested may be to alleviate a symptom of an underlying problem. Your goal as a software engineer should be to fix these underlying problems. The surface level, symptomatic stuff can be easy and appealing, but you only get to amazing and “can’t live without it” software by solving the problems the user didn’t know they had. Now go find them!

What is the current experience? #

Try to understand what the current workflow is. To properly gauge the value and assess the change, you need to know what the baseline is. Depending on the context of the change, you may need to know how many clicks a user has to perform, how long does the code take to run, or what does the output look like. It can be helpful to document these workflows with either screenshots or in a sequence diagram.

What is the desired experience? #

Confirm with your customer what they want the change to do. Avoid agreeing to subjective descriptions or measurements. If something is “slow” you may need to measure it first and confirm that it is slow. Then determine what “fixed” would be. If they want an updated user flow, ask them to annotate screenshots or create a video. The clearer your communication, the happier everyone will be.

Is this something that should be done morally and ethically? #

Software (currently) doesn’t get built and deployed without a human. You have the responsibility to ask, is this software good? And I don’t mean, does it run well. I mean is it morally and ethically good software? There are nuances to all our decisions and lives. We may have different value systems. Please apply yours to what you’re being asked to build.

Ask questions.

Who needs to be involved? #

If you know this change impacts Sam and their department, please make sure that Sam is aware of this change. If you’re not sure of the impacts and the task made its way to your desk, it’s time to start asking who is impacted by this. If you’re new, ask a more seasoned coworker. If you’re in a silo, ask your manager or team leader. Your goal is to deliver expected software without surprises. Good or bad. So communicate and communicate early.