
The Math Behind Project Scheduling, Bug Tracking, and Triage [video] - rossjudson
https://www.usenix.org/conference/srecon18europe/presentation/pennarun
======
jonchurch_
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?

~~~
erikb
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?

~~~
jonchurch_
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!

------
georgewsinger
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)?

~~~
maroonblazer
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...](https://en.wikipedia.org/wiki/Critical_chain_project_management)

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

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

~~~
forapurpose
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?"

~~~
apenwarr
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](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...](https://www.youtube.com/watch?list=PL3bvPCw5QCLJ-VJPamVeQx-
UPNBVyaopj&v=vJL8xrQ3gOE)

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

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

