One of more deadly sins that we’ve see too many times in the past centers around the application of technology for the wrong reasons. One of the underlying causes of this problem is the acronym and keyword-centricity of most IT recruiting processes. This story shows how a hot new technology is handled in a typical corporate IT environment.

Let’s imagine that the hot thing in IT is the brand new (and fictitious) programming language named Foo. The IT rags are all talking about how Foo will reduce development costs by 63.25%. All the banks/startups/etc. are all talking about standardizing on Foo. The tickets for Foo One World Conference and Expo down in Orlando are selling fast. Heck, it even got mentioned in Business Week.

The problem is that our friend Bob has never worked on the job with Foo. Sure, he’s done development in .NET, J2EE, Perl, and a plethora of other buzzword-compliant environments. But not Foo. All of the cool kids are using Foo, and Bob doesn’t want to miss out.

So Bob reads up on the Foo Developer Network website, and memorizes all of the marketing and advocacy propaganda. He’s even built out the obligatory “Pet Store” sample application on his personal network at home after the kids go to bed.

At the weekly staff meeting, his boss announces that he needs a new widget configuration website that integrates into their existing widget management database. The only problem is that they’re under a strict 90 day deadline to get this application scoped, specified, designed, and implemented.

Suddenly, the heavens part and a ray of sunshine slices through the sky and into the conference room window, shining down on Bob. With that, the now illuminated Bob stands up and says “I have a solution. We’ll build the new functionality in …Perl“.

Perl? But that’s over a decade old, has it’s fair share of detractors, and isn’t the hip thing right now, especially compared to Foo.

Yes, dear reader, Bob could have shoehorned Foo into the environment. But our friend Bob has been around for a while. He knows that the best practices for Foo are still being worked out. The documentation is still sketchy. Plus, there aren’t any robust unit test frameworks built for it. A year from now, that will all be different. But at that point, the new widget configuration website will be in production for nine months already.

Bob recommended Perl because most of the other widget management applications were written in Perl. They’re six years old, and rock solid. For Bob and his team, Perl isn’t flashy like Foo, but it’s predictable. And in a 90-day full-lifecycle project, predictability rocks. Hard.

Bob likes a lot of things about Foo. He even thought for a second about employing his new favorite language on this project as an interesting change of pace. But he thought about it literally for a second, as he remembered the words he mentioned to a gang of consultants as he escorted them out the door nearly two years ago:

“This Project is Not the Science Fair”

Even though said consultants were faced with a relatively simple problem, they built an N-Tier J2EE EJB application atop a bleeding-edge XML database using a custom persistence framework that they cut out of the back of a Captain Crunch cereal box, and still managed to use all of the Design Patterns in the book (plus a couple that they coined themselves) in the process.

When I say built, I use that term very loosely. It was more like “experimented”, or more accurately “played with”.

That project was a caricature of everything that can go wrong on a project. The “architects” (quotes intended) took a bunch of resume-enhancing buzzwords and catch phrases, and made a very convincing case for employing them on that project. That was pre-Bob, mind you. Because everything was brand-spanking new, some of the APIs were still volatile. This meant that there were plenty of excuses to build homegrown abstraction layers to go around. Yet the application still kept breaking. Go figure.

After nearly 9 months of delays, Bob was pulled in to clean up the Service-Oriented mess. Bob got buzzword-compliant, alright. In fact, he developed some serious credibility on the support forums, as he learned enough about the various APIs to stem the bleeding, and ultimately rip out the riskiest parts of the application.

The irony is that, in hindsight, that project was just like the Science Fair. The consultants were awarded the “prize” of having a bunch of new buzzwords added to their resumes. Unfortunately, Bob turned out to be the Science Fair’s janitor.

He didn’t get to build the tabletop volcano, nor did he get to set it off and watch it erupt.

Nope. Bob was the guy who had the honor of mopping the red goo up off the floor, and muttering to himself: “Never again.”

Larry Wall, the creator of Perl (a very popular programming language) says that the three virtues of a programmer are Laziness, Impatience, and Hubris.
As a project team, you always want to “Maximize the work that you don’t have to do”. This does not mean that you are lazy, either in the negative sense or even in the strict Larry Wall sense. What it means is that you are actively identifying the areas of low-value work that you could reasonably do in the course of the project, and INTENTIONALLY NOT DOING THEM.

By specifically identifying the things that you aren’t doing (the anti-requirements, so to speak), you are doing two things:
1) Reinforcing the focus and scope of the real work at hand
2) Taking a second pass through the out-of-scope activities to ensure that they are not required.

One of the best and worst uses of time on a multi-person project are the inevitable debates around architecture and design. Unfortunately, these debates can sidetrack the participants, and become a mano-a-mano test of debating acumen, neither of which are especially conducive to producing software on time. This article discusses the value of a shared philosophy among team members.
Linus Torvalds (of Linux fame) has a saying that “Many eyes make all bugs shallow”. Similarly, project teams should have a process whereby the collective wisdom of the team members should cause Bad Ideas to die a quick and painful death.

The challenge with this is that it is often difficult to separate the message from the messenger. While the senior folks on the team are usually correct more often than their less-experienced counterparts, this is not always the case.

In order to keep lively debates from devolving into a “spitting contest”, euphimistically speaking, it’s important to allow Bad Ideas to die with minimal collateral damage to their creator.

The way that we do this is simple: We set out early on the project to gain consensus on a number of core principles or beliefs that the team has about the project and the resultant software. These are often broken out in terms of:

• People Issues (User experience, stakeholder expectations, team member specialization, etc.)
• Process Issues (Requirements management, testing strategies, build/release management, etc.)
• Technology Issues (platform considerations, “No Premature Optimization”, role of database, etc.)

Once we have consensus on the high-level beliefs, then many subsequent debates can be judged not solely on their individual technical merit, but also in terms of how well-aligned they are to the higher principles that the team is marching toward.