Apple Stories

I've long been fascinated with the history of computing.  I've read many books and watched what few movies/tv shows exist on the subject.  It is for this reason that I found this week's "This Week In Tech" so interesting.  In honor of the 30th anniversary of Apple's founding, it is an interview with several of the people who were there when it all began.  Guests include Steve Wozniak, Andy Hertzfeld, Bill Fernandez, Daniel Kottke, and Randy Wigginton.

Along these same lines, there is an interview with Lee Felsenstein who ran the Homebrew Computer Club and creator of the Sol.  I haven't had a chance to listen to this one yet but it's queued up on my Zen Nano right now.

If this subject interests you, see my Amazon List on the subject.  It needs a little updating but includes most of the books I've found interesting.

Pranks at Microsoft

Microsoft, like many technology companies, has been the site for many pranks over the years.  In this video, Larry Osterman and Dave Norris relate many of the pranks that have been seen on the Microsoft campus during their tenure.  On his blog, Larry describes their latest prank involving 20,000 bouncy balls.

On a side note, this interview is filmed in the lounge area just down the hall from my office.

Podcasts I'm Listening to Now

Here's what I'm listening to this month.  If you have any suggestions for things I might like, especially tech/programming podcasts, send them my way.

I listen to these regularly:

Major Nelson - Covers the world of the XBox360.  News, reviews, interviews with insiders.

This Week in Tech - Leo Laporte and a cast of characters talk about the technology news of the day.  Includes guests like Steve Wozniak.  A bit chaotic but you get a good overview of the week's happenings so you can dig in more later.

Security Now - Very informative show about the world of computer security.  Lately they have been doing information series covering networking, crypto, etc.  Also covers practical tips.

The Dice Tower - Best of the board gaming podcasts.  Reviews, news, and top ten lists.  Gives a good overview of what is out there.  Good place to become introduced to new games.  The hosts are good natured and fun to listen to.

Engadget - This is last on my list but I usually get to it.  Everything you need to know to stay atop the fast-paced world of cell phones and gaming systems.

These are not published regularly but I find interesting listening when I run out of regular podcasts:

