4 ms·

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

w4tson 8y ago
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
- apenwarr 8y ago
  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.
forapurpose 8y ago
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 8y ago
  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-UPNBVyaopj&v=vJL8xrQ3gOE 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?).

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

apenwarr 8y ago
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.

forapurpose 8y ago

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 8y ago
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-UPNBVyaopj&v=vJL8xrQ3gOE 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?).