This is a spectacular train wreck that had doom written all over it from Day One. It’s a familiar, predictable pattern constantly repeated since the first clueless manager commanded “just make it user friendly”.

The goal was simple enough: create handheld computers for census field workers to interview citizens and to electronically communicate with a central system. What the Census Bureau got were expensive paperweights unable to transmit the large volumes of necessary data and too complex for census employees to comprehend during tests.

Census Director Steven Murdock blamed the failure on “communication problems” between the Census Bureau and the software contractor. But, the AP learned, “interviews, congressional testimony, and government reports” soundly spell out the failure more precisely: “census officials are being blamed for a poor job spelling out technical requirements.”

Gee, doesn’t that sound familiar? As Yogi Berra so eloquently put it: if you don’t know where you’re going, you might not get there. The Census Bureau failed to spell out what they wanted, so they didn’t get it.

Building software isn’t like shopping for it

How can there be such viral stupidity in corporate leadership that this failure mode burns up capital and burns out developers with such regularity?

Here’s an analogy that works for me. Many years ago, I bought a digital video camera. To do anything meaningful with it, I needed editing software. Several were available, so I browsed the stores and surfed the discussion groups to learn my options. Each came with a unique set of functionality and corresponding price tag.

Many video editing products came with cool features I hadn’t even thought about. Suddenly, visions of green screen magic with pan-and-zoom, slow-motion effects did a fade transition to my Best Director acceptance speech at the Academy Awards! When my decision was made, I plunked down my credit card and walked out of the store with a set of CDs rattling around inside a cardboard box. I couldn’t wait to see what it could do!

We’re all familiar with this process of buying software. Why is it so easy? Because somebody else did the requirements analysis for us! Someone else spelled out the workflow of the user interface. A subject matter expert carefully described what processes needed to be automated – and how. The product was carefully prototyped, evaluated, refactored, and packaged into a polished work of technical elegance. This process took months or years. But, all we have to do as consumers is waltz into Best Buy on our lunch break.

But, what if no video editing software had ever been written before? What if I was the first to identify the market and launch a little startup with the goal of making it big with the first video editing software targeting the consumer market?

Therein lies the greatest challenge in software development: building something that has never been built before, envisioning something never seen, describing an inspiration to someone else with sufficient clarity so they may bring it to reality.

Simply deciding on what features might be useful is hard enough. Creating an interface and an intuitive workflow requires diligence, collaboration, and lots and lots of prototyping.

Where the Census Bureau, and everyone else, gets it wrong

At some point, the Census Bureau approached its contractor and described their needs. I picture the conversation going something like this:

Census Bureau: Make us some software for our handheld computers.

Contractor: Okay. What sort of work do your field workers do? What are their most common tasks? What kind of data will they be collecting?

Census Bureau: I don’t have time to go over that. Just make sure it’s user friendly.

The Census Bureau thought they were strolling through Circuit City looking for “Intuit Census Taker 2010 Deluxe”. They hadn’t stopped to think about what they really needed, they just figured they’d know it when they saw it.

In reality, they weren’t going to find their software on some store shelf. After all, they needed software that had not been written before. They needed careful analysis of their requirements. They needed to identify who would use the software, what their users would be doing, and how they would be doing it. Requirements analysis is hard. It takes time. It is tedious.

This is not work that can be passed on to the developers. Developers are not the subject matter experts – they’re merely specialists in building dazzling creations meeting exacting specifications. Leaving them to guess at requirements guarantees they’ll solve the wrong problem.

How to fix it (and not fix it)

Imagine buying a custom home and telling the builder “build me a home for $250,000…and make it pretty”. Your builder can’t measure “pretty”. How does he know when he’s done? Requirements must be measurable and verifiable.

Your builder needs specific questions answered like “How many bedrooms?”, “One story or two?” Failure to answer fundamental questions ensures you’ll blow 250K on a house you don’t want. Answering these questions is your job – not the builder’s. Software is no different.

Poor requirements analysis is the most common thread in all failed projects. Who is responsible for providing requirements? The primary stakeholders paying for the work. Unfortunately, business process owners driving the software’s need see requirements definition as too burdensome – too much “busy work” – to task their own resources to address. Can’t the developers just write the software? I’ll see if I like when they’re done. That’s a costly cycle to rely on.

When projects fail, developers take the heat. Why? They have no direct reports. Everyone in the food chain has underlings to berate and scapegoat for their own failures.

So, an endless stream of passing fads gets hauled out to “correct” the waywardness of the development staff. These fads are called “process” and go by important and trendy sounding names like RUP, Extreme Programming, and Agile. One process after another is ditched for “better” processes that theoretically correct the cause of the previous digital disaster. When another failed product gets pitched into the bit bucket, the developers are erroneously accused of “not following the process.”

Don’t get me wrong. I don’t mean to disparage the litany of software processes that have come and gone over the years. But, doesn’t anybody wonder why we need so many? Doesn’t anybody question why new processes continually come along claiming to “fix” the shortcomings of all before it? Why is a workable software process so hard to find?

They’re all workable – they simply fail to address the root cause of the problem. The problem is leadership laziness.

When even halfway competent programmers are given a goal and sent on their way, you can expect them to deliver on all expectations. Things like process, skill, and experience can influence the cost and maintainability of the code. But, with clear requirements, you can always expect to get what you want.

So, business leaders, stop looking for the right “process”. Instead, roll up your sleeves and do a little hard work. Think about what you want. Spell it out. Be available for questions and clarifications. Don’t make the developers guess.

It’s time well spent. And, if your time is well spent, then so is your money.

Remember the days of eagerly poring over core dumps to quash that nasty bug? The fascination of learning something new? The determination to write code properly so it could be maintained and easily understood by others? Remember when “so what? it works” just wouldn’t cut it for maintainable design?

I loved it. So, what is it with kids these days?

A colleague of mine noted that the best programmers have a raw enthusiasm about their work. They’re not 9-to-5 coders. They’re driven incessantly to learn new things – to do things right. They play with ideas in their off hours and on weekends. They’re geeks. Total nerds. And, they’re proud of it.

From gearhead to bit twiddler

My degree is in mechanical engineering, but my first love was software. I was writing BASIC on my family’s TRS-80 back in late elementary school. I shunned a formal education in computer science because the curriculum, at least in the late 1980’s, was almost pure theory: optimizing data structures, theory of languages, operating system design, etc. All noble causes – and certainly a worthy field of study. But, I wanted to build something!

As I finished my degree, it was clear that, despite my enjoyment of mechanical engineering, my true passion was for software. I abandoned my quest to apply my degree and began looking for pure programming work. I knew there was more out there than just writing a better compiler. I could make applications that normal people could use and would make the world better.

From the late 80’s to early 90’s, a great transformation had occurred. Once, software was written only for very narrow problem domains and computers were found only in special rooms. Maybe administrative assistants had one for word processing (anybody remember WordPerfect?), but that was it.

By the time I graduated, PCs were beginning to permeate the workplace. Office workers had PCs as surely as they had a chair and a desk. It would be only a few more years until Netscape, the Web, and the Internet explosion wowed us all. Even the bursting dot-com bubble couldn’t stop this new era.

Software wasn’t just about scientific calculations and data retrieval anymore – it was about information management. I just knew that massive, ground-breaking systems were waiting to be built.

Sorry, your real world experience doesn’t interest us

So, there I was in the university placement office trying to get a programming job without a germane degree. I had spent the last several years building software for a million dollar research project in the mechanical engineering department. I was kicking butt at the job that had washed out two computer science majors. I had mastered C++ in a real world application while the ivory tower academics were poo-pooing the burgeoning relevance of object oriented programming. Yet, I could barely get my foot in the door with any employer.

Despite years of experience and demonstrable ability, I was self-taught and had never set foot in a computer science class. In the eyes hiring managers, I was a mere hobbyist without hardcore credentials.

Then, one icy morning in a tiny interview room, I once again began the spiel that was beginning to bore even myself: “No, my degree isn’t in computer science, but I built these engineering applications, see…” The interviewer nodded knowingly and said “oh, no need to explain, my degree is chemical engineering”. This big-wig IT guy from Citicorp was another engineer! Better yet, he understood! He understood that passion and enthusiasm – drive and determination – are what make the grade.

I got the job, and my career began. Through years of C++ followed by years of Java, I’ve encountered countless code wizards who coached me, learned with me, and sometimes learned from me. They had degrees in physics, history, English, theater arts, and marine biology. They all came to the software field from seemingly unrelated paths. They learned their trade through energetic devotion to the beauty of their creations. They were geeks in the purest form.

