At first I thought: Huh?

One look at the demo and I was completely and utterly confused. But here’s the concept in a nutshell:

Google Wave is a new service that blends email, instant messaging, file sharing, and software collaboration into one giant messaging center.

I lifted this screen shot from Google in an effort to provide a clearer picture of Wave. And in case you haven’t heard – and you probably have- Wave is Google’s answer to the question: “What would e-mail look like if we invented it from scratch today?”

It’s kind of cool in a chaotic sort of way. You can’t help but to sit and take it all in – and that’s precisely what developers and industry observers are doing.

When developers first caught a glimpse of Wave at Google I/O they were giddy. The big reveal was compared to the Apple iPhone unveiling – and it had developers there wondering what Google Wave would allow them to create.  The potential apps are endless.

As for industry observers, well CNet’s Matt Asay bluntly indicated that Google Wave – with all of its promise –  is a shining example of just how poor most enterprise software remains.

Google Wave – It is the wave of our Internet future.

What’s next? The Google Wave app store?

Poor Microsoft Bing. It doesn’t have a prayer.

LinkedIn is not a popularity contest.

What good are 500+ connections if you don’t actually know any of them?  Are you suddenly more important (more popular?  more profitable?) if you have 1,500 connections on LinkedIn?  The goal of networking is to build relationships with people, not to collect their email addresses and add another notch on your Rolodex tally.

Today I have 185 contacts in my LinkedIn profile, a number that may decrease in the near future.  I’m going to remove anybody whom I am not 100% comfortable calling and just saying hello.  If I have to call you, explain who I am and where I work, then honestly I don’t think there’s much reason to include you in my professional network.  And that’s what LinkedIn is supposed to be - a professional networking resource.

Here’s my LinkedIn Network Quality Test.  To be in my LinkedIn network (not that it’s an honor), a contact must fit this criteria:

1. I trust you.
2. I like you.
3. I have had more than one email or phone call with you at some point in our relationship.
4. I want to do business with you sometime in the future, if we don’t do business together already.

That’s it.  These four criteria embody the exact opposite of the LION philosophy, which is simply: if you have an internet connect and can type my email address, welcome to my network.

Software projects have certain phases, as do all projects.  We have conception, brainstorming, kickoff, development, QA, implementation, etc.  Being a programmer myself, I know the parts of the project I like best.  I like the brainstorming and the kickoff, but by the time implementation rolls around I’m pretty much done with whatever it is I’m writing.  I’m sure many developers feel the same.

Now that I’m in management, I want to get a better understanding of developer productivity.  This matters a great deal to me since unproductive developers affect my bottom line.  With 52 software developers at Stature, if all our developers have just one unproductive day it equates to over two months of unproductive business days.

Wow, OK – I just scared myself with that statistic.  The bottom line is that it’s important for Stature to keep its developers productive, motivated, and happy.  Happy developers are productive developers, and productive developers pay my mortgage.

Alright, enough intro.  Here’s the meat of my argument:

I believe software development productivity dips immediately after the first deliverable, when the client first sees a functional version (or subset) of the product.

The “client” is whoever will be using the software.  For Stature, it really is a client.  But for an internal developer, your client is probably a business user at your company.

Here’s what happens:

1. The client works with the development team to design the product.  There are meetings, brainstorming sessions, and eventually some sort of spec.
2. The development team disappears for a period of time.  At least a few weeks if it’s a decent sized project.
3. The development team codes like mad and is highly motivated and productive.
4. The development team prepares for the first deliverable, probably a subset of functionality or a functional wireframe version of the application.
5. The client views the first deliverable.  It is probably presented to the client by the development team, and the client is walked through the functionality and progress to date.
6. The meeting ends.

Soon thereafter, developer productivity starts to dip.  Why?

1. This was the first time the client actually felt the application.  Specs are one thing, mockups are another, but to actually use the application is entirely different.  Now that the client has used the product, the first set of changes are about to come.  These changes will come soon – if not at the meeting itself (in the form of “hey, can we…” type questions), then within days afterwards.
2. Once the developers receive the changes, they need to make unanticipated changes to their code.  Even worse, immediately after the meeting the developers are probably working on the very parts of the product that are going to be changed by the client.

It is during this period that overall productivity dips.  The project isn’t moving forward with the same energy and productivity as before.  Sometimes the developers start to get that “Us vs Them” mentality, where the they think the business users are neophytes who don’t understand software development (hint: business users don’t understand software development; nor should they).  The developers are forced to abandon some of the cool parts of the code (hey, they spent 3 days getting that treeview just right!) and resent throwing the code away.

This productivity dip is inevitable but the affects can be minimized:

1. Warn the developers that the client is going to do this.  Just knowing it’s coming can make it easier to deal with it.
2. Immediately after Milestone 1, we often have the developers work on tertiary parts of the product.  Things like reports, admin-screens, password-reminder screens, etc.  We have them work on the parts of the application that need to be written eventually (but are often left to the end) and don’t require much client input.  While they’re working on this functionality, the client has the time to thoroughly (and thoughtfully) review the first deliverable and provide feedback.  In the meantime, at least the developers aren’t continuing to code something that may be altered by the changes being written up by the client.

The First Deliverable Dip is a real thing.  It can last for days or weeks depending on the changes requested by the client.  Normally the changes are more pronounced when it’s a brand new project that only existed on paper before the first deliverable.  In those projects, it’s really hard for the clients (users) to know how the product is going to work until they get time to play with it.  But with a little planning and lots of patience, it’s a part of the development cycle that can be managed.

And honestly, I don’t blame the clients one bit.  Imagine designing a car on paper.  Do you really think when that car is delivered from the manufacturer, it would feel exactly like you anticipated?  No way.  The radio controls may be a little awkward now that you actually get to use them.  The seats may be a little uncomfortable.  There may be a blind spot.  It’s the same with software projects – you just don’t know how it’s going to feel until you use the product.  That’s life.  Just plan for the changes and everybody wins.

All new projects at Stature are kicked off by our best developers.  Great developers don’t want to be bogged down for 6 months writing reports, suffering through code maintenance boredom.  They want to work on the new stuff.  They want to design and be creative.  Some of them want to lead a team of developers and be in charge.

Our method of managing developers works.  Perfectly.  A new project comes in and we’ll take one of our best developers to start the design and planning.  A junior developer will move up in the existing product team to fill the void.  In time, when he or she is ready, that junior developer will become the lead developer for the existing product and possibly lead a new product in the future.

The cycle need not be long.  Sometimes we find a prodigy developer who can lead a project within months.  But more often than not, lead developers happen because of experience and maturity, not skill alone.