Archive for June 2009

The 3 kinds of code

You can look at any chunk of code as belonging to one of three categories. Confusion between them plus a misunderstanding about the relative cost lead many people into trouble. With a little communication and some discipline, you can save yourself a lot of pain.

The 3 kinds

A few weeks back, I had to help smooth over a conflict between two co-workers. One was a seasoned developer. The other was a businessperson who just wanted some things added to their company’s web site. The conflict arose because they had very different ideas of the costs of software.

For their purposes, there were three plausible paths to take, matching the three kinds of code:

  • Temporary – Code written with a plan to throw away in a day, a week, or maybe a month. If it breaks, that’s ok — we were going to get rid of it anyhow.
  • Sustainable – Code that’s built to last. Well factored, well understood by the team, with strong automated tests, and generally meeting the team’s standards for something they’d happily maintain forever.
  • Half-assed – Everything in the middle. Code written by amateurs. Quick fixes that become permanent. Rush jobs. Things written when people say “we’ll clean it up later” and don’t.

When the businessperson expressed their desires, they wanted something cheap and quick. However, they didn’t want it to be fragile or throwaway; it had to be reliable and last indefinitely. They proposed bolting on an off-the-shelf solution that fell in the “half-assed” category. When the developer reacted poorly, they couldn’t understand why.

Follow the money

The misunderstanding comes because they had different perceptions of the costs:

businessperson
view
developer
view
Temporary low low
Sustainable high medium
Half-assed medium high

Given their perceptions, it’s natural that the businessperson would prefer the half-assed option. It’s more valuable to them than the temporary option. But doing things sustainably doesn’t get them any apparent increase in value, and they think it costs them more. Just as naturally, the developer resists what they see as the high-cost option.

In truth, they’re both right. They’re just looking at different sorts of costs. We can rewrite the column headers this way:

short-term
costs
long-term
costs
Temporary low low
Sustainable high medium
Half-assed medium high

The experienced developer is more aware of the long-term costs not only because they have more experience, but because long-term costs are generally thought of as their problem. As the maintenance costs of half-assed code add up, they won’t be attributed to last year’s excess schedule pressure from business stakeholders. Instead, the developers will be perceived as increasingly unproductive or unreliable.

Of course, that’s not just bad for the developers. It’s bad for the company as a whole. If a company’s costs for software continuously increase, that eventually becomes a powerful advantage for competitors who are more thoughtful and disciplined about their approach to software development.

Don’t fall in the trap

This is why many parts of the Agile world either explicitly or implicitly rule out the option of writing half-assed code.

Extreme Programming, for example, started out with a number of sustainability-focused practices, including pair programming, test-driven development, and merciless refactoring. As the book Planning Extreme Programming says, “With most of our planning, we assume that quality [is] fixed.” This continues up to the present day with efforts like Bob Martin’s Manifesto for Software Craftsmanship.

No matter what process you use, you can avoid the trap of half-assed code:

  1. Make sure everybody agrees that they are in it for the long haul.
  2. Educate stakeholders on how expensive supposedly cheap solutions are in the long term.
  3. Whenever people agree on a temporary solution, make sure that it is really temporary. In particular:
    • Agree in advance on the end date and expected issues. Write that down.
    • Budget for the costs of removing the temporary solution.
    • If a permanent solution is to follow the temporary solution, budget for that, too.
    • When the end date approaches, people will try to fudge it. Politely refuse, reminding everyone of the earlier agreement.

In addition, be constantly vigilant about half-assed code returning in disguise. For example, a lot of people get sold on outsourcing or offshoring because it looks cheap and easy. Sometimes it might be, but most of the projects like that I’ve seen are really half-assed code that got sold as sustainable. Just as dangerous is the cowboy coder who rides in to save the day, but leaves a lot of half-assed code behind for other people to deal with.

Mindful engineering

I’ve been pondering lately what was special about the teams I’ve been on that have felt the most effective to me. It wasn’t just a certain set of practices, though those were helpful. The essence, I think, was a certain openness to ourselves and to each other, a willingness to really look at what we’re doing and how what we’re doing affects the project, ourselves, and each other.

Retrospectives are a specific practice that provides regular opportunities for this kind of openness. But even more, when I’ve really felt productive there’s been a pervading attitude on the team that it’s always okay to take a moment to explore some interaction or event at a deeper, more personal level.

One day, on a team of four, we were programming in two pairs. At some point my partner and I noticed that the other pair had reduced to a solo. We asked, “Where’s your partner?” and he replied, “I think he got upset with me.” My partner replied, “Well, I hope we can talk about that later.” And the really amazing thing is: We did. The partner returned, and described what he had gotten frustrated about, and we were all able to talk constructively about how to deal with that kind of frustration.

Another day, on another team, also while pairing, I noticed my partner withdraw and get quiet. I wasn’t quite sure why, though I was aware that we had been debating some technical point. She started to go on with the task, but I stopped to ask what was up, and she said, “I’m just not getting much ‘Yes, and…’ from you right now.” We had both learned the “Yes, and…” principle from improv classes—which I highly recommend—and it was an easy way to remind ourselves to respect and build upon each others’ ideas rather than only pursuing our own. This quick check-in in the middle of a task short-cut what could have been a long period of frustration, leading instead to a productive, collaborative session.

As I said, this isn’t about specific practices as much as it is about a thorough willingness to talk to each other openly and to respect each others’ thoughts and feelings. Obviously, I think that Agile practices, especially retrospectives and pair programming (when done well), are a good way to foster this kind of openness. In fact, what first drew me into the Extreme Programming community was the openness to learning that it demonstrated.

In my short career up to that point, I felt that I wasn’t really learning much—I was already a pretty good programmer, but the really tricky problems on my projects were less about programming and more about communicating with each other and with the project’s stakeholders and about finding ways to keep everyone sane in the face of growing complexity and business uncertainty. These were the real challenges, but no one was really addressing them—until I found the XP community, who were meeting every month to talk about exactly these issues, and about what they were trying and what they were learning about them.

Now, of course, this kind of concern for how we work together is not the exclusive domain of Agile communities, though some of us often talk that way. The CMM community is likewise dedicated to trying new things and talking candidly about how they’re working, albeit with a more formal approach. The Space Shuttle software project case study described in the CMM book is actually quite an inspiring story of worker empowerment and process experimentation and improvement over time.

Why do many in the Agile community criticize the CMM, lumping it together with the straw man process known as “Waterfall”? I think that Waterfall is an example of formality in a process without authentic openness and introspection. When a manager looks at an undisciplined project and sees it spinning out of control, the most common reaction is to impose some control with some mandated formality. The CMM may be used as a framework for that formality, even though the authors of the CMM themselves strongly warn against using it to impose formality without honest assessment and openness to continuous improvement attached. (They even have nice things to say about XP.)

I’ve been exploring the practice of mindfulness lately, and I think it nicely captures the kind of openness and introspection I’m talking about here. Mindfulness can be practiced through activities such as meditation, improvisation, journaling, and reflective listening, and has documented benefits for compassion, empathy, concentration, and even happiness itself.

I can easily see the appropriate level of formality varying based on the nature of the project, but this quality of mindfulness seems essential to any endeavor. Agile methods tend to be moderate to low on the formality scale, and—when they work—high on the mindfulness scale.

How are you mindful of your work? How are you not?

Clicky Web Analytics