The Mu

Earlier I told you about FizzBuzz. I even offered my solution to it in Java.

Tons of traffic was created by Imran’s original post, Reg Braithwaite’s comment, and Jeff Atwood’s followup. All over the blogosphere, eager developers are trying to show their stuff by solving this simple problem.

The saddest part is that the community is mostly proving the rule: programmers can’t program! Of the subset of coders who actually read the requirements correctly, or at least muddled through the intent of the requirements, very few created correct solutions. There was a lot of “I did this in under a minute” and “look, I only used a single line of code”. Since we advocate iterating faster, I guess it is okay that the published “under a minute” solution was wrong, or that the single line of code was utterly unreadable and therefore unmaintainable.

One of the most amusing comments was from the guy who said: “It’s disgusting how many wrong solutions there are to FizzBuzz on this page.” He then proceeded to offer an incorrect solution in C: the iterator started at zero instead of one.

Equally amusing (as I assume was the author’s intention) was the solution that created a factory and tested for every single instance individually. I am not one to assume I know what code would optimize better, but judging by the amount of code in the solution: it would have been faster to just type out the results: even if someone changed the upper boundary to 1000 instead of 100.

I think a little testing would prove whether or not something worked. Rapid iteration would then refine the solution.

On Coding Horror, Jeff Atwood recently exposed his incredularity at how many programmers can’t program even the simplest pieces of code.  I read through his post and was shaking my head because over the years I have found that many of the people I interview also can’t produce simple code.

We have started testing our candidates with very simple recursion problems and other assorted programming challenges.  There is an ongoing debate as to the efficacy of doing this.  Does it truly identify weak programmers?  Does it create a false sense of elitism?  Does it inadvertently weed out brilliant programmers who may be hampered by a language barrier?  Forget the nuances of the debate: What I hadn’t realized is how fundamental the questions should probably be. We need to ask even easier questions to start identifying legitimate candidates!

The simplicity can go as low as you want.  One example readers provided was: show me how you would swap the values of two variables.

As an aside, I gave the FizzBuzz problem a shot too.  I included my result below (it took me almost twenty minutes because I learned about the StringBuilder class while I was writing it — I have been a manager since before Java 5 came out!). 

EMO* is often the acronym for Emergency Management Office.  Many jurisdictions have one, and they go by various names.  Perhaps the most infamous one is FEMA, which garnered a poor reputation as a passive yet voracious money pit in the aftermath of Hurricane Katrina.

Now to my point (yes I know it took me long enough): emergency agencies can’t be careless and cavalier like the rest of us where technology is concerned.  My brother-in-law and I were discussing how people who rely on technology in life-and-death matters cannot afford to be early adopters.  Granted, they must experiment with new stuff as soon as possible, but they can’t switch over wholesale until a technology is proven beyond any doubt.

For example, there’s always a black analog handset lurking in a corner hardwired to a landline.  VOIP and wireless technology have made inroads but are not reliable enough to be trusted in a real emergency.  When we were hit with the big North American power outage in August 2003, our wall-mounted telephone was the one that was working.  People had to come to our house to make important calls.  We are not going to get rid of that ugly old phone any time soon.

I love new gadgets, but somehow the ultra-conservative approach of government to adopt new technologies makes me feel safer.  Better to be safe than disconnected.

* My kids listen to emo music.  I think it is short for emotional or something.  I am an old guy so it is my duty to not know these things.

I repented for my earlier reaction to Second Life, pointing out that while it might not appeal to me, there is potential in the technology and elements of it may be used to shape the way the 3-D Internet may eventually work.

But I can’t help but point to the somewhat risqué (reader discretion advised) and amusing account of what a typical gamer experiences when arriving at Second Life.  It’s not at all what they expect.

Meanwhile, folks continue to question the scalability and demographics at the same time that virtual terrorists are organizing to claim rights for Second Life citizens.

Good grief.

Consider a piece of software that is already out there being used every day.  The majority of users have become what Alan Cooper refers to as “perpetual intermediates”.  They use specific parts of the product and are probably annoyed by certain interactions that the software makes them endure.

These users, if vocal enough, will be the source of most ongoing functional requirements.  They will drive the ideas for enhancing the product.  But who speaks for those potential customers who didn’t stick with the product long enough to become perpetual intermediates?  How many novice users were driven away by function or interactions that the “loyal” users overcame?

Apple has Steven Jobs.  His uncompromising view of how the product must be before it is released to the public has resulted in several hits.  The Mac and the iPod are the two most famous examples.  I am not suggesting that Apple doesn’t gather user feedback or conduct usability testing.  But I am hypothesizing that Apple has another voice speaking out for the silent group that would otherwise abandon the product before getting used to its quirks.

I think it is our duty as software developers to speak up when we see complexity gaining ground on usability or even usefulness.  We must pound on the table and demand that “ejector seat” function does not appear beside common function — or hundreds of other fundamental design principles put forward by people like Cooper and Jef Raskin.

By the way, there is another group at the other end of the spectrum, just as silent as the ship-jumping novices. When people become truly expert at using a difficult-to-use product, they have a disincentive to submit feedback about simplifying it.  After all, they can make a living charging for their expertise.

Almost as a counterpoint to yesterday’s topic, and in response to Ferdy’s comment, I wanted to point out that while evolution can produce mutations, it can also breed the fittest of the species.  The idea is that you want to force evolution to happen quickly but in an environment conducive to improvement and not just compromise.

From the software creation point of view, Coding Horror provided Jeff Atwood’s take on this with a recent post about Boyd’s Law of Iteration.  His conclusion: iterate faster.  But he first lays out the requirement that a development shop have the support of management and the proper infrastructure in place.  That is what I am talking about when I say that only the fittest will survive.