A nag popup where the dismiss button just changes itself instead of dismissing the window? Oof, that's a new one.
Yeah, as if the popup spam wasn't enough, now it asks for confirmation to close...
The work is never just “the work” (2022)
21–30 of 77 posts
Re: The work is never just “the work” (2022)
#22The 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 t…
In find that even though I’m typically pretty spot on in the amount of actual design and coding time a feature requires, the actual wall clock time can be way off. Ad hoc meetings, days off for holidays/corporate events, waiting on external feedback, etc. are all very hard to account for.
Re: The work is never just “the work” (2022)
#23Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…
>1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't
Not to mention, even if you have done the exact same thing before it's unlikely you'll be satisfied doing it the same way. What % of projects are finished with everyone thinking "Yeah that was done perfectly there's nothing I would change if I could start from scratch"?
Re: The work is never just “the work” (2022)
#24Earlier quoted context omitted.
> In reality, the post-go-live support can take a surprising amount of time, but is rarely accounted for. Really the most frustrating part of PM. I have never had a PM that understood "we could implement features faster if we took a little time to go back and tighten up the code". Instead it's just a constant stream of one feature after the next with whatever got written down the first time by a fresh college grad be…
It's like running a marathon and you keep falling on your face because your shoes are untied, but you "don't have time" to stop and tie them, so instead you just keep tripping over and over and over while your competition recedes into the distance. Bonk.
In the limit, you reach the level of that joke I remember hearing as a kid (and I think it dates to post-WWII rebuilding / soviet era). One possible retelling:
An outside inspection comes to a busy construction site. As they watch the workers running with wheelbarrows, back and forth between material storage and active construction, they notice that all the wheelbarrows are empty. They flag a foreman, and ask him, "why are all these workers pushing empty wheelbarrows around?", to which the foreman replies, "we're so swamped with work, there's no time to load them!".
Re: The work is never just “the work” (2022)
#25The author seems to argue that estimates are off because of "unknown knowns", and can be improved by adopting an estimation framework that makes these items more explicit. While this is certainly valid I would add that in my experience the most influential causes of major shedule disruption were the "unknown unknowns", wich are inherrent in any new creation, but which are exacerbated in software because of the extrem…
The author covers "unknown unknowns" explicity;
> It’s interesting to note: (...) the amount of work “outside” the project, aka unknown unknowns
If I understand correctly, most of those fall under the blue "Problems" category, aka. "the work outside the work" - though there may be some bleed-through to the green "Iteration" category, aka. "the work between the work", in which the author includes "debugging, refactoring, maintenance, tooling".
This is valid by my experience too; most of the schedule-breaking "unknown unknowns" fit into the "Problems" category.
Re: The work is never just “the work” (2022)
#26Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…
>1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't Not to mention, even if you have done the exact same thing before it's unlikely you'll be satisfied doing it the same way. What % of projects are finished with everyone thinking "Yeah that was done perfectly there's nothing I would change if I could start from scratch"?
Not to mention, you're still just learning. You don't get proficient in anything by doing it once. After you do something a few times (in relatively short succession - enough for the sequence of actions to stick around in your memory; compare: spaced repetition), only then you can have a good feel for how long it takes (and you have a baseline against which to compare your ideas to improve the process).
Re: The work is never just “the work” (2022)
#27It's kind of ridiculous that people still believe that they can get better at estimating work they've never done before.
The amount of hours lost by teams estimating work is insane.
Re: The work is never just “the work” (2022)
#28Earlier quoted context omitted.
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 t…
In find that even though I’m typically pretty spot on in the amount of actual design and coding time a feature requires, the actual wall clock time can be way off. Ad hoc meetings, days off for holidays/corporate events, waiting on external feedback, etc. are all very hard to account for.
Something I realized while skimming this thread, and moments before opening the article itself - I'm definitely underestimating things by factor of 2x, because I keep forgetting about the denominator - that my one work day isn't really 8 people-hours of project work!
In reality, it's closer to 3-4 people-hours on average, after I account for time consumed by team meetings, corporate paperwork, 1-on-1s, code reviews, lunch break, help requests from teammates, IT/devops doing maintenance on infrastructure, requests to opinionate on / get involved with some discussions about new projects or with new customers... - a lot of work that's mostly necessary, but isn't relevant to the particular thing I'm focusing on (or estimating).
So on top of the excellent framework from the article, I'm going to keep reminding myself that, for the purpose of estimation and project work, I'm working 3-hour days, not 8-hour days (and that's before we factor in any fuzzy human stuff like kids getting sick, becoming burned out, etc.).
Re: The work is never just “the work” (2022)
#29A nag popup where the dismiss button just changes itself instead of dismissing the window? Oof, that's a new one.
I immediately closed the tab away as soon as it asked if I was sure.
Re: The work is never just “the work” (2022)
#30A nag popup where the dismiss button just changes itself instead of dismissing the window? Oof, that's a new one.
Fair point! Consider it fixed