Bcc

(Looping back in the digital exhibitionists, in case they have input here.)

Regarding exhibitionism and subjectivity: I'm not sure there's any way around the fact that I control this. Since it's on a web page that I control, I don't see how I could prove to you that it's automatic or genuine, even if it really were. Short of a government-implanted chip, I think there's no way to stop me from potentially lying to you about my location, and if it ever got to the point where I couldn't lie about it, hide my location at certain times, I'd be really unhappy.

But I think I see your point, that there is a difference in degree here. The more automatic the updates are (even if I have the power to turn them off, or distort them), the more realistic the image of myself is portrayed. The more I have to remember to update, choose to only in certain circumstances reveal my location, the more my persona is curated.

There's no choice but for my online persona to be curated, the same way that my "real life" persona is. But the more automatic and implicit I can make these updates, the more realistic (and richer) a persona I can present. That seems like a worthy goal -- I'll work on getting updates to happen more automatically, and on building the habit to press that button each time I look at my phone. And maybe I can document on my page when my location was last updated -- it's not real proof, but it would be a start.

On Feb 23, 2009, at 2:51 PM, Sam Maurer wrote:

Friends,

Using the wonders of Fire Eagle (thanks Seth!), and a Google Geo Developer Workshop (thanks iSchool!), I've added a map to my personal website (http://npdoty.name) which is centered around my exact location, as stored in Fire Eagle.

So if you're curious, you can see roughly where I am, any time you have access to a web browser. Go ahead, stalk away. Try it out, let me know what you think.

Of course, updating Fire Eagle is something I have to do explicitly from my phone or laptop, so it won't be as automatic as the way that Andreas does it (though I'm looking at Loki to try to do it automatically via SkyHook). And the way the page is laid out, my exact location is visually obscured -- though those of you comfortable with code should be able to find my latitude and longitude without any trouble.

Nevertheless, I've never made this sort of information public before, so I'm curious to know how you'll use it, whether it borders on digital exhibitionism, if you think it'll lead to my untimely death, etc. So far, I like it, just because the maps are pretty and it provides some context to a webpage about me. If that isn't pretentious and self-aggrandizing, I don't know what is.

Nick

Dear Google and Microsoft friends,

It's pretty exciting to see software testing come so prominently into the news twice in such a short time frame. I know that neither of you can share any of the internal discussion you've heard on these topics, but I sure would have enjoyed watching the threads these events sparked. Are these issues getting talked about a lot outside of the groups immediately impacted?

Really, I've been able to see quite a bit just looking in from the outside. It's pretty neat to see the actual source code of the Zune leap year bug and hear the exact wildcard problem in this weekend's Google badware bug -- it makes me feel like I'm not so far away from the industry after all. (Which isn't to say there isn't some advantage from knowing some people on the inside: it was fun when I was at Microsoft last month to hear about how our friend on the Zune test team got a call at 7 AM on a day when most people weren't expected at work telling him he needed to be in the office immediately. That must have been a pretty intense day. ;)

I've heard conjecture (fueled by the short-lived rumor that StopBadware was somehow responsible rather than Google itself) that the mistake happened because Google got an updated list from StopBadware and just checked it in verbatim, rather than Google mistakenly adding the wildcard in itself.

And it's similar to the discussion I saw around the Zune leapyear issue. Speculation raged about how a Microsoft developer could make such a mistake or how the Zune test team could miss it. Then when it came out that it was actually a bug in Freescale Semiconductor's code, suddenly it made sense to everyone: only the Zune 30 had the problem, none of the newer Zunes have that problem because they no longer rely on a third-party vendor's code. And more significantly, it wasn't that Microsoft developed code with such a glaring hole. Or that Google deployed a file with such an obvious error. It's as if we're comforted by thinking that Google and Microsoft weren't the responsible entities; that at least fits with our understanding of these software companies.

But neither of those explanations helps the Google customer or the Zune customer, nor should they be any solace to them. Microsoft and Google are just as responsible for code they ship that was originally written outside the company. And really, if anything, it's an opportunity for a Microsoft SDET and a Google QA engineer to get a promotion.

Sure, whatever Google engineer checked in the file should be getting a talking to: wouldn't a single manual test have caught the issue? When you're making a change to code that'll be run as part of every Google search, shouldn't you at least have tested it once yourself? But it's much more an issue of why there wasn't an automated check-in test that prevented the change from going in at all. A single negative automated test case would have caught this and relying on all your individual engineers to never make mistakes like this is foolish.

Also, I happen to think that the Zune leapyear bug should have been caught by a developer's unit tests: shouldn't a unit test for a piece of leap year code include a case for the end of a leap year? But a Microsoft SDET could make some significant improvements for his product by proposing a policy to do code reviews of partner code. Collaborations are inevitable, and it would be worse for the company to have the already frustrating Not-Invented-Here syndrome institutionalized as an official company practice under the name of quality assurance. Test plans and code reviews are just as valuable for partner code as for code written internally.

Of course I know that none of you can speak for either company any more than any single person could ever represent such a huge group of people, practices and institutions. For that matter, I have faith that both the Zune team and the Google Search team have already come to these conclusions and implemented something along these lines. But I'm curious what your thoughts are, since you might be able to bring this idea up as a reminder in your group and in the next group over and that maybe we can all have a little more discussion about it. And that's exactly the point: we expect Google to not make mistakes like this because we expect such a powerful single entity to be so consistent. But Google isn't such a single entity -- any one engineer will make mistakes and any one partner will be unreliable. But since Google the institution is so powerful, it can be as perfect as we expect, not by being a single infallible entity, but by putting practices in place -- like a culture of quality assurance and a system of unit and check-in testing. In both of these high profile cases, the issues were institutional bugs, not code defects.

Perhaps that's all obvious to you guys; to someone just looking back on the software business, it seemed important.

Anyway, hope you're doing well and that you're enjoying software development. Grad school is pretty great, but I do miss being more intimately involved.

Nick

Well, I guess the idea was that it wouldn't need any editing (or only to fix programmatic problems). That raises the question about what the true purpose of the project would be, but at least partially for me it's a statement about our communications -- that they can often be trivial, that the amount is huge, that the pieces are intermixed and formatted identically in my email client despite having such different characters or topics.

This distinction about how email has such a wide variety of topics and styles actually got me started thinking about another idea. What if I wrote a blog that was done in the format of emails that I sent to various people? So each post would be an email (like some of the more significant ones I send to you, or Tim O'Reilly, or friends at Microsoft, or whoever), complete with headers. I really like the idea of blog entries that have more metadata than just a title (who I chose to send to and CC and so on; the content of the email I'm responding to, etc.). Also, it harkens back to publishing an important person's letters as a journal of his life. (http://npdoty.name/bcc, say.)

On Jan 20, 2009, at 11:52 AM, Sam Maurer wrote: