Live data from Hacker News

Failing (and winning) at planning software projects

simplabs.com

21–24 of 24 posts

Re: Failing (and winning) at planning software projects

#21
post #17

Earlier quoted context omitted.

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

My main craft is software engineering but I've occupied managing roles in the past, and even twice as the CEO of a small company.

I am perfectly aware of the difficulties of managing projects and keeping clients happy.

From my experience, what you are describing is something few founders are concerned about, because they understand and embrace risk.

On the other hand middle-management is always trying to push their peons to predict the future and accept the liability.

Re: Failing (and winning) at planning software projects

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

That's what I've done with my email. It's either in my inbox, or 'archived'. Mentally much easier than deleting, but functionally the same

Re: Failing (and winning) at planning software projects

#23

Earlier quoted context omitted.

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…

ShapeUp is great! I don't think a cool-down phase is good though – if something is important to someone and it is indeed important for the business but still doesn't get planned in any iterations that means either

a) it's not actually important compared to other things so having someone work on it in a cool down phase is likely not well-spent time

or

b) there is a dysfunctional team/organization in which important stuff doesn't get prioritized correctly (typical example for this being 100% product management driven organizations in which refactorings etc. never get any time assigned)

Re: Failing (and winning) at planning software projects

#24
post #17

Earlier quoted context omitted.

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

My main craft is software engineering but I've occupied managing roles in the past, and even twice as the CEO of a small company. I am perfectly aware of the difficulties of managing projects and keeping clients happy. From my experience, what you are describing is something few founders are concerned about, because they understand and embrace risk. On the other hand middle-management is always trying to push their p…

> On the other hand middle-management is always trying to push their peons to predict the future and accept the liability.

That's bad just middle management then though. It's also why I'm advocating against project managers who would typically/often/sometimes do what you describe here – if you have someone who doesn't actively contribute to the project influence (or dictate in the worst case) timelines, that's deemed to fail from the beginning.

Post reply on HN