“70% Rowing Backward: Why is software development so messed up?”
“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: