Scope
This week I was asked to justify a development estimate by a product manager. As context, the project had undergone weeks of planning and proposal, and it's now under active development by yours truly. I gave an honest estimate of about 4-6 weeks, including coding, review, and testing. This estimate surprised the product team. The product team's surprise in turn surprised me. Why the mutual surprise?
What's in an estimate, anyway?
This was part of the line of questioning from my product manager: how does 4-6 weeks break down per component of the project? That line of questioning misses the forest for the trees. On the face of it, it makes a certain sense: at the end of the project, I could look back and count how many hours I spent coding each component. That would give a concrete and empirical answer to the question.
In an estimate, I sometimes use a similar heuristic. If I am tasked to build a new feature, I could for example compose an estimate as follows:
- 1-2 days coding the data model
- 1-2 days coding the UI
- 1-2 days review and testing
Amounting to about a week timeline. This type of estimate works well, until it doesn't. In a mature codebase, like the one I work on, seemingly simple features can take weeks or months to build. The reason for this is the complexity.
Complexity is the enemy
Complexity is invisible to product and stakeholders. From the outside looking in, my car seems fairly simple: there's a steering wheel and gear stick, and some pedals by my feet. Behind the simple interface there is a swatch of complexity: imagine my surprise that replacing my clutch pad costs thousands because the transmission has to be removed to access the underlying parts. What I believed naively to be replacing a pedal is a complex mechanical operation.
Similarly for non-technical folks, the cost (in terms of time rather than money typically) to maintain or change software features can be surprising, as the product manager can attest. The feature request - adding a second option to a selector - seems so simple! I had to explain the underlying complexity, just as my mechanic friend had to explain the same to me about my clutch. Here are some contributing factors:
- The initial design was not extendable, i.e. the old feature has to be removed in order to build the new. This is more challenging than building from scratch, especially when mobile application APIs have to remain backwards compatible.
- Several levers for customization: each option in the selector has customizable properties that affect both display and functionality.
- Bespoke UI: rather than leveraging the design system, there are custom UI components.
Each of these adds considerable complexity, and therefore effort and timeline.
Talk about scope
It's my opinion that scope should be a top concern in project proposals. This is a lesson that I've taken to heart from my boss, who strongly advocates for a focus on ROI in software projects. What I've found in my experience is that it's easy to discuss scope at the outset of a project, when it's most abstract: "we want to launch this by end of the month!" But the devil is in the details when having to make hard decisions, that is say "no" to stakeholders. In the example of my current project, this could have meant eliminating some of the customization options or leveraging the design system.
As an engineer, it's my responsibility to inform product about the impact to scope for these types of decisions. If there are shortcuts, or 80-20 opportunities, then I will advocate for them - as I believe a feature shipped quickly and imperfectly is better than a feature shipped late and "perfect" (but let's not kid ourselves, there's no perfect feature launch!). As it goes, I did make these suggestions during this project's proposal process, and the suggestions were rejected. Hence my surprise at their surprise.
Final thoughts
I'm in a stage of my life where I am learning to let go. I firmly believe in personal excellence, in doing the best that I can. To that end, I committed myself to delivering this project according to my estimate. But when it comes to soft pushback on the timeline, I don't feel responsible, i.e. pushing myself to work longer hours/weekends to deliver sooner. The project will be delivered when it's delivered, and if that's later than expected, maybe next time scope will be prioritized throughout the project.