Stature Software

Archive for the ‘Software Development’ Category

Software Developer Productivity - The First Deliverable Dip

August 4th, 2008 by Gregory Silvano Posted in Developers, Software Development | 1 Comment »

I have a theory about the productivity of software developers, and I’m going to call it the First Deliverable Dip.

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.

 Tags: deliverable, milestone, productivity, software developer

The Most Important Project Manager Skill?

July 24th, 2008 by Gregory Silvano Posted in Software Development | 1 Comment »

For the past few days, I’ve been working closely with Stature’s newest hire, Mike Bykow.  He’s a Project Manager at Stature and is handling several projects for us.

As I was driving him back to South Station yesterday, I listed all the things I think are important for a Project Manager at Stature (or anywhere, for that matter).  I mentioned the obvious things, like: communicating with the clients, making sure you understand every facet of the application, keep in touch with the developers frequently so you’re on top of schedule slips, etc.

But then I told him something that, the more I expanded on the idea, I realized it was the most important skill of all.  I told him he needs to learn to finish the project.

Software projects can go on forever.  Literally.  They can be tweaked and tweaked for months on end.  This is beneficial to no one, but especially for a company like Stature.  We need to finish projects to maintain profit since nearly all of our projects are fixed-price and we don’t issue change orders (see our 3 Guarantees).  So to have a project run over by a month is a big deal for us since we can’t recoup those costs.  Software Projects don’t end naturally - they need to told to end. 

If I were a Project Manager, I’d want to be known as The Closer.  The guy who wraps up his projects on time, on budget, and to spec.  If another project is running past schedule, I want to be the guy they bring in to restore order and get the project done.

In the coming weeks, I want to expand on this topic and discuss the tricks we’ve learned over the years that allow us to close a project.  It’s something you learn through experience and observation, and I think with just a few high-level rules any Project Manager can become The Closer.

 Tags: project management

The Hard Button

June 30th, 2008 by Gregory Silvano Posted in Software Development | No Comments »

So, Staples made millions on the “Easy Button” idea.  Just push a button and it’s done.  Easy.  Sort of like my favorite UI line, where the users just want a big button in the middle of the screen that says “Do it”.

I think Toys R Us watched those Staples commercials and thought “you know, I think they’re on to something there.  We should do the exact opposite.”

I went to Toys R Us to buy my daughter a tot-friendly camera.  I found the Fisher Price Kid-Tough Waterproof Camera, grabbed it, and went to check out.  Here’s the conversation (no exaggeration at all):

Clerk: May I have your phone number?

Me: I’d rather not.

Clerk: Sure, no problem.  That’s $52.49.

Clerk: We offer a replacement plan for only $4.99, where we’ll replace it if…

Me: No, I’m all set, thank you.

Clerk: OK, no problem.  We have a special on AAA batteries.  Would you like to buy a 12 pack…

Me: No, I’m all set, thank you.

Clerk. OK, no problem.  Would you like to get 10% off by opening our credit card…

Me: No, I’m all set, thank you.

Really - that’s how long it took to get out of the store.  The clerk was very nice, don’t get me wrong.  And he wasn’t pushy or rude.  But talk about the anti-easy button.  I think the corporate office needs to seriously rethink its checkout procedure.

Sadly, I’m sure I’ve designed and written software that behaves just as poorly.  We’ve all used bad software, and the problem is that unlike my once-a-year trip to Toys R Us, poorly designed software gets in our way dozens of times a day, over and over and over.

It’s a great camera, by the way.  The batteries don’t last very long and the display is a little slow to render, but she loves it.

 Tags: design, easy