Discover application architect Geoff Godwin takes you on an inspired fantasy adventure that details why estimating project timelines in the world of code is inconceivable! Join Geoff to explore the challenges, see the reasons behind the difficulty, and hear valuable insights to improve your ability to estimate future timelines. This 'A Moment of Your Time' quest will have you responding to future deadlines and requests with a simple "as you wish."
Want more videos? Subscribe to our YouTube channel.
Transcript
Have you ever felt like you're in a constant struggle to meet project deadlines? Whether you're a stakeholder or a developer, let's face it: estimating project timelines in the world of code is really, REALLY difficult. So today, let's confront the elephant in the room—the inherent difficulty of estimating code. Together, we'll explore the challenges, shed light on the reasons behind the difficulty, and discover valuable insights to improve our ability to estimate project timelines.
Narration: "Once upon a time, in a world of innovation and possibility, at a small direct bank that provided private loans, direct banking and credit throughout the land, there lived Jamie, a capable dreamer and business aficionado with a vision, and Riley, a skilled architect of software wonders.
Interrupting kid: Hold it, hold it. What is this? Are you trying to trick me? Is this a kissing book?
Narrator: Wait, just wait.
Interrupting kid: Well, when's it get good?
Narrator: Keep ya shirt on. Let me read.
Narration: One fateful day, Jamie approached Riley with both a problem and an idea—in order to help their customers achieve a brighter financial future, they could offer each customer a means of tracking their spending and analyzing it to learn about their habits, a ... spend analyzer we’ll call it. Jamie’s hope was that they could provide such an offering through their marvelous mobile app. Such a feature would allow their customers to see where they had spent their money month to month, track their spending habits based on the time of year, and get insightful tips on how to save smarter. Excited by the possibilities, Jamie turned to Riley, seeking wisdom and an estimate for such a grand endeavor."
Aside: Alright so Jamie and Riley have a problem: they wish to improve their customers financial wellbeing, and a proposed solution to their problem in the form of a spend analyzer, but how long will it take and how will they estimate it? Hopefully they won’t make a blind estimate without knowing the details. That would be like trying to estimate how long it takes to build a house without knowing the number of rooms, the square footage, or the condition of the land. So, let's see how Riley tackles this challenge.
Narration: "Riley made it clear to Jamie that an estimate was impossible to give without first researching the specifics of the undertaking. Any t-shirt sizing or ballpark would truly have been massive and Jamie likely would have been left rather unsatisfied by the outcome. So, Jamie left Riley to delve into the depths of the problem, seeking to unravel its intricate tapestry. Like a master weaver, Riley began breaking down the solution into smaller, more manageable pieces—in an attempt to make estimation more feasible."
Aside: Breaking the problem into smaller chunks makes it easier to estimate in a piecemeal fashion. It's like guessing how long it takes to vacuum your bedroom versus guessing how long it takes to vacuum the entire house. It’s also super important here that Riley let Jamie know there is no way to estimate the length of a ball of twine without unraveling it first. Riley could have just said “extra-large” and walked away but that would be disingenuous and honestly just as bad as saying “extra-small” just … on the other end.
Narration: "Riley’s findings were... rather daunting. The full scale of the process seemed inconcievable, as it was in fact an enormous endeavor that required commitment and participation from other technical stakeholders to maintain and manage the data necessary. As Riley met with other professionals in adjacent spaces, they discussed the nuances and pitfalls of the plan, adjusting accordingly and solving as they went.”
Aside: You know often I get asked by developers why we bother estimating at all. “It’s just a guess anyway, the work will take as long as it takes!” and it’s a good question to ask. However, I think the answer typically misses the mark. While yes there is value in having some idea how long something will take so that you can plan the next thing you’ll do afterwards, the true value to planning effort is in the conversations that arise when you debate effort. Some of the best hidden details and edge cases I’ve worked on in my career were exposed in those early conversations when someone throws out a number on effort that's too low and someone else on their team responds with “Well have you considered ..BLANK?” or someone else pitches a high number and then when asked to explain their reasoning for that difficulty their colleagues point out a better or easier way.
Then there’s coordinating work across multiple people and teams. The majority of developer teams have multiple priorities, not just one task at a time. Figuring out at what point someone upstream of you needs their work done for you to complete your section and pass it to the next group is important if you aren't working solo.
Narration: “As Riley worked and discussed the problem with peers, the estimation grew and grew in duration. Riley became concerned that the sheer effort would destroy any chance of the spend analyzer ever seeing the light of day. Sharing this concern with Jamie, they together proposed an alternate solution to implement the feature in stages. Instead of the complete product rolling out day one, they would release a Minimum Viable Product (MVP) sooner and continuously improve upon it until they reached the full model Jamie initially envisioned. It was a marvelous plan, for it allowed them to share useful features with their customers while steadily building towards the final product."
Aside: By breaking their plan into consecutive iterations, Jamie and Riley could achieve their goals in smaller steps. This way, instead of waiting a long time for the final product, they could bring regular updates and enhancements to their customers, steadily improving their lives while avoiding the burden of long development cycles. Iterative development also brings more frequent, smaller changes, so your audience both gets to adjust to change over time and contribute feedback into the system to drive further iterations. When you plan and build something big all at once, that feedback opportunity is missed, limiting the potential of the final application.
Narration: "With their plan in place, Riley presented Jamie with a piecemeal estimate—not fixed timelines but ranges that accounted for unforeseen circumstances. You see, the world of coding is filled with unexpected twists and turns, and Riley knew the importance of allowing room for these surprises. Putting their heads together they organized the features they needed into separate rollouts, with major versions one, two, and beyond. Later features would plan to build upon and enhance previous ones."
Aside: Now, I want to note here that it’s essential to always have some wiggle room in your estimates. Unexpected distractions and external forces can throw off timelines and "life" is what happens while we’re all busy making plans. Riley was wise to account for these possibilities given the situation and equally wise to share these ranges with Jamie as an olive branch of trust. It was Riley’s way of saying “look Jamie, this task could be quick but there are some things in here that give me pause and for that reason I’d rather cover our bases just in case. If I’m wrong, then we’ll get it done faster but if I’m right we won’t miss the mark.” Personally, I try to think of two estimates for everything I plan to work on. An optimistic one that’s a little lower and a pessimistic one that’s a little higher.
Narration: "United in purpose, Jamie and Riley set forth on their quest, aligning their visions and conjuring the first version of the spend analyzer. Along the way they were met with many hardships and perils. Early in the pursuit, Riley fell ill for nearly a fortnight, leaving work to a more junior staff member unfamiliar with it. This setback was unaccounted for, but manageable as other padded estimates were able to be completed ahead of schedule. At another impasse, a legacy piece of software in practice turned out to be inadequate and an alternate solution was necessary. Luckily Riley and Jamie remained steadfast and supportive of one another, and Jamie came to Riley’s aid by shifting the priorities of other tasks away from the teams Riley needed to coordinate with to allow them to focus on the spend analyzer fully."
Aside: And as is the case with any grand adventure, challenges arose. Riley underestimated a piece of work due to illness, and a seemingly simple feature relied on a legacy system that couldn't deliver as expected. However, Jamie and Riley remained transparent, working together to overcome these obstacles and adjust priorities. As Jamie thought up new potential features and ideas for the spend analyzer, they were added to later iterations beyond the current one so as not to stop or shift the goal posts mid-build."
Narration: Although it lacked the full splendor Jamie originally envisioned at release, their spend analyzer creation allowed the bank’s customers to peer into their own spending ventures, discovering the highest-spending categories within their financial domains. It was a marvel!
With resilience and determination, they launched their creation, only missing the deadline by a week. Later, they expanded the tool, adding insights, trends, and summaries in later iterations. Their customers were bestowed with a brighter financial future—a treasure worth more than any kingdom. With great gusto they rejoiced, liked, commented and subscribed in unison!"
Conclusion: And so, we've reached the end of Jamie and Riley’s journey through the challenges and triumphs of estimating code. This story of course is entirely fictional to illustrate my points. But based on what should be familiar anecdotes around project management and software development. So now let's take a moment to reflect on the valuable lessons we've gathered along the way.
Estimating code is no easy task, let's be honest. It's like trying to catch lightning in a bottle—elusive and technically impossible. But there are ways to navigate this complexity! Breaking down large-scale problems into smaller, manageable pieces helps us gain clarity. It's like tackling a big jigsaw puzzle by finding the corners first, then the edges, then sorting by colors... etc.
One of the most powerful strategies to learn from this tale is the art of iteration. Instead of waiting for perfection, we can release a Minimum Viable Product (MVP) and continuously improve it over time. Think of it like painting a work of art—you start with a rough sketch and then refine it stroke by stroke. By delivering value to your customers early on, you show them your commitment and keep their excitement alive through updates.
And we can’t underestimate the importance of trust and transparency. When Jamie and Riley openly communicated about the challenges they faced, they could work together to find solutions. It's like having a reliable partner on your side during a challenging quest—someone who has your back when things get tough. Building that strong partnership between stakeholders and developers is crucial for conquering the coding landscape.
Now, I’m not saying you need to update each other on a moment-to-moment basis, that’s just counterproductive, but if at any point you foresee a slow down or difficulty ahead of you, there is no time like the present to communicate it. As I always tell my engineers, if you’re stuck on a problem for more than an hour, it’s time to get a second set of eyes. Don’t waste a day out of pride.
I also want to point out that when Jamie first approached Riley with the problem, the discussion of estimates wasn’t available out the gate. Riley needed to go look at the systems in play, in some cases diving into code itself to check how something worked and whether their existing systems could support some of their use cases. I often hear from developers that project managers push back on them about large estimates and from project managers that developers estimate too high. This is often a result of not breaking the steps down small enough to show the specific details. I’d also always recommend overestimating than under, if you’re a project manager who has asked teams to lower their estimates but then still missed the deadline, this should tell you the estimate was probably more accurate than it looked.
And let's not forget the value of leaving room for the unexpected! In the unpredictable realm of code, surprises can arise when we least expect them. It's like reaching a detour sign on a familiar road, or running into sudden inclement weather, you need to deal with that in the moment. That's why Riley wisely accounted for unforeseen circumstances, allowing flexibility in the estimates. It's better to finish ahead of schedule, with a sense of accomplishment and a smile on your face than to explain why your team is always behind the curve on delivery.
So, my fellow adventurers, I hope these lessons stay with you as you continue your coding journeys. Embrace the thrill of breaking down complex problems, of iterating and enhancing your creations, and of fostering trust and transparency. Remember, it's not about perfection--it's about progress and the satisfaction of the journey itself. If you agree, feel free to subscribe to our channel for more insights into the realm of software development.
As always, I'm Geoff Godwin, and I thank you for a moment of your time.