All of this fascination with software as an art form meant one thing: a team of people dedicated to doing the best job possible – not because it was good for their employer, but because they loved their work. They were, and are, the “old school” programmers.

I mean no disrespect for computer science majors

Yes, I also met some hot shot CS majors who leveraged their book smarts along with a keen sense of design to help bring triumph to the team. But, remember the tech bubble? Companies were spending billions automating every business process. There just weren’t enough people with CS degrees to staff all of the projects. Progressive companies began casting a wider net and bringing on the eager but self-taught. As a group, this would be the motley crew that lived on pizza and No-Doz to build the systems that made startups and large companies thrive.

So, what happened?

As the IT bubble began to rise, salaries went stratospheric. This created two problems.

First, every college freshman saw IT as a path to riches – guaranteed employment with high starting salaries. Colleges and universities now turn out legions of just-in-it-for-the-paycheck programmers. Writing code is tedious, and doing it right requires extraordinary patience. It often means rewriting working code as requirements change or better solutions reveal themselves. If your heart isn’t in it, it’s going to drive you nuts. You’ll do the bare minimum, then clock out at 5:00 and forget about it.

The second problem is companies clamping down on salaries. Yes, tech salaries of the late 90’s were obscene and needed to be addressed. But, the effort has gone too far. Companies now staff up on low cost, inexperienced, and poorly motivated drones with little desire for excellence. There’s no effort to hire real talent. HR departments recruit solely by filtering thousands of resumes based on keyword searches and then sorting by salary.

There’s a misconception that developers are plug-and-play. Somebody whined about wanting more salary and quit? Replace them with someone cheap! Companies place little value on experience.

Companies round out the team with one or two superstars – either old schoolers, or young heroes with passion. Too bad they give these champions no authority over architecture or design. Misguided flat team structures mean the hot shots must rely solely on persuasion to have any influence. They are generally shouted down by sophomoric colleagues too lazy to learn anything new or too insecure to entertain any ideas other than their own.

The hot shots get their life and enthusiasm sucked out of them! They’re left to support and maintain the wreckage left behind by the loudest code slinger. They quit under the naive belief that “this must be the only company this dysfunctional!” They soon discover that their new job is no better. The madness is everywhere these days.

What now?

Oh, I still work on my pet projects at home. It’s partly because my job requires me to keep my skills sharp despite leaving the day-to-day programming behind. It’s mostly because I still get a kick out of making creations and making them better.

Some of my “old school” former colleagues have moved out of development, too – some to eagerly pursue other career goals, others with great reluctance and resignation. I know at least one who left software entirely to become a high school teacher. The rest slog through the nonsense, cuss under their breath, and long for the early days when the work was still fun.

Will the corporate world ever start valuing experience again? Will they truly trust a project to the “best and brightest” and not just the “cheapest and most readily available”? Maybe. I think it still works that way in the Silicon Valley where true software companies that understand the challenges of the trade still thrive.

Unfortunately, it’s the companies whose core competencies are not software related that’ll continue to burn out and demoralize the up-and-coming software gurus. Telecoms, banks, and airlines, for example. They all see techies as a pure expense – not specialists who can efficiently automate and streamline their businesses. They’ll burn through millions of dollars on failed digital monstrosities by scrimping on their most vital employees and driving off their best talent.

These companies don’t need an army of unmotivated minimum wagers. All they really need is a handful of old schoolers, pizza, and little No-Doz.

Their recommendations to customers are simple and easy-to-follow. If someone calls you on the phone asking for your ATM number, don’t give it to them! Only divulge secret information when you initiated the phone call. Be wary of emails asking for your social security number or credit card numbers. You know the drill.

So, why is Wells Fargo undermining all of these self-defense measures by sending out emails with hyperlinks to a Web site asking for your online banking username and password?!

It’s easy to get fooled

My step-mother is timid about computers, but last year she entered the brave new world of online banking. At about that time, I received a phishing email from a scammer masquerading as Chase Bank. The email was slick. It had all the images and logos copied from the legitimate Chase Web site. When you clicked the embedded link, it brought up a beautifully forged Chase Web site with a login screen.

Well, I knew it was a fraud – mostly because I’m not a Chase customer. The embedded links were pointing somewhere besides Chase.com, but that was hidden in the HTML. All in all, it was a high quality fake. But I wondered “what happens if I play along?”