Nerd TV - Interviews with lots of big names in technology.  The interviews sometimes wander (Bill Joy's sailboat?) but are always interesting.

ITConversations - I've started listening to the programming series there.  It doesn't appear to be getting any new podcasts but the archives are fun.

Naked Conversations - Live

   Yesterday I went to see Robert Scoble and Shel Israel talk on campus.  It was a stop on their book tour.  It was an enjoyable hour.  Their presentation was better than many book tours I've attended.  First, it was on topic.  They discussed what they talked about in their book.  It is amazing how many times an author comes around shilling one book but spends the hour talking about something wholly different.  Second, it wasn't just the book.  Sometimes authors come and read a portion of their book out loud.  Thanks, I'll read the book.  Third, they were very extemporaneous.  They had a roadmap but still interacted with the crowd.  A lot of interesting questions were answered.

   For those who haven't read the book (that includes me right now), the basic thesis seems to be that corporate blogging is displacing traditional PR methods.  You get a more authentic connection with your customers when you keep it real than when you sanitize everything before it is sent out.  Sure, there can be mistakes made without the PR-filter, but that's exactly what makes it so valuable to customers.  As a user, I find that I rarely read about a product on a company's web site any more.  It is trying too hard to get me to buy and not hard enough to educate me.  Instead, I'll go read reviews or look in the forums.  Blogs can fill a similar role.  Bloggers from within a company can be great advocates for their products but still be informative.

   I think Robert and Shel are probably taking things too far.  There is a place for both corporate bloggers and PR.  Having a designated, official mouthpiece can be good.  It gives the ability to answer a question definitively and give people confidence that the answer won't change (soon).  At the same time, it will always be suspect because it is so one-sided.  Corporate blogs, if done right, should be more personal and less partisan.  They help put a human face on a business.  People are still, at the core, emotional creatures.  A human bond is worth more than lots of perfectly crafted press releases.

Blogosphere Gets Taken

There has been a lot of talk in the blogosphere about how it it replacing old media.  The response of old media seems to be that the blogosphere is uncontrolled and therefore inaccurate.  The response back has been that the blogosphere is self-policing.  If someone says something inaccurate, they won't last long.  Today we see a stark example of why the blogosphere is still flawed.  David Richards writes an article claiming that Microsoft is delaying Windows Vista in order to rewrite 60% of the code.  Not only that, but we're going to have the XBox team come save us and start working on Windows.  If you actually read the article, the numbers appear to be pulled out of thin air.  The number 60% shows up in the headline and the opening sentence.  It's not actually ever sourced.

Whether it is memeorandum or slashdot, the blogosphere seems eager to suspend disbelief when it comes to bad news about Microsoft.  Memeorandum links to more than 15 articles, only a handful of which call the number seriously into question.  Think about the scope of the claim.  Windows is reported to be something like 40-50 millions lines of code (I haven't counted them myself).  If that is true, we're going to rewrite 25 million of them?  I think not.

The blogosphere is not as objective as it might think that it is.  Often times the community policing works but there is also a bias and when something plays into that bias, the policing breaks down.  It will be interesting to see if cooler heads prevail here soon.

The Dangers of Test Automation

   One of my favorite TV shows right now is House.  In it a brilliant but antisocial doctor and his staff try to solve medical mysteries.  If you don't watch it, you should.  The writing is great.  Earlier this season, there was an episode where a journalist hits his head and has slurred speech.  The team is trying to diagnose this and having no luck.  Toward the end, House tells them to go do the blood work again and "don't use a computer."  When they look at the blood under a microscope, the cause becomes readily apparent.  There are parasites in the blood.  The patient has malaria.

   Just like the computers examining the blood were not programmed to look for parasites, so too the software that we write to test a program is often not programmed to look for all of the potential failures.  When we write test automation, we are focused on one thing.  If testing a video renderer, the test will make sure that video output is correct.  What if that output causes the UI to be distorted?  What if it causes audio to glitch?  The test wasn't programmed to look for that.

   About a year ago I first visited the concept of test automation.  In that article I gave several reasons why the best testing must be a mix of both manual testing and test automation.  The idea that all tests should be automated continues to pervade the industry.  It is thought that testers are expensive and automation is cheap.  Over the long haul, that may be true.  It is especially true when projects are in sustaining mode that you want primarily automated tests.  However, when developing a new product, relying solely on automated tested can be disastrous.  In addition to the issues I talked about in my last post, there is a danger I didn't discuss.  That is the danger of missing something obvious but unforseen.

   Before diving in, let me get some definitions out of the way.  Manual testing is just that:  manual.  It involves a human being interacting with the program and observing the results.  Test automation is the use of a programming language to drive the program and automatically determine whether the right actions are taking place. 

   In addition to the higher cost and thus higher latency of automated testing, it is also possible that automated testing will just miss things.  Sometimes really obvious things.  Just like the computers in House that missed the parasites, so too will test automation miss things.  Just recently I came across a bug that I'm convinced no amount of automation would ever find.  The issue was this:  while playing a CD, pressing next song caused the volume to maximize.  To a human, this jumped out.  To a computer designed to test CD playback, all would seem normal.  The next song did indeed play.  Even a sophisticated program that knew what each chapter sounds like would probably not notice that the volume was too high.  A programmer would specifically have to go looking for this. 

   There are a near-infinite amount of things that can go wrong in software.  Side effects are common.  Automation cannot catch all of these.  Each one has to be specifically programmed for.  At some point, the returns diminish and the test is set in stone.  Any bugs which lie outside that circle will never be found.  At least, not until the program is shipped and people try to actually use it.

   The moral of this story:  never rely solely on automation.  It is costly to have people look at your product but it is even costlier to miss something.  You have to fix it late in the process--perhaps after you ship--which is really expensive.  You lose credibility which is even more expensive.  Deciding the mix of manual and automated testing is a balancing act.  If you go too far in either direction, you'll fall.

Becoming a Lead, Pt. 4 - We Not I

   Another aspect of becoming a lead/manager that takes some time to wrap one's head around is what your role is now.  You are no longer judged based on your own actions, but rather the collective actions of your team.  With all of the time you will likely spend developing people, attending meetings, reviewing work, etc., your direct contribution to the collective output of the team will be low.  This is more and more true, the greater the number of reports you have.

   The role of a lead is fundamentally different from that of an individual contributor.  A lead is tasked with maximizing the output of his or her work group.  More often than not, this means that the lead takes a back seat when it comes to "real work."  It is more important that you spend your time growing, unblocking, and dealing with bureaucracy than it is that you fix a bug or implement some feature. 

   Writing software takes a lot of concentration.  It takes unbroken time to just sit and work.  As a lead, your day is usually broken up.  It is hard to get that time to concentrate.  When you get it, it often comes at the expense of other things.  You won't have the same opportunities you once had.  Instead, your day will be working with others to solve their problems.  You will be helping people develop themselves.  You will be helping to prioritize the work.  You paying more attention to the project as a whole than to particular features.  This is all good work, but it is very different from your previous life as an individual contributor.

   This becomes really apparent when it comes time for reviews.  At Microsoft we have a review system where we are judged based on the goals we set for ourselves and our ability to achieve those goals.  When you are an individual contributor, your review is easy.  You just list off everything you did during the previous year.  I wrote this.  I tested that.  I drove this iniative.  When you become a lead, your review changes.  When you sit down to write your first review as a lead, you'll notice that your individual accomplishments were not what they once were.  That's okay though, you are no longer responsible for just "I."  You are now responsible for "We."  You are judged by, and it is okay to claim credit for, the work of your team.  We wrote this.  We tested that.  One of my reports drove this iniative.  The first time you write a review like that, it feels like cheating.  After all, you didn't do that work.  Your role has changed.  That work took place because you facilitated it.  You kept people focused and unblocked so they could give 100% of their effort.  Welcome to your new job.