The Math Behind Project Scheduling, Bug Tracking, and Triage [video] | Hacker News Reader

The Math Behind Project Scheduling, Bug Tracking, and Triage [video]

usenix.org

77 pointsrossjudson17 comments

I did not expect this talk to hook me so quickly. Im still watching currently, and a thought that pops up for me as a freelancer, how can I employ some of these mental tricks (like for example estimating tasks by points while disregarding how much calendar time that is associated with) while also being the manager of myself? Im sure its simply be aware of the pitfalls of thinking in deadlines, to avoid “Student Syndrome”, to focus on the benefit and spirit behind this sort of goal setting.

Im thinking it would help me if I took one day a week to put my “project manager” hat on and divy up tasks for the coming week into story points, and then kept the hat off the rest of the week to keep time based goals out of my way.

Does anyone with some experience scheduling their own time using tips in the talk have any suggestions?

It doesn't make sense for yourself. The idea is to have one person tracking another (group of) person(s) and thereby having some feedback and motivation. Maybe you can grow a team with other freelancers and track each other?

That makes good sense to me actually. By the time I finished the talk, I realized there were some great takeaways for me in terms of understanding product management, but that it would be foolish overtooling to try and solve for problems that I dont actually have on the scale the tools are designed for. Thanks for your input!

This is a great talk so far. Does anyone have any [text]book recommendations for "mathematically mature" Project Management (i.e., project management theory that doesn't shy away from using math to demonstrate its points, if needed)?

Goldratt's "Critical Chain" work is the closest I've seen to 'mathematically mature' project management.

https://en.wikipedia.org/wiki/Critical_chain_project_managem...

Deming’s work is another good source along with Goldratt.

Critical Path Method + Program Evaluation and Review Technique (PERT). Figure out the shortest path to the goal (critical path) then figure out the most likely timeline, by applying a probability distribution to the weights of each connection. This highlights the truth that reducing variance is a huge factor in improving the quality of forecasts.

Change Management studies cover this aspect, I believe

https://en.wikipedia.org/wiki/Change_management_(engineering...

For probabilistic scheduling you could look at software like @Risk by Palisade. Effectively applying Monte Carlo simulation to schedules. You provide a distribution around the level of effort or duration required to complete a task/activity in your precedence network/graph. What you get after enough runs is a probability or likelihood of completion dates/cost (e.g. P50 or P90 estimates).

This is extremely powerful in non-trivial scenarios where you have a properly resourced & cost loaded schedule with logical constraints.

The question reminds me of this classic chart from "Rapid Development,"

https://www.construx.com/uploadedImages/Construx/Construx_Co...

It's a great reference for project management, but not very math heavy.

More math-oriented I'd say:

- "How to Measure Anything," although not specific to project management

- "The Principles of Product Development Flow." Think of "product" in this context as anything you want made that is unique (not made made repetitively in a factory). E.g., software. There's some queueing theory in there. And although the math isn't always presented, you will get more out of it if you can figure out or understand the math behind the principles

The author, based on the technology and products he's chosen to work on, is either visionary and courageous, completely lacks foresight, or enjoys pain:

Avery was the lead engineer for Google Fiber's home wifi devices, building, managing, and monitoring the whole fleet in customers' homes. ... Before that, he started startups including one that deployed Lotus Domino in 10 minutes, and one that did unspeakable things to Microsoft Access databases.

Microsoft Access, Lotus Domino, and consumer Wifi (mass-deployed!)? Shoot me, please, three times.

On the other hand, they are a great way to learn the challenges of project scheduling and management. (In fairness, Lotus I mostly know by reputation, but the other two are enough.)

Of your proposed motivations, I’ve been accused of all three but it’s probably the third one :) — the author

Good talk. I thought it was interesting what you said about student principle because I have a counterpoint to it. Which is that not carving out time day to day to tackle tech debt (via sand bagging) means the treacle gets thicker and harder to run through and the volume of bugs increases which leads to corners being cut to get features out at the old pace.

So the argument to over-estimate or sand bag, and fold in better solutions with the boy scout principle seems to me the best way to make a brown field site green again.

I’ve had one experience of this which totally worked. Time to implement features went from weeks to hours. I’m currently trying to apply the same method again with mixed results

The approach recommended in the talk is to use relative size estimates instead of absolute size estimates, which removes the possibility of over-estimating (or under-estimating) or sandbagging.

During the conversion phase from relative sizes to absolute sizes (which should be based on historical measurements, not aspirations), you can choose to add a bit of extra time so that people can work carefully and fix things rather than feel rushed. That's often a very good idea.

Hi - I hope the intended humor was taken that way! I really do see it as courageous, because I would never take it on. How do you efficiently provide remote support for mass-deployed, consumer wifi in residential structures - which also means unmanaged networks and systems of every imaginable variety and configuration? It can be hard enough to diagnose problems in person, on-site, in structures I know on networks I built. I can't imagine the support calls, even if you tediously work with the end-user to narrow it down to the wlan signal: "Do you have metal mesh your walls? Baby monitors? Fluorescent bulbs? A microwave? Do the bulbs or microwave leak? Do your neighbor's? Does your neighbor have wifi? Do you an RF sensor in the right frequencies, mapping software, and do you know how to use them?"

No offense taken. The wifi project was indeed very hard, but I think we moved the world forward at least a little bit. If you're really interested, you can find out more about how we did it in my recorded talk here (although the slides pdf has a lot more detail): https://apenwarr.ca/log/20160328

And some additional comments on the evolution of wireless networks in my talk from Battlemesh last year: https://www.youtube.com/watch?list=PL3bvPCw5QCLJ-VJPamVeQx-U...

One part that made the problem more tractable was that we both ran the network and made the devices. This almost never happens. It means we could optimize the devices for quality and supportability instead of making the usual consumer device tradeoffs (is it pretty enough? cheap enough? glitzy enough?).

It sounds very attractive to developers, and I myself was a huge fan of this way of thinking for a long time. Sadly real life teams are never even close to this. And there are reasons for that, which we might like or not. But they have to be accepted. For instance most project leaders are not good developers nor good managers. And they don't really want to advertise that fact, because just like us they believe that anybody actually cares. So they get even worse by not tracking relevant metrics and instead focus (not by coincidence but by cunning) on metrics that are painful for developers, like current_open_bugs, or open_features_that_nobody_understands_and_that_where_discussed_with_nobody. They do that because it increases pressure on developers, hooks them with their desire to become better, and they provide automatic goals that can never be achieved. And these are the desired outcomes for the project leaders. Because if everybody is under time pressure, you don't need to worry that someone might steal your job, if everybody already feels bad about themselves they will not criticize you openly (and are motivated to work harder), and if there are always automatic goals you don't need to think about new goals all the time.

What is interesting to me is that nobody puts these people actively at the top of the projects. It's more like they grow to these positions naturally. But now that they are there, you can't really apply the logic from the presentation to convince them. Insted you might even give them the impression that they don't apply enough pressure yet because you are criticising their job.

Reply on news.ycombinator.com