I clicked a link that brought up a login page. I entered bogus credentials and voila! I was “authenticated”. Obviously, they let any username/password combination get through. The next screen asked for my credit card number, ATM number, mother’s maiden name, etc. At this point, had I been a real Chase customer, the hucksters would have had my login credentials and complete control over my online account.

Adding to their cleverness, they set a cookie in my browser so subsequent clicks on the email link would cause me to be redirected to the real Chase Web site. I guess this was just in case their “mark” got suspicious and wanted to check out the link a second time. By getting sent to the real Chase site when the scam was over, you’d see your real account information and, ostensibly, not get suspicious.

As a techie, I was pretty impressed with their ingenuity. I was so impressed that I had to admit, in a weak moment, I could easily have been snookered. Heck, it only takes a momentary lapse of judgment to type in your password.

So, I told my step-mother and a few other family members about it to show them just how convincing a hustle can look. Not all criminals are bad spellers (one of the most common hallmarks of a phishing scam). I wanted to sensitize them to the danger.

Wells Fargo gets stupid

I’m not a Chase customer, but I am a Wells Fargo customer. Click on the thumbnail on the right to see a screen shot of an email they recently sent me. While telling me my “privacy is assured,” they invite me to click on an embedded hyperlink and “Sign On To Online Banking.”

My spidey sense went off on this. Large lights spelling “Danger! Danger!” flashed in my headed. I couldn’t imagine this being anything other than a trick to get me to divulge my online banking credentials to a cyberhoodlum.

But, the email looked eerily familiar. This August 9th email looks similar to an email I received on June 14th. Scammers seldom try the same shtick for too long, so a two-month-old scam seemed unusual. Also, I had recently received a third, similar email that had my full name embedded in it (an unlikely mass-emailed phishing scenario).

So, I dug into the raw contents of the email. Here are the SMTP headers:

Return-Path:
Received: from om-wellsfargo.rgc3.net ([66.35.244.164])
by smtp.gavaghan.org (JAMES SMTP Server 2.2.0) with SMTP ID 571
for ;
Thu, 9 Aug 2007 17:58:11 -0500 (CDT)
Received: by om-wellsfargo.rgc3.net id hnee720664ov for ; Thu, 9 Aug 2007 16:00:00 -0700 (envelope-from )
MIME-Version: 1.0
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 9 Aug 2007 16:00:00 -0700
From: "Wells Fargo Online"
Reply-To: "Wells Fargo Online"
Subject: Online Banking Basics - Privacy
X-cid: wls.1469.253
X-sgxh1: upsLxnHNHnoHgQhjn
To: mike@gavaghan.org
X-valueof-AFFINIUMCODE: 2007080848744
X-valueof-DATA5: null
X-valueof-CELLCODE: YYMMLCOLB22
Message-Id: <4288517.1186700292455.JavaMail.SYSTEM@SOMBRITA>
James-RelayLocation: id=38045;country=US;region=CA;city=Redwood City;postalcode=94065;latitude=37.5331;longitude=-122.247;
dmacode=807;areacode=650;isp=Exodus IDC - SV/SC8;organization=Responsys;error=;


What can we glean from the headers? Most importantly, the IP address of the server that sent the email. I traced the IP address back to a Redwood City, California-based marketing company called Responsys. (Many thanks to the geolocation technology at MaxMind for making this possible!).

Is it possible Responsys had their email servers compromised by a hacker and turned into spam zombies? I was opened to that possibility, but ruled it out once I realized, from the raw HTML in the email, that this email was definitely legit.

When I looked at the raw HTML to see where the links were really pointing, I saw they were all pointing to the legitimate Wells Fargo domain name. You can see the raw contents of the email for yourself by clicking here.

Conclusion: this is not a phishing scam. This is a legitimate email from Wells Fargo, sent on their behalf by Responsys, as part of a marketing campaign.

Marketing email from banks is bad juju

What were they thinking? The IT security folks at Wells Fargo must be going nuts! They need to give a stern lecture to the brainless suits in marketing who thought this was all a good idea.

Wells Fargo’s own website warns customers about phishing on a page replete with real world phishing examples. Their “fraud tips” admonish customers to be wary of suspicious emails.

My favorite is their page that characterizes some of the common attributes of fraudulent email. Many of the attributes pertain to Wells Fargo’s own marketing campaign! Let’s take a look:

Fraudulent emails will often:

“Ask you for personal information” Their email contains links to pages that ask for your username and password.

“Appear to come from a legitimate source” Well, duh! It is coming from a legitimate source.

“Link to fraudulent websites” The text goes on to say “fraudulent emails may direct you to counterfeit websites carefully designed to look legitimate”. The world is filled with spammers who can’t spell and who do amateurish hack jobs on forged sites. But, Wells Fargo acknowledges that some fraudulent Web sites are so elaborate they’re nearly indistinguishable from the real thing. The bogus Chase site I went to was probably a copy-and-paste job directly from the actual Chase site.

The moral of the story? There are no easy ways – particularly for those who aren’t as tech savvy as the readers of this blog – to distinguish legitimate marketing from phishing.

What Wells Fargo ought to do

Stop sending email that asks for passwords.

Banks don’t call you on the phone to ask for your ATM number. That’s a cardinal rule. Banks always advise you not to give away secret information, like your social security number, over the phone unless you place the call. Assume anyone that calls you is a hustler.

This is easy advice to follow – and it works. Banks would be ill advised to start initiating legitimate phone calls to customers asking for personal information. It would cause customers to let their guard down if some calls are real.

So, why does Wells Fargo insist on muddying the waters with regard to email? It would be most secure to simply tell customers “we’ll never send you email asking for personal information.” Assume all such email is a scam. Period.

Unfortunately, Wells Fargo is telling customers “some email that looks like it comes from us is real, and some isn’t.” The burden is on the customer to discriminate. But, by Wells Fargo’s own admission, that’s pretty hard to do!

Why am I picking on Wells Fargo? It’s solely because I happen to be a customer (and, despite this rant, I’m a very satisfied and happy customer). Perhaps Chase, Bank of America, Citibank, and every other major financial institution operates like this. I don’t bank with them, so I’m not in a position to know.

But, if other banks send out email like this, they should stop. If not for me, do it for my step-mother and all the other less-geeky folks who could use a hand defending themselves in the sometimes dangerous online world.

It’s not the recruiter’s fault.

Many IT staffing companies are utterly clueless about the extraordinary value their recruiters add to the company’s image in the eyes of job candidates. I’ve been a software professional since 1992 — C++, Java, and now C# — and I value the relationships I’ve formed with a handful of hot-shot recruiters in the Dallas area. Later, I’m going to hold up a lady named Shanna as an example of the sort of top-notch recruiter staffing companies should strive to attract and retain.

Unfortunately, many companies believe technical recruiting is a low-skill, no-experience-necessary sort of job. All they need to do is hire a bunch of low-pay, disposable cube drones like a telemarketing firm filling a call center. Make as many phone calls as possible and they’ll maximize the number of techies they reach, right?

The recruiters are essentially thrown to the wolves. They’re not given the training they need. They’re given poor information to pass on to candidates. They suffer the ire of techies who probably got five other calls recently from poorly equipped recruiters. When the recruiters burn out, they quit and get replaced by some other college sophomore on summer break.

Technical recruiting is hard work! It’s a highly skilled job where experience should not be undervalued. Give these people the training, tools, mentoring, and respect they need and deserve!

Would you like some fries with that contract?

There’s a staffing company — let’s call them “Phone Monkeys ‘R’ Us” — that has me in their database. So, they call me monthly. Here’s an example of a recent call:

“Hello, Mr. Gavaghan. My name is [mumble, mumble] and I’m looking for someone interested in [voice fades out briefly] with a lot of experience in [unintelligible]. Would you or someone you know be interested?”

His pitch was as clear and enthusiastic as the speaker at a fast food drive-thru. Who can blame him? He was reading from a script, and he had already called 50 other people that day. All he knows is he’s on a short term gig to make a few bucks before he moves on to a “better” job.

His employer rationalizes that if he brings in one candidate for every thousand calls, that’s enough to turn a profit. Isn’t that the arithmetic spammers use?

The voice and image of the entire company

I want to find an executive at Phone Monkeys ‘R’ Us, grab him by the shoulders, and say:

“So, you’ve got a stylish office on the top floor of a swanky building in downtown. You’ve got leather chairs, a cool looking fish tank, and a pot of freshly brewed Starbucks up front where the eye-candy receptionist greets visitors. Guess what? I haven’t seen any of it!

I need something that’ll make me believe your company is one worth investing my time to research. If you’re different from all the others, show me. You might be a first rate outfit with some high paying clients, but over the phone you’re indistinguishable from the scores of fly-by-nights that fill this town. Your recruiter isn’t merely my first impression. Right now, he’s my only impression!

To job candidates, recruiters are the voice and image of your entire company. Before I’m going to sit down in your office to close the deal, it’s your recruiter that’s going to bring me in the door. Now do you see how important they are?”

That’s why the execs at Phone Monkey should fear a competitor’s recruiter like Shanna.

It’s the relationship, stupid

Shanna first called me back in the late 1990’s when I was still doing Java work. I remember her giving me a detailed job description for the sort of work I’d be interested in (which is also an accolade for the account manager who put the job description together in the first place). I was impressed, but unavailable.

Shanna would continue to check in with me from time to time. Each time, she presented a job opening that seemed tailor made for me. She was professional and jovial. I suppose it’s quite a trick to be aggressive without appearing aggressive.

She checked up on me for years without actually placing me anywhere. Then, in 2003, I found myself on a disastrous contract, and I needed to get out quickly. I could have posted my resume on a job board, but I thought I’d call Shanna first.

Did you catch that? I called her. Not the other way around.

I’m “on the market” for maybe two weeks every one to two years. Every time a recruiter calls, I’m probably not looking for work at the moment. When I do start a job search, the odds of a recruiter calling me within that narrow time window are pretty slim.

With Shanna, however, I had a relationship. Without actually trying, her name stuck in my brain over the years. She’d call, and I’d think to myself “Oh, yeah. I remember her. She’s the recruiter who’s always trying to fill the cool jobs”.

Now, contrast that to Phone Monkeys ‘R’ Us. They call monthly, and I get a different recruiter every time. If I hit the market today, I wouldn’t even know which Phone Monkey to ask for! While the Phone Monkeys are dialing away on fruitless calls to candidates, Shanna has candidates calling her!

Sure enough, when I called, Shanna had a position for me. In days, I had an interview and an offer. It would turn out to be a nearly two year stint and one of the most professionally rewarding contracts I’ve ever had. After years of trying, she and her employer were finally making money off of me.

It gets better. When colleagues ask for a referral, I send them to Shanna. I don’t send them to her staffing company, I send them directly to her. “Call and ask for Shanna,” I say. Heck, through years of mergers and acquisitions, her employer has had no fewer than three names! The company’s current name is generic sounding and carries little recognition among techies. It doesn’t matter, because Shanna is their voice and image. They’ve got somebody on the payroll who knows how to bring people in.

My advice to IT staffing companies

I don’t know how long Shanna has been working as a technical recruiter, but she’s been working with me at least eight years. In addition to Shanna, I also have a few other recruiters on my “short list” of phone numbers to never lose. All of them have many years of experience.

Think “fewer, but better” recruiters. Do what it takes to keep experienced recruiters on board. Sure, you’ll need to pay them more, but their bang-for-the-buck will be a win-win. Leverage their experience to mentor new recruiters.

Think “fewer, but better” phone calls. Have recruiters spend more time reading the resume and preparing for the call before dialing the candidate.

Don’t call techies just to ask for a referral. You’ll only peeve them. I don’t care if your recruiters call only every other month. You’re competing with a hundred McStaffing companies that call twice a week. Don’t let someone else’s bad reputation rub off on you. If your recruiters are respected by the techie, the referrals will come automatically.

Prepare for a conversation, not a sales pitch. Help recruiters gain a basic understanding of what technology is out there. Candidates are bound to ask for more information about a job, and it’s important that the recruiter can either answer the question or accurately relay the question back to the hiring manager. (i.e., Java is nothing like JavaScript – not even close!)

Build a relationship. Nearly all calls will be to a candidate who isn’t available right now. If your recruiters are good, they’ll be remembered. Candidates will call them when the time is right.

What do other techies think?

Am I way off base, here? What makes you really want to work with a particular staffing company? What makes a staffing company appealing to techies? How can great staffing companies – over the phone – distinguish themselves from the brainless Phone Monkeys filling the market?

