JPR 2008: Tuesday morning, part 3

“70% Rowing Backward: Why is software development so messed up?”

Bruce Eckel convened this session, inspired a statement he heard from Cameron Purdy of Tangosol:

“70% of programmers are writing code that is going to have to be fixed to move forward.”

(Purdy is known for other insightful statements in the past…)

Bruce immediately clarified that he was not referring to deliberate misbehavior, but rather to effort expended by people who thought they were doing the right thing. The question behind the question was, “Why is it so hard for developers to keep in synch with each other and with the organization’s goals?”

As we discussed the issues, answers included:

  • education out of touch with the current software development, because of:
    • a focus on theory to the exclusion of application and best practice,
    • a focus on short-half-life skills without conveying the underlying concepts, or
    • a focus on a single language or platform without showing the bigger, longer-term picture;
  • curricula with no practice-oriented components;
  • no (or infrequent) code reviews, so that large amounts of code get written before anyone but the (single!) author sees it;
  • division of labor (e.g. framework dev vs. application dev.) with inadequate knowledge-sharing between dev groups; and
  • production environments and architectures which make rapid deployment (and rollback, when necessary) painful.

There was a fair bit of discussion about code reviews, especially about the fact that the most effective reviews are done by (or with) the most experienced developers. Under that assumption, how can code reviews be done without saturating the senior people? Several options were suggested, including:

  • on-line code reviews, via such tools as Google‘s Mondrian and Atlassian‘s Crucible;
  • frequent code walk-throughs (i.e. take small bites often, don’t try to swallow the elephant all at once);
  • pair programming (of course); and
  • post mortem discussions per load or milestone (common at Google, especially for problem cases).

The post mortem topic generalized into a the question of how to increase communication, both within a team and across teams (even including non-developers). Google has “grouplets” that meet to discuss common issues, concerns, and techniques. Some companies use reading rooms or tech talks for the same goal. Dianne Marsh‘s company holds lightning talks every other Friday. Others reported officially-sanctioned “long coffee breaks” as an opportunity for cross-pollinating conversations. Barry Hawkins mentioned weekly talks (any topic allowed: technology, post mortem, etc.) held on Friday mornings right before lunch as an effective stimulus for informal follow-up conversations.

A more formal approach added to the mix was the use of a structured panel discussion. A request for topics was made a month in advance, the collected list was redistributed for voting, and the winning topic(s) provided the subject matter for one or more panels.

Several people responded to the point that personality and personal responsibility are crucial. It’s easy for a programmer (responding either to schedule pressure or a desire for higher productivity) to go “heads-down”, but there’s a risk that (s)he will lose sight of the big picture by doing so. Worse, some developers seem to want to “stop studying and just do it”, while others see learning as a career-long process. A popular, related theme was the need to retain humility and a beginner’s mind, rather than becoming a self-perceived expert (a small boy with a hammer, who sees everything as a nail). Regardless of what our environments offer us, we are responsible for our own skills and development, and for our influence on those with whom we work. Carl Quinn admitted, “We drag the quiet guys to lunch.”

Returning to the environment and organization, we also discussed physical set-up (cubes, offices, open space), technology (using a chat server to support constant, open communication), employee life-cycle (aptitude testing for applicants, “how we do it” training for new-hires, mentoring, and internships), and relationships with other parts of the organization (e.g. having a project-level “war room” in common with development, QA, marketing, etc.)

There were also complaints about interruptions and noise from non-development co-workers who don’t respect the times when a long attention span is needed. This was balanced by recognizing that developers can’t “go dark” for so long that they loose communication and shared vision.

In fact, I perceived balance as a constant theme throughout the discussion. A successful software development organization must be alert and flexible enough to maintain a dynamic balance among a number of forces:

  • short-term demands vs. long-term vision,
  • flexibility vs. formality,
  • constant communication vs. quiet “think time”,
  • moving among the roles of craftsman vs. engineer vs. scientist,
  • popular “building trades” and “factory” metaphors vs. the unique pressures of fast-moving technology,
  • the legitimate business needs of cost and schedule predictability vs. the equally legitimate difficulties of dealing with highly-complex systems and incomplete or ad hoc requirements, and
  • moving the art forward vs. dealing with what we have today.

Of course no one argued with the strategy, voiced late in the session, “Hire smart people and turn them loose on a problem!”


Suggested follow-up reading:

Pair Programming Illuminated
QBQ! The Question Behind the Question: Practicing Personal Accountability in Work and in Life

Advertisements
Trackbacks are closed, but you can post a comment.

Comments

  • Nancy  On 2008-03-25 at 00:08

    Hi,

    Excellent article – I really appreciate your knowledge about Why is software development so messed up and I have bookmarked it for later viewing and forwarded it on.

    Cheers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: