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

Failing (and winning) at planning software projects

simplabs.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Failing (and winning) at planning software projects

#11

Post by danvasquez29 »

jasonpeacock wrote: post #10
berkes wrote: post #4

> Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months. This makes me uncomfortable. I don't exactly know why, but the thought that ideas, nice-to-haves, and bugs move to a /dev/null of some sort, does not resonate with me. Wh…

ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix". [1] https://basecamp.com/shapeup

that's not true at all in my experience. In the past we've had "bug bash" type activities, or used that lower-hanging fruit as training opportunities. As an architect i've sometimes grabbed tasks like that just to stay fresh but also out of the way of the prioritized team backlog.

Re: Failing (and winning) at planning software projects

#12

Post by marcoow »

danvasquez29 wrote: post #11
jasonpeacock wrote: post #10

Earlier quoted context omitted.

ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix". [1] https://basecamp.com/shapeup

that's not true at all in my experience. In the past we've had "bug bash" type activities, or used that lower-hanging fruit as training opportunities. As an architect i've sometimes grabbed tasks like that just to stay fresh but also out of the way of the prioritized team backlog.

Bug bashes are a bit like cool down periods in my experience – if your focus is 100% on features all of the time then every now and then you need to catch up on open bugs or piled up tech debt. I'd argue these types of activities are not necessary at all when all stakeholders contribute to the scope of each iteration (see https://simplabs.com/blog/2020/06/17/failing-and-winning-at-...). Still, if a bug isn't taken on for x weeks or months, I'd say 99% of the time it never will be and can just as well be closed since it's ignored anyway.

Re: Failing (and winning) at planning software projects

#13

Post by stephc_int13 »

"other stakeholders that have legitimate needs with regards to predictability and insight into a project's progress are left in the cold"

Well, that's a bit dishonest, this is not really about coordination, this is about risk and money.

This is about helping people who are not working on the project to sleep better.

I believe that setting the budget and deadline from the start and then asking the team to scope the project is a reasonable way to manage risks, but not the other way around.

Re: Failing (and winning) at planning software projects

#14

Post by commandlinefan »

stephc_int13 wrote: post #13

"other stakeholders that have legitimate needs with regards to predictability and insight into a project's progress are left in the cold" Well, that's a bit dishonest, this is not really about coordination, this is about risk and money. This is about helping people who are not working on the project to sleep better. I believe that setting the budget and deadline from the start and then asking the team to scope the pr…

> not working on the project to sleep better

I believe it's more sinister than that: it's to prevent the people who are working on the project from sleeping at all. Remember, most developers are on a salary, which means minimum 40 hours a week, but a maximum of 168. People who view other humans as expendable "resources" - the amoral types who inevitably rise to prominence in corporate America - then see planning as a strategy to push that number as high as possible. They thus insist that an inherently unpredictable process - software development - must be 100% predictable and, when that inevitably turns out not to be the case (yet again), they demand punitive uncompensated overtime. This isn't an accident.

Re: Failing (and winning) at planning software projects

#15

Post by marcoow »

commandlinefan wrote: post #14
stephc_int13 wrote: post #13

"other stakeholders that have legitimate needs with regards to predictability and insight into a project's progress are left in the cold" Well, that's a bit dishonest, this is not really about coordination, this is about risk and money. This is about helping people who are not working on the project to sleep better. I believe that setting the budget and deadline from the start and then asking the team to scope the pr…

> not working on the project to sleep better I believe it's more sinister than that: it's to prevent the people who are working on the project from sleeping at all. Remember, most developers are on a salary, which means minimum 40 hours a week, but a maximum of 168. People who view other humans as expendable "resources" - the amoral types who inevitably rise to prominence in corporate America - then see planning as a…

Hey, I’m the author. I think you Mis-interprete what I’m saying - of course understanding timelines and budget will often be a legitimate need of one or some stakeholders, among others. And of course making teams stick to deadlines when that’s not possible is bullshit. But the other extreme - demanding that nothing can ever be estimated and understood well up-front - is equally wrong. In the Limited scope of an iteration, it is well possible to reduce risk and uncertainty at least a good amount through thorough analysis and preparation.

Re: Failing (and winning) at planning software projects

#16

Post by stephc_int13 »

marcoow wrote: post #15
commandlinefan wrote: post #14

Earlier quoted context omitted.

> not working on the project to sleep better I believe it's more sinister than that: it's to prevent the people who are working on the project from sleeping at all. Remember, most developers are on a salary, which means minimum 40 hours a week, but a maximum of 168. People who view other humans as expendable "resources" - the amoral types who inevitably rise to prominence in corporate America - then see planning as a…

