Software Engineering and Hockey–Not As Different as You May Think!

November 12th, 2009

GAINING PERSPECTIVE BY BEING OUT OF THE ACTION

Hockey is one of my favorite sports.  I love to play it, sometimes I like to watch it.  Even when you are playing, though, you watch while you are on the bench waiting for your shift.  It is when watching that one gains the most appreciation for the strategy and finer points of the game.  This is our first similarity to software engineering: the unbiased perspective, where you can really ’see’ what is going on, is only gained from being ‘off the ice’ or ‘not a part of the project’.  In either case, if you are in the action your perspective is tainted and you will make errors that you would definitely not if you were ‘off the ice’.  You’ll be a better hockey player, or member of an application development team, if you can lift your mind out of ‘the game’ to look at what is going on with some degree of detachment from time to time.

In the same light, I used to tell a sales manager that worked for me to ‘lift your head out of the swamp for a while each day’.  I said thus because he was getting so mired in the day-to-day goings on that he was losing sight of what we were needing to achieve in the coming weeks, months, and years.

TEAM COMPOSITION

Managing software engineering is my work.  The ‘game’ is application development, played out in offices and on computers instead of on a few centimeters of frozen water.  It takes a team to build an application, the larger and more complex the application, the more varied and specialized the roles on the team.  The need for a team composed of people fulfilling different roles is our next similarity.  In hockey, there are two wingers, a center, two defensemen, and a goalie on the ice at one time.  Each role requires a different mindset and skills to do it well.  In software engineering, we have project managers, software architects, developers, quality assurance staff, and documentation staff.

SOMEONE HAS TO BE THE BOSS

Each hockey team has one and only one captain, just as there must be one and only one head project manager for each application development project.  Someone has to be the boss, able to make the decisions that must be made in a timely manner.  Oh yes, there are assistant captains and vice-project managers, but the reality is that there needs to be a bit of benevolent dictatorship going on for a team of either kind to be effective.  Some of the toughest decisions involve whom is going to do what.  The average winger can’t play defense very well, and let’s not even talk about putting anyone but a born and bred goalie in-between the pipes!  In the same light, most quality assurance staff would not make good developers.  So, in both hockey and in application development, the ‘captain’ has to put each team member in the role that their skills and temperament make them most suitable to fulfill.  And those that don’t fit any of the roles needed on the team should be playing on a different team :)

THE DEVIL IS IN THE DETAILS

Finally, let’s talk about execution.  In hockey as in application development, ‘the devil is in the details’.  All the little things have to come together to make the big thing a success.  Passes that are crisp and on the tape, everyone giving their all from start to finish of the game, and playing your position properly.  These are the elements of winning on the ice.  Play the details right and the game will go your way.  The same goes for application development–good system architecture, robust and efficient code, effective quality assurance, and good usability make for a successful application development project.

OK, so MAYBE this whole blog entry is really kind of stretch…but at least I got to write about what I do and what I like to do!

Yours in software engineering,
Dean Whitford, B.Comm.
Chief Operating Officer
DraftLogic

That Last Percent of the Work

November 4th, 2009

I have been a software engineering project manager for eleven years now, and it still amazes me how painful it is and how long it takes to finish up that ‘last percent’ of the work!

“That doesn’t make any sense” you say?  Or perhaps you think the last percent of work should not be any different from any other part of the work?

Following that logic, our 20,000ish hour development effort should take a couple hundred hours for the last one percent to be finished.  The reality is we have burned five hundred or so hours and counting.  The light at the end of the tunnel is in sight but we are crawling toward it instead of running!

There are a number of reasons for that last percent of work taking such a disproportionate amount of effort to finish off.

HUMAN NATURE

A big part of it is the developer’s succumbing to human nature and the project manager letting such a thing happen…because it seems harmless when you consider the decisions one by one.  What I am referring to is most people’s tendency to go for the ‘easy kills’ when assigned a number of tasks.  We do that because we like the feeling of success and forward progress we get when we finish a task.  In organizations where there is performance evaluation based on completing tasks and having quality assurance sign off on them, going for the easy kills is sometimes an act of survival, i.e. the system makes you do it, regardless of whether you want to or not.

The project manager’s part of this is either not assigning a priority to the tasks to ensure that things get done in a particular order regardless of their relative difficulty OR in letting it slide when some of the developers skip the hard stuff.  My sin is usually the second type.

BACKWARDS RIPPLE

Another material contributor to the hours spent finishing the last percent of work is dealing with more ripple effects than usual.  Once your application is basically completely built, any change you make has a higher probability of affecting more code–much more in both respects than when you are first starting to build the application.

LATE STAGE REQUIREMENTS CHANGES

In the same light, requirements changes that are introduced at the end of the job have a higher probability of affecting more code.

DEALING WITH IT

So now we know how we got to this painful stage, how do we get through it?

This first thing is to manage the expectations of all the stakeholders.  Let them know that the task list is much shortened from before but that the items left are difficult and risky.  Let any of those who are asking for requirements changes know the full potential impact of their requested change & suggest, where feasible, that the change would be best left until after the first version of the product is tested and released.

The second thing is to maintain the development team’s morale.  Grinding through the tough tasks and dealing with ripple effects is going to be stressful, especially for those who either need or are used to frequent gratification from completing easier tasks.  Congratulate each developer for the small gains that will be made as they happen.  Keep the team updated about progress that is being made.

Finally, stay positive and stay focused!  Your clients on the one side and development team on the other will sense any fear or negativity you feel–and it will adversely affect their attitude.  Celebrate progress made, however glacial.  You need to keep your focus, the clients’ focus, and the development team’s focus all squarely on completing the product.  You will need to be strong in resisting any changes that are not absolutely necessary, whether proposed by the client or by your development team.  In this light, you need to be prepared to re-evaluate the inclusion of any functions that are causing major problems.  If feasible, delay a troublesome function for later in order to expedite the completion of the release.

NEXT PROJECT

OK, so you and your team pushed through the resistance and finished the release.  Can you avoid making the ‘last percent’ so painful on the next project?  Well, you won’t be able to get rid of all the nasty nuances tied to the last percent of work, but much of it can be managed away.

Ensure that your developer performance evaluation and task tracking system are sensitive to task difficulty and priority.  Do this by assigning higher completion credit to difficult issues & assigning an exact relative priority to each task.  The completion priorities must be enforced throughout the project, otherwise the tough items will pile up for late in the project.

Throughout the project, carefully evaluate any change requests, whether from clients or the development team, for the degree of ripple effect and for how truly immediate they need to be.  Change requests that can reasonably delayed to a future release should all be delayed.  Ones that cannot be delayed will need to have their time required, including dealing with ripple effect and added quality assurance time, push the project completion date forward commensurately.

Until next time for more software engineering ramblings,
Dean Whitford, B.Comm

Chief Operating Officer

DraftLogic