While reading a June 12, 2008 Time Magazine article “How He Did It,” an account of how Barack Obama came to win the Democratic nomination, it reminded me of the dynamics of a software project.   Early in the Obama’s campaign, near panic set in;  as Obama was drawing record crowds and record donations, he still trailed Hillary Clinton by 20 points in the polls.   Many in his campaign feared his approach to politicking would not get the job done.  Obama’s “top moneymen were urging him to rethink his strategy, shake up his staff, go negative.” 

Obama made an unscheduled appearance that Sunday night and called for a show of hands from his finance committee.  “Can I see how many people in this room I told that this was going to be easy?” he asked.  “If anybody signed up thinking it was going to be easy, then I didn’t make myself clear.”  A win in Iowa, Obama promised, would give him the momentum he needed to win across the map - but his backers wouldn’t see much evidence of progress before then.  “We’re up against the most formidable team in 25 years,” he said.  “But we’ve got a plan, and we’ve got to have faith in it.

Isn’t that what often happens on a software project? At the first sign of trouble, there is pressure to throw the discipline overboard.   It takes too much time.  Right?  Sometimes, it’s just decay: the team becomes too preoccupied with struggling through the issues, and the discipline melts away.

Does this Sound Familiar?

You’re on a team assigned to develop the next new product for your company.   The requirements are vague, and the date is aggressive.  The team struggles to nail down the requirements with key stakeholders.   Time is ticking away.  Completing the requirements definition is late, and it’s not clear when it’ll complete. 

Finally, some functional areas are understood well enough to start the developers on designs and implementation, but there are still a number of requirements that need detail and agreement.  Panic sets in.  Management wants to see something real, but you don’t have anything to show yet.  You’ve only started coding in a few areas.  The developers are tired of working through the requirements and designs.  They want to code it in the way that they think it should work. 

There is no way to deliver this project unless the team goes minimalist, so the thinking goes: no designs, no reviews, and no unit testing. Just code it, pass it to test, find the defects, and fix them.   If some of the requirements are vague, code them anyway and improve them with feedback.

The software manager gives in.  He throws out the plan.  Planning doesn’t work anyway.  He sets the team on coding and testing.  Six months after the original release date and many months of sixty plus hour work weeks, the product finally ships, barely.  The product releases with many deferred defects, and customers are unhappy because quality is low.

Faith and Courage

Even in software it often comes down to faith.  It’s unnerving to deliver on an aggressive schedule.  In the beginning there is a catch-22.  You’d like to get the team started on coding, but the delivery isn’t defined well enough to have them start.  It’s difficult to resist the temptation to have something more tangible than requirements and designs.  It’s comforting to see something, anything working even if having something working is an illusion that you are making good progress towards the deadline.

Who said software development is easy?  It’s a tedious, exacting discipline.   Have one semicolon missing, and the module won’t compile.   Use a less than comparison when a less than equal to comparison is required, and the program works maybe most of the time.  There are seemingly an infinite number of simple ways software can fail.   This is not easy work to get right, and surprisingly most times we get it right.

Yet, there’s always the temptation and often the pressure to fallback to cowboy development practices.   This isn’t only a symptom of traditional methodologies: even Agile software practices experience forces working against staying with the discipline. There will always be forces working against discipline, and the forces are greater when there is pressure to deliver.  Often it is fear motivating the behavior; it is the fear that you won’t meet the deadline.

Delivering software requires courage.  In “Extreme Programming Explained”, Kent Beck explains, “Sometimes courage manifests as patience.”   The practice of software development requires the leaders and the team to have faith in their development practices and the patience to stay with them when fear gives you doubts.  Who said software development is easy?