After eight years of slinging Java code, I converted over to C#. The C# language borrows (steals?) heavily from Java, but it also has added some features. Some of C#’s most valuable introductions to the language have now been adopted by Java. Things like attributes, generics, and auto-boxing – which first appeared in C# – have now been added to the JDK as of 1.5. It’s only a matter of time until Java adopts using-blocks and the yield keyword, too.

Despite this back-and-forth trading of features and enhancements, each language still maintains its distinct flavor. Some facets of each language – many of which are quite subtle – will probably never be adopted by the other simply because their introduction would create such a fundamental shift in language concepts it would invalidate a lot of prior work.

So, I was careful about my approach to C#. My Java work had been preceded by seven years of C++, and I remember what that transition was like. Although Java is strikingly similar to C++, the similarities are deceiving. Seemingly minor differences between the two languages created a sea change in how I thought, how I designed code, and how I tested applications.

Java introduced me to new things like garbage collection, type reflection, and meaningful exception handling. At first, I tried to write Java like a C++ programmer. It took some time to get my brain adjusted to a new paradigm. Once I did, however, I was able to unleash the true power of the technology by leveraging new, fundamental concepts of the language.

Hence, I approached C# with an abundance of caution. Despite C#’s similarity to Java, I didn’t want to stay shackled to “the Java way” of doing things. I kept a sharp eye on what other developers were doing and tried to gain insight into the most effective way to adopt the language.

Now that I’ve gained experience in C# – but continue to do some Java work on the side – I can see how seemingly trivial differences in the languages impact my design decisions. Off the top of my head, two things come to mind…

C# events and delegates

This is a huge win for C#. I use the Observer Pattern all over the place now.

The Observer Pattern, of course, allows you to decouple the events generated by an object and the objects that listen for them. In Java, making this work requires a lot of effort on the part of the programmer. For your observed class, you need to create an interface which captures all of your events, manually implement methods to add and remove your listeners, and manually iterate over your list of listeners in order to raise events.

Even implementing event listeners is ugly. You need to create an implementation of the event interface – stubbing out all of the uninteresting events with no-ops – and have that class make callbacks to your business object. Anonymous inner classes help a bit, but they still clutter up the code.

java.util.Observable – a weak attempt to encapsulate this design pattern into a class – has been around since JDK 1.0, but it fails to be useful in anything but contrived, academic examples.

In short, the level of effort required to make the Observer Pattern work in Java is so overwhelming it is seldom implemented except in the most compelling cases. Most Java developers, though not intentionally lazy, simply don’t think to reach for this tool and end up creating tightly coupled code which is harder to test and maintain.

C#’s decision to add events as first-class members of a class and delegates as first-class data types makes hooking up listeners to events as easy as calling the += operator. For those of you unfamiliar with C#, think of delegates as typesafe method pointers and events as special class properties that automatically manage a collection of delegates. All of those listener interfaces and anonymous inner classes from the Java world get reduced to a single line of code.

The complexity of the Observer Pattern in Java makes me reluctant to use it if I can envision a “cleaner” solution, but the simplicity of implementing the pattern in C# makes using it second nature. As a result, I design code in C# that looks fundamentally different from what I’d design in Java. It’s not deliberate. It’s just that the nature of each language naturally steers me toward a particular way of solving certain problems.

Virtual methods

In Java, all methods are overridable by default. To disallow overriding a method, you have to explicitly declare it using the final keyword. C# is exactly the opposite. A method on a C# class may not be overridden unless it is explicitly declared with the virtual keyword.

A minor difference? No way. In C#, the inability to make minor behavioral changes to third party classes is driving me insane!

The only semi-legitimate rationale I can think of for this default behavior is performance. Invoking an overridable method requires an extra step of finding the method pointer in a lookup table instead of invoking it directly. Still, this is a silly argument. If your application is so in need of this performance boost, you are using the wrong programming language.

Allowing other code to override your class’ methods makes your classes more extensible. Although some classes use the Template Method design pattern to deliberately leverage overridable methods, most class designers can seldom predict how and where the consumers of their classes might benefit from polymorphic behaviors.

Developers almost always take the default path unless they’re envisioning a particular usage. Therefore, the default path for class methods should be the most useful and extensible one – overridable unless explicitly declared otherwise.

Once again, a seemingly trivial distinction between two languages drives my thought process. Knowing that third party C# classes probably limit polymorphism (unless every method is declared virtual), I’m forced to approach my problem solving differently than I would in a Java application.

