Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The work is never just “the work” (2022)

davestewart.co.uk

Post reply on HN
Print view View original

11–20 of 77 posts

Re: The work is never just “the work” (2022)

#11

Post by creakingstairs »

jiggawatts wrote: post #6

This 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…

> 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.

This mentality and Agile mixed together creates monster technical debts. A team is rushed to create an MVP. Since it’s an MVP, things are skipped, rushed and riddled with edge cases. This is fine if the team can now use the customer feedback and deeper understanding of the domain to iterate and polish the product. Write some documentation, refactor rough edges etc.

But of course, this often doesn’t happen and the team begins sprinting to deliver on yet another “top priority”. After a while, management starts to wonder why doing anything takes forever and devs are leaving.

Re: The work is never just “the work” (2022)

#13

Post by cogman10 »

jiggawatts wrote: post #6

This 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…

> 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 being the golden solution.

It's particularly frustrating because PM tend to measure success by the number of features produced. That alone incentivizes a fair number of devs to just pump out shit without thinking about what they are producing.

Re: The work is never just “the work” (2022)

#14

Post by cogman10 »

creakingstairs wrote: post #11
jiggawatts wrote: post #6

This 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…

> 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. This mentality and Agile mixed together creates monster technical debts. A team is rushed to create an MVP. Since it’s an MVP, things are skipped, rushed and riddled with edge cases. This is fine if the team can now use the customer…

Scrum is so anti-agile it's not even funny. Just TRY to convince a scrum lord that maybe we shouldn't put process before people. It's a treat.

Re: The work is never just “the work” (2022)

#15

Post by throwaway892238 »

Why 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 impact on deliverability, even for the exact same work. (but it's not the same work, because you haven't done it before)

3. You have changed, or will change. You're literally a different person since the last time you did it, and you haven't taken that into account, and now things take a different amount of work/time.

4. You're fallible. You just remembered wrong, guessed wrong, fucked up, forgot, etc.

5. Estimating is a skill. After a long career, you can look back at what you did and what happened, and look at what you've got now, and make an estimate. The more experienced you get, the better your estimates get. That doesn't mean they're accurate, because you can't control #2-4. But they'll certainly be closer.

My favorite is when I actually have a very strong feeling about an estimate, and I tell my boss, and he doesn't want to believe it, so he arbitrarily tries to find a way to get a better estimate. I end up right, he conveniently forgets my original estimate.

Re: The work is never just “the work” (2022)

#17

Post by spondylosaurus »

cogman10 wrote: post #13
jiggawatts wrote: post #6

This 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…

> 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.

Re: The work is never just “the work” (2022)

#18

Post by devjab »

I really like this article. I think impressive how informative it manages to be in such a short space, and how the visual work helps tell the story. I’m definitely going to use this (with full credits) from time to time when the discussions on how a team needs to work with estimations.

What I wish it also included was the not-so-academic parts of estimations. Like how we’re often operating in systems where it is much better to over than underestimate, because it’s much better to never let a client know that you didn’t actually spend that X time compared to letting them know that you need X more. Or how estimating things you’ve done before can also be hard because people don’t actually deliver Y “story points” every week, because sometimes their children get sick, they sleep poorly, whatever. Or how even the most senior developer can spent 3 hours on something silly.

But I guess a lot of that plays into a different sort of discussion. One where we talk about whether a lot of the “control” parts of the work process are actually necessary or just wasted resources. And I don’t want to sound like I think it’s wasted resources, because it can be both and often it’s a combination. Personally I tend to avoid working in areas with too much “control”, if you estimate by anything less than a day, then I’d like not want to work for you. Not because I can’t do it, but because I hate spending time on things that aren’t “the work”. I’m not sure how to include that sort of metric into the discussion, but I think it may be relevant. Because I doubt I’m the only one, and while completely anecdotal, I wouldn’t want to invest in any of the places I wouldn’t want to work because they tend not to do so hot in the long term. So maybe looking at overhead is important? But my sample size is way too small to mean much.

Re: The work is never just “the work” (2022)

#19

Post by fatfox »

cogman10 wrote: post #13
jiggawatts wrote: post #6

This 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…

> 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…

From my experience, it's the business pressuring the PM into situations like this. If PMs want to keep their jobs, they're often just as helpless as the devs having to execute the work.

Re: The work is never just “the work” (2022)

#20

Post by PeterStuer »

The 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 extremely high and fractal dimensionality of digital assets. The smallest deviation from assuption can have an unbounded impact on the plan, often popularly refered to as a 'butterfly effect'.

Post reply on HN