As a developer I want to build something neat, that impresses others and makes someone's life a bit easier. This most commonly manifests itself in a problem that could be easily solved but I've added various extensibility points that were neither required nor will probably ever used. In times where I find myself slipping into one of those modes, where I'm just adding functionality for the sake of functionality, I remind myself of
YAGNI ("You aren't going to need it") who's main tenet is:
Programmers should not add functionality until it is necessary
I was reminded of this twice recently, the first last Saturday, the latest being tonight.
Last Saturday I was talking with family while at a parade. The discussion of brainstorming came up. The somewhat well-known story, or so I'm told, was reiterated to me on Saturday. It has to do with a power company trying to figure out how to remove ice from electical lines. When the ice would build up the lines were in danger of breaking under the weight of the ice. Here's what they came up with during a brainstorming session on how to fix it:
"during one of the breaks, one of the linesmen shared with
some of the participants about how came face to face with a big, brown bear
when he was servicing the power lines, and how he narrowly escaped being mawed
by it.
when they returned for the meeting, someone suggested training
the brown bears to climb the poles to shake off the ice from the wires. brown
bears were very common in the areas that they were looking at and they are
strong enough to cause the poles to shake when they climb the poles.
someone else then suggested putting honey pots at the top
of the poles to entice the bears to climb the poles.
they then started to discuss about how to put the pots of
honey at the top of the poles and someone threw out the idea of using helicopters
to do the job."
The idea however was quickly abandoned for a more simpler solution when a secretary pointed out the following:
"a secretary in the meeting pointed out that the down wash from
the helicopters could possibly break the ice and blow it off the wires."
The helicopter idea works, and is still in use to this day (
read the whole story), but how cool would it be to sit back and say, "I trained some bears to climb a tree in search of honey to solve our problem." The story is typically used to illustrate how even crazy ideas in brainstorming sometimes aid in finding a simple solution. As a programmer however, I learn from the story the fact that they implemented the helicopter solution because it was easy, safe, cost-effective, and quick to implement.
The second, and latest, reminder occurred tonight when talking to a co-worker at a client cocktail party. The co-worker was talking to me about a conversation with a client who's main complaint is that we have to provide everything "whiz bang". Typically "whiz bang" denotes something cool or neat, however, the gripe was not that what we delivered was bad or wrong, but that in our pursuit to "wow", we didn't "wow" the client because it took a long time to implement.
Over-architecting. This is a seemingly common trait in developers. If you work on a team it's likely that you're constantly having to fight this from somewhere within the team. On days where I'm dutifully adhering to the YAGNI principle and building shippable software, someone else on my team may be in the throes of a battle of over architecting. Likewise while everyone is adding real features, I may be dreaming and scheming of ways to make a program über-great.
I have to keep reminding myself that shipping software is the most important aspect of a software company. It seems too simple to carry any real weight; like something as simple as a shippable product is enough. It's really a novel idea considering how much software I've shipped recently.
Today I passed my first Microsoft Certification test in about seven years. I passed the first of two tests, 70-528 (Microsoft .NET Framework 2.0 - Web-Based Client Development) on my way to MCTS. I've had mixed feelings on certifications and still do to this day. I know some
very talented certified developers who add to the MC* reputation. Likewise I know several developers who despite being certified, can't program, and weaken/cheapen the MC* title.
My reaction to the test is that it is heavily weighted in places that seemingly don't matter "in the real world". I'm keenly aware I could be way off base here, however I've been working with .NET now since 2003 and asp before that. The two areas that were heavily stressed in my test were deployment ("Copy Website", Publishing, aspnet_compiler) and Mobile Controls. In my nearly 5 years with .NET I have never written an application that uses mobile web controls. Should I have? Am I strange? Regarding "deployment", at
Geonetric, we have a build server which uses
Cruise Control and
NANT, and therefore I rarely (read:never) have used the "Copy Website" function from within Visual Studio to get a site to a staging server, nor used the "ASP.NET Configuration" application to change web.config settings in my production machine.
While the debate can rage on about the relevancy of tests, I'm softening my position on them and do see them as beneficial (maybe for another post) when taken as part of a whole. In some chats with
Scott Hanselman about the subject recently, he took the stance that certifications are just a good resume line item but the most important thing was to ship software, not what collection of consonants you can string together behind your name.