Conclusion

Do these two examples imply that either C# or Java is “flawed”? No. But, they certainly highlight how moving between the two can create some consternation for developers as they are forced to “think differently”.

How does moving between languages make you think differently? Please comment.

In our rapidly changing field, there are seldom “textbook solutions” to problems. The textbooks are out of date shortly after they go to press! Thus, we defend our technical decisions – be it object modeling or database design – by pointing out the flaws in the alternatives. We become aware of these flaws by reflecting on past experiences with the same problem. A successful solution to the problem then produces a design pattern, and a proven design pattern applied to future projects allows us avoid prior mistakes.

That’s perfectly reasonable – mostly. Unfortunately, that can lead to a trap when we forget the original problem behind our so-called “best practice” solution.

I heard the parable about “Cutting the Ends Off the Pot Roast” early in my career. I think it really captures the danger of defending software architecture and design decisions with the simple argument “because that’s how it’s done.” A “best practice” solution applied to the wrong problem is costly.

Cutting the Ends Off the Pot Roast

Our story begins with Bill and Mary – a happy couple preparing dinner for a family get-together. As Bill busily chops vegetables and peels potatoes, he observes his wife cutting the ends off the pot roast she’ll be cooking for the meal. As a programmer, Bill believes every step in a procedure should be deliberate and serve a purpose. So, perplexed at his lovely bride’s decision to chop off and throw out two perfectly good chunks of meat, he asks “We are you cutting the ends off the pot roast?”

“Because that’s how you make pot roast,” she tells him.

“But, what good does it do?” he asks gently, taking care not to offend someone he recognizes as a far more capable and experienced cook than himself. “Does it make it taste better?”

“My mother taught me how to make pot roast, and she always told me to cut off the ends. That’s just how you make pot roast.”

Soon, the guests begin arriving. The first is Mary’s mother. As an accomplished cook herself, Bill always knew it was his mother-in-law’s careful mentorship that turned Mary into the culinary wizard she had become. Certainly, she must know the answer to this riddle!

“You taught Mary to cut off the ends of the pot roast before cooking it. Why is that?” he asked.

“Because that’s how you make pot roast,” answered his mother-in-law. “I learned how to cook by watching my mother, and she always cut the ends of the pot roast.”

Bill married well, and he knew it. His wife was part of a long lineage of masters in the art of fine cuisine. Their experience spanned generations. They had accumulated a wealth of skills and knowledge that could compete with all the great chefs of the world. Certainly, the step of cutting off the ends of the pot roast must be some long held secret to dinnertime delight! But why? How does it help? Does it enhance the flavor? Does it make the meat more tender?

At last, the family matriarch arrives. Mary’s grandmother, the inspiration behind three generations of pot roasting perfection, is greeted at the door. It was Bill’s last hope of understanding the most mysterious step of this family recipe.

“Grandma, you taught Mary’s mother to cut off the ends of the pot roast. Mary cooks pot roast the same way, too. They tell me that this is the way pot roast is made. Why is this such an important step?”

Grandma, incredulous, looks at both women and asks “Do you still cut the ends off of the pot roast”.

“Yes,” they said in unison. “That’s how you showed us to make pot roast. We know that’s just how pot roast is made.”

Grandma broke into hysterical laughter. After she composed herself again, she explained “Honey, I cut off the ends of the pot roast because my pot was too small! Cutting off the ends of the pot roast was the only way I could get it to fit!”

The Perils of Experience

If you don’t see how this applies to software development, then you haven’t been paying attention. Cutting the ends off of the pot roast was a “best practice” solution to the problem of the pot that was too small. Because Mary and her mother never understood the underlying problem that motivated this preparation step, they turned a necessary practice into a wasteful one when their larger cooking pots obviated the need to cut the pot roast down to size.

How can we avoid following into traps like this? Never be satisfied with the rationale of “just because.” Every technology decision that carries any cost must be justified by a savings of greater value.

Mentoring junior programmers is a great way to keep us on our toes. It’s often the uninitiated – those unfamiliar with “how things have always been done” – that challenge us the most to explain why we do what we do. If we can come up with a persuasive argument, we solidify our own understanding of the problem and, consequently, enlightened our student. On the other hand, if we can’t answer the simple question “Why?” then we probably don’t fully understand the problem we’re trying to solve.