Hacker News Reader

Comment by forapurpose | Hacker News Reader

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

View on HN

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

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

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.

Reply on news.ycombinator.com