A lot of developers think that code is the thing they sell.
That's not true.
I learned one lesson about being a great software engineer: reducing scope.
Scope creep is the root of project management evil, and software developers are historically bad at estimations. Thus, our only remedy is to make the project smaller - by reducing the scope.
Agile software development has taught us the importance of early and continuous delivery. As a result, the agile principles tell us to reduce the scope, ship our product in a minimum viable product, and work in incremental change.
Understanding the Why
As an engineer, your job is understanding the problem (NOT the proposed solution).
Customers think they know what they want. Often, they don't know what they want. Many customers will try to "self-diagnose" a problem in the market and ask you to implement the solution immediately.
A product manager once asks me to add a new row in our internal database to detect anomalies in a cron job. After asking her "Why" and the problems she encountered, we understood the problem was not the anomaly in the database but the huge memory we needed to acquire during the job run. A simple logic change within the code ended solves the problems.
As Jonathan Stark says, it's like visiting a doctor and saying:
"Hey, doc! My chest has been hurting. I googled around, and apparently, I need a triple bypass. When can we start?"
Customer loves to self-prescribe. They think they know the solution. However, your job as an engineer is to understand the purpose of the proposed solution.
Ask questions such as:
What does the customer hope will change before and after this project?
Why are we trying to do X right now?
What if we don't do the project or do something much smaller? What's at stake & why is the project scoped this way?
Focus on the Problem
Once you understand the "why" of the problem, you must guide the customer to the correct solution.
When trying to solve a solution, understand the minimal effort you can make to achieve that solution.
For instance, the product manager wants you to implement a ticketing queue system to create a better customer experience during customer service. You ask why. The product manager tells you that the problem is that the customer doesn't have the patience to wait during asking for customer service. Now you know that the assumption of the problem is the "wait time."
"Is there an early indication that the bad customer service is due to wait time? Is there a small product that you can build that addresses this issue? What about a quick survey on the customer to understand if the wait time is indeed the issue before creating a ticketing service?"
If the problem is the "wait time," is there a possible way for you to create a FAQ site so that customers can get the answer to the common problems instead of waiting in line? Will that help elevate the "wait time" issue since more customers can get the result from a single FAQ page?
Focusing on the problem, breaking them down into smaller fundamentals, and deliberately thinking of other solutions that decrease the amount of code written can result in an interesting solution.
As a result, you help save your team's engineering resources time and effort and reach the desired goals for the customer pain points.
Think about a smaller product that indicates the "Why' is true.
Reuse Some of the Existing Service
Before even thinking about implementing a new service or feature, think about if there is any existing feature that we can reuse.
The cost of building a new feature is high. To start a new microservice, you must spin up a new infrastructure and monitoring component and consider various failure modes.
As an application grows in usage and functionality, it becomes more complex, and more developers are needed to maintain and develop it. Reusing some of the existing services and functions helps decrease the complexity of the codebase and cuts down time for application development.
Reusing some of the existing services also reduces developer time spent on maintenance. It's much easier to understand and fix a software system that is modular and composed of components. A developer can focus on the specific component that needs to be changed or fixed in a small and specific way rather than drown in complicated projects that take a long time and effort to understand and fix.
Use Messaging
A product manager asked me to design a cash-back reward. A referee can be rewarded once the referrer goes through the transaction funnel.
I encounter a problem during the design phase of the system. Our service cannot be responsive in telling the referrer that the referee has booked because there is no event-driven system to account for referee transaction events. We can use a scheduler-like method to check if the referee has transacted through the ETL table.
Instead of building a transaction-listener service that will listen to transaction events, which will take a higher level of effort, I decided to cut down the scope by asking the product manager if it is okay to give a message that "Referrer rewards will reflect in their dashboard within 48 hours".
Messaging can go a long way and cut down engineer scope.
As long as you tell the customer ahead of time that a delay or something wrong is happening, 80% of the time, they will understand.
A bad experience happens when they are surprised by the interaction of the service due to a lack of communication.
If some features are hard to implement, consider negotiating to see if we can tell the customer what to expect.
Recap
Aside from writing code, software engineers need to reduce the uncertainty of project estimates. Numerous misconceptions exist that our job is a top-down approach, where we are the implementer. In reality, our job is to help guide the product manager on how to solve problems.
Embracing the concept of reducing scope empowers software development teams to optimize their resources, enhance efficiency, and deliver valuable solutions. By focusing on the core problems and delivering maximum value to customers, projects can achieve success and contribute to the growth and satisfaction of all stakeholders involved.
When in doubt, reduce scope. The rest will work itself out.
💡 Want more actionable advice about Software engineering?
I’m Edward. I started writing as a Software Engineer at Disney Streaming Service, trying to document my learnings as I step into a Senior role. I write about functional programming, Scala, distributed systems, and careers-development.
Subscribe to the FREE newsletter to get actionable advice every week and topics about Scala, Functional Programming, and Distributed Systems: https://pathtosenior.substack.com/
Top comments (0)