The work is never just “the work” (2022)
davestewart.co.uk
The work is never just “the work” (2022)
1–10 of 77 posts
Re: The work is never just “the work” (2022)
#2The article description is "A deep dive on why projects always overrun and a framework to improve future estimation"
This was a personal investigation into my faulty estimation skills, off the back of a small project which became a medium project, which became a large project with no shortage of surprises, overruns and pain.
The blog post was born from an honest and thorough postmortem where it turns out most of the work was simply not expected – and so wasn't accounted for.
I then went a stage further and attempted to outline more general reasons for this and to visualise how might look in terns of time and effort. It's not meant to be scientific, but is certainly an interesting way to look at things.
Anyway, I hope someone finds it useful.
Re: The work is never just “the work” (2022)
#3I wish companies would do this kind of analysis within their own projects. Probably not every project since doing this analysis would add overhead, but perhaps a small sampling of arbitrary projects.
How are we supposed to optimize things if we don't know where the time and effort is going to? How are we supposed to estimate, especially when a huge chunk of the extra time may be caused by an inefficient part of the process, caused by specific people (say, who like to schedule useless meetings), or caused by external factors?
Instead we see people choosing arbitrary things to blame, and business goes on as usual.
Re: The work is never just “the work” (2022)
#4A nag popup where the dismiss button just changes itself instead of dismissing the window? Oof, that's a new one.
Re: The work is never just “the work” (2022)
#5A nag popup where the dismiss button just changes itself instead of dismissing the window? Oof, that's a new one.
I didn't even realize that "Whatever" was the dismiss button.
The Kill Sticky bookmarklet is your friend: https://alisdair.mcdiarmid.org/kill-sticky-headers/
There's a newer version, but it breaks a number of sites for me, so I don't use it: https://github.com/t-mart/kill-sticky
The internet is a hostile place without Kill Sticky, uBlock Origin, and uBlock Matrix.
Re: The work is never just “the work” (2022)
#6This is actually a really good summary of how projects should be estimated. A lot of people I know just focus on the core task or the minimum viable product, ignoring everything around it.
I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away. In reality, the post-go-live support can take a surprising amount of time, but is rarely accounted for.
One particular customer, a telco, had PMs that started in the telephony space and were especially stuck in this mindset. Imagine digging a trench and laying down some fibre for a customer. The second the hole is filled and the fibre is lit up, the project is done. There is zero ongoing maintenance! Fibre doesn't need monthly patching, or regular replacement. It lasts decades. Sure, it might be cut by a backhoe, but that's break-fix, not project work.
Now picture the same mentality applied to general IT projects. Build it, mark the project as closed, and walk away. Never patch anything. Never upgrade. Never consolidate. Just leave things precisely as-built forever or until it breaks...
... or gets hacked and makes national headlines.
Re: The work is never just “the work” (2022)
#7The article description is "A deep dive on why projects always overrun and a framework to improve future estimation" This was a personal investigation into my faulty estimation skills, off the back of a small project which became a medium project, which became a large project with no shortage of surprises, overruns and pain. The blog post was born from an honest and thorough postmortem where it turns out most of the…
> and a framework to improve future estimation
The best framework I've heard of and used in practice is to simply ask one question: "How long have similar projects taken in the past?"
Chances are this one is no exception. It will take about the same time as similar past projects.
Re: The work is never just “the work” (2022)
#8Love the graphic, mind sharing how you made it?
Re: The work is never just “the work” (2022)
#9A nag popup where the dismiss button just changes itself instead of dismissing the window? Oof, that's a new one.
I didn't even realize that "Whatever" was the dismiss button. The Kill Sticky bookmarklet is your friend: https://alisdair.mcdiarmid.org/kill-sticky-headers/ There's a newer version, but it breaks a number of sites for me, so I don't use it: https://github.com/t-mart/kill-sticky The internet is a hostile place without Kill Sticky, uBlock Origin, and uBlock Matrix.
i customized the first one or one very similar to it to remove the "sticky" ones and also to remove the ability of the page to stop you from scrolling as some overlays do. I think it's a large improvement but there's nothing stopping you from having multiple of them(not well formatted here unfortunately but it should be fine to just copy and paste as a bookmarklette):
javascript:( function(){ let i, elements = document.querySelectorAll('body *');
for (i = 0; i if(getComputedStyle(elements[i]).position === 'fixed' || getComputedStyle(elements[i]).position === 'sticky') { elements[i].parentNode.removeChild(elements[i]); } } document.body.style.overflow = "auto"; document.body.style.position = "static"; })()
Re: The work is never just “the work” (2022)
#10The article description is "A deep dive on why projects always overrun and a framework to improve future estimation" This was a personal investigation into my faulty estimation skills, off the back of a small project which became a medium project, which became a large project with no shortage of surprises, overruns and pain. The blog post was born from an honest and thorough postmortem where it turns out most of the…
Golly gee, someone that realizes software engineering isn't entirely just sitting down and pumping out code? Why aren't you in management? (don't tell me... it's because you're honest with yourself)
I do wish this becomes more popular (and the graphic does help for those without imagination ;).
All venting aside, if you're familiar with a system, its development and deployment environment, and all the quirks of the tools you're using, you can easily "feel" around for how much "dark matter" work you're going to have to do -- and your estimates become a lot more tight, and close to reality. That is, once you throw away -- as you said -- "happy path" optimism and get down to business. An extra padding of cynicism will make sure you never miss a deadline; and if it turns out you were too cynical, you can always under-promise and over-deliver and wow everyone.
But padding is necessary, and I wish it didn't have this air of dishonesty associated with it. Realistically, shit happens. Stakeholders can huff and haw because it gets in the way of their aggressive plans, but it's not dishonest to say it's going to take another 3 months, because you're asking me to dig you a hole with a plastic sand-castle shovel. Yes, I can actually pound Red Bulls and wear myself down to the bone digging that hole as fast as humanly possible -- but I'm not going to.
If that's not good enough, the next best is to ship in phases (what little "A" agile tries to do, but fails in practice): a group of features will be guaranteed to ship at some date. At that point, we'll reassess and estimate the next batch -- until the project is done. We can even do soft estimates on all the batches, but using ranges (e.g. 3-6 months, rather than something concrete -- because they'll become de-facto deadlines), to give a rough "total project estimate." I like the month-by-month "sprint" model more than the 2 week model. Analysis and planning isn't free. It costs time, effort, and mental resources. Doing it every 2 weeks is absolutely ridiculous. Monthly strikes a nice balance between giving you enough time to actually do the "The work" and give stakeholders a feeling that they're "on top of things."