Archive for February, 2007
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.
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.
You’re on a busy Los Angeles street. You hail a cab. (Can you hail cabs in L.A.?) A diminutive man with an intense look appears out of nowhere and says he needs to share your cab. It’s okay, he says, he works for the government. Depending on how you feel about the government, serenity may descend upon you.
If in the course of conversation, or if you overhear him talking into his cell phone, you discover that the man’s name is Jack Bauer… leap from the moving cab immediately. Even if you are on the freeway, don’t hesitate. You have a far better chance of surviving than if you stay close to him.
As all fans of 24 know, you should never go on a mission with Jack Bauer. He will survive. You won’t.
I have a slow cooker at home. Earlier this year I started experimenting with various chili recipes to try to find one that I liked, but more importantly that my picky four year old liked.
I learned as I went. I learned that real Texas chili does not have beans in it. But my son loves red kidney beans and he gets precious little fiber and vegetable content in his diet as it is, so beans were non-negotiable. I learned that a favorite ingredient of many chili chefs is chocolate. Who could say no to chocolate? Well, my son gets way too much chocolate as it is. So I decided to leave the chocolate out. I learned that bacon has lots of salt and so does beef boullion concentrate. If you put both of those in, you can’t keep the added salt at the same level. Dead Sea would have described the salt content of one batch I made.
I think I have perfected the recipe. My wife raves about it and my son keeps eating it (he is not just picky but finicky as well). My daughter has also given the typical teenage show of rousing approval: “Yeah, it’s okay.” My eleven year old son is the only holdout. But since he seems to exist on a diet of half a cracker every three or four days, I don’t feel bad.
Lessons for software development:
- reuse proven source (start with an existing recipe)
- gather requirements (even from hard-to-please and ornery customers)
- release to the public
- gather feedback
I think I have a new hobby. No, not chili making, but metaphor stretching. This was fun.
Sorry to mislead with the title. I am not talking about teamwork myths here; I am talking about teamwork in reality and in fiction. The nature of teams in the workplace has been studied extensively by business scholars. I can summarize their findings with the key phrase I hear around my office a lot these days: “Diversity drives innovation.” Another phrase I like is: “If two people on a team think exactly the same way, one of them is redundant.”
So why in fiction is the solitary (and non-conformist) hero usually the one who triumphs? I believe that novelists and screenwriters love to celebrate the idea of diversity but often boil it down to a single person going against the grain and coming out on top. Personally, I love stories where the “protagonist” is actually an amalgam of personalities brought together as actual separate people, each contributing uniquely to the successful outcome. Diversity gets things done. I’m sure that’s why I like ensemble cast television shows like Heroes so much. Indeed, teams that triumph in movies like The Fantastic Four and novels like Tom Clancy’s Rainbow Six are much more appealing than stories about a lone wolf hero.
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.