Rules for nothing

One blog entry from last year, “Look. This SOPA/PIPA Thing,” started out as an offhand blurb on my Facebook status. I think I spent two whole minutes writing it, which can be pretty effective when you know exactly what you want to say:

Rather than doing their own damn work chasing down copyright violators, they want to keep everyone off sites that *might* be used for unauthorized copying.

My favorite comment came from my old Grinnell College homie, Laura Allender Ferguson, who said simply: “Go Agile.” She was responding to my side-whine about the ever-changing requirements that we always get from software development clients.

If you’ve worked with me or been reading my stuff for any length of time, you get Laura’s point even though it appears to be way off the topic of intellectual property law. But it’s not. The fundamental idea of Agile development is that reality simply is. You won’t get anywhere by assuming waterfall-style requirements are actually going to be complete; they’re not. You won’t succeed by demanding that developers understand all of a project before commencing work on any of it; that’s simply not practical. You will regret the ritualistic pre-assigning of development tasks to each team member at the beginning of a project; time after time, reality indicates that your detailed advance plans will just get in the way.

Most methodologies, or even taken more broadly most conceptual ways of looking at how projects get done, are simply very heavy-handed. If developers feel stressed by artificial deadlines, conventional approaches say try harder! If the client isn’t sure what she wants in advance, conventional approaches say pin down the requirements anyway and depend on the high cost of change orders to protect you. Any problem is solved by some application or another of control.

What’s wrong with SOPA and PIPA legislation

You’re a record company, a movie studio, a cable news network. You’re concerned about the likelihood that people are making unauthorized copies of your copyrighted content and pushing them around the Internet. So, because you have money and influence, you call your pals on Capitol Hill to give you more power and control over how people use the Internet.

But that sucks for everyone. It makes even non-infringing use of the Internet more difficult, imposes a huge enforcement cost on DNS servers and gateway routers, and gives everyone a “locked down” feeling. That’s because it’s a brute-force solution to a problem that hardly anybody is actually suffering from.

Dude, That’s Not Agile!

Similarly, when you impose lock-step order on the day-to-day details of your software development project, especially when you assign interdependent tasks with individual deadlines, you’re actually making it harder for people to do good work. They’re afraid to do even the most compelling refactorings, because those take nonzero time that doesn’t count towards the task deadline. They’re less likely to help each other, and especially the higher-skilled developers will hesitate to spend time with someone who might be working more slowly. They will do the most expedient thing in the moment rather than the best thing.

That’s not because they want to do shoddy, selfish, incomplete work. It’s because your regime demands it. It’s because you can’t dictate reality.

Here are some bites of reality:

• Most people want to like their jobs.
• Most people prefer to do the best work possible…
• …but not at the cost of being held responsible for getting less done.
• Most people want credit for their best work.
• Most people want to help their coworkers…
• …as long as they don’t get called out for being off task.
• Developers really can’t know how long something will take to do until they do it. (Proof: The Halting Problem.)
• If you’re not able to write the code yourself, you’re unlikely to be qualified to override a developer’s estimate. (Ditto.)

Everyone knows these things, except for probably the last two, but we keep seeing development shops that act as though the exact opposite is the truth. Why do we have standards that assume people are trying to get away with doing less work, crappy work, and that they prefer to be selfish about it? Like the SOPA/PIPA legislation, these work rules are brute-force solutions to a problem that doesn’t really exist.

Rules for nothing

So look at your own development team environment. Ask questions like this:

• Does the version control system let you do paired checkins? Why not?
• Who sets the deadlines for things, and how are those deadlines calculated?
• On a day-to-day basis, how do you personally decide which small task to pick up next? Is this even up to you?
• What is your shop’s estimation process? In what ways is it superior to making no estimates at all? (That’s a harder question than it should be.)
• Who defers to whom? Does that inequality contribute to quality?
• Do your rules and processes make it more or less likely that developers will:
  • Cooperate on code design?
  • Program in pairs when that is effective?
  • Refactor appropriately?
  • Mentor and teach each other?
  • Notice when a project is going badly?
  • Do good work rather than raw work?
  • Understand requirements?
• What kind of destructive behavior gets rewarded? How and why?
• What kind of constructive behavior gets punished? How and why?

You might find that your culture, rules, tools, and practices don’t actually contribute to the job of producing great software and high business value. Maybe some of them are just cultural habits, or artifacts of self-preservation. They’re “rules for nothing,” which produce poor outcomes in reality. The Agile idea is to adapt the rules to reality rather than vice versa.