Hey, I’m the author. I think you Mis-interprete what I’m saying - of course understanding timelines and budget will often be a legitimate need of one or some stakeholders, among others. And of course making teams stick to deadlines when that’s not possible is bullshit. But the other extreme - demanding that nothing can ever be estimated and understood well up-front - is equally wrong. In the Limited scope of an itera…

I disagree, in my opinion it is never legitimate to pressure people into predicting the future, and it simply never works.

There is a very this counter-intuitive thing about predicting the future.

We tend to believe that by cutting our predictions in smaller and smaller pieces, our predictions will be closer to reality, or at least more manageable. But there is nothing further from the truth, the best predictions are made when someone experienced in the field is looking at the big picture and try to give a rough estimation.

This has been proven again and again.

At the end od the day, people are working and projects gets finished not because, but in spite of micro-management and other unhelpful practices.

Re: Failing (and winning) at planning software projects

#17

Post by marcoow »

stephc_int13 wrote: post #16
marcoow wrote: post #15

Earlier quoted context omitted.

Hey, I’m the author. I think you Mis-interprete what I’m saying - of course understanding timelines and budget will often be a legitimate need of one or some stakeholders, among others. And of course making teams stick to deadlines when that’s not possible is bullshit. But the other extreme - demanding that nothing can ever be estimated and understood well up-front - is equally wrong. In the Limited scope of an itera…

I disagree, in my opinion it is never legitimate to pressure people into predicting the future, and it simply never works. There is a very this counter-intuitive thing about predicting the future. We tend to believe that by cutting our predictions in smaller and smaller pieces, our predictions will be closer to reality, or at least more manageable. But there is nothing further from the truth, the best predictions are…

Indeed we disagree. I’d say the reluctance that’s relatively wide spread in particularly among engineers to even try and reduce risk as much as possible (within a limited scope) and framing that as „predicting the future“ is a huge fallacy that doesn’t benefit anyone. There’s just not only the 2 extremes - completely and reliably predicting the future vs. just going off with no plan - but there’s something in the middle.

Also the big picture That one could look at in the beginning of a project and base an estimate on is more often than not not what you end up with at the end of the project anyway.

Re: Failing (and winning) at planning software projects

#18

Post by commandlinefan »

stephc_int13 wrote: post #16
marcoow wrote: post #15

Earlier quoted context omitted.

Hey, I’m the author. I think you Mis-interprete what I’m saying - of course understanding timelines and budget will often be a legitimate need of one or some stakeholders, among others. And of course making teams stick to deadlines when that’s not possible is bullshit. But the other extreme - demanding that nothing can ever be estimated and understood well up-front - is equally wrong. In the Limited scope of an itera…

I disagree, in my opinion it is never legitimate to pressure people into predicting the future, and it simply never works. There is a very this counter-intuitive thing about predicting the future. We tend to believe that by cutting our predictions in smaller and smaller pieces, our predictions will be closer to reality, or at least more manageable. But there is nothing further from the truth, the best predictions are…

There's a particular bit of wishful thinking endemic to software project managers, in particular: the belief that almost everything useful is also predictable, and that what's left accounts for only a tiny fraction of the overall effort. A bit of reflection should make it obvious that the opposite is true: if it was so easy, somebody else would have done it before. Yet, like every 15-year-old who believes in their heart that they'll grow up to be rich and famous, the manager always assumes that they're just the first person to think of cloning Facebook.

Re: Failing (and winning) at planning software projects

#19

Post by commandlinefan »

maaarghk wrote: post #6
marcoow wrote: post #5

Earlier quoted context omitted.

Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are: * putting effort into preparing proper tickets for all these ideas is likely wasted time as 90% of the ideas will never be taken on * keeping all the ideas together with the issues that are actually important creates noise and makes it harder to identify the actually important stuff; also having…

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Reminds me of a recent Dilbert comic/quote: "Our boss can't judge the quality of our work, but he knows when it's late".

Re: Failing (and winning) at planning software projects

#20

Post by jasonpeacock »

danvasquez29 wrote: post #11
jasonpeacock wrote: post #10

Earlier quoted context omitted.

ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix". [1] https://basecamp.com/shapeup

that's not true at all in my experience. In the past we've had "bug bash" type activities, or used that lower-hanging fruit as training opportunities. As an architect i've sometimes grabbed tasks like that just to stay fresh but also out of the way of the prioritized team backlog.

Yep, ShapeUp describes an open "Cool Down" period between cycles, where people are free to work on whatever they want - favorite bugs, features, docs, developer tools, etc.

They discuss how everyone maintains their own personal list of what's important to them and use that to drive their work.

But maintaining a single, centralized list of everything has little value. Anything important is already being tracked in the roadmap, including bugs impacting customers of sufficient priority.

It really is worth reading the ShapeUp book, it provides a good, alternate view of commonly-held beliefs.

Post reply on HN