Tuesday, September 23, 2008

Idea to Existence

It's easy to get caught up in process, even when process adds more overhead than you could possibly want. At the same time, it's also easy to go around process because it's cumbersome and then watch the system blow up in your face because it's become a mishmash of poorly understood ad hoc changes.

For example, we had this sequence of events occur today:
  1. Someone in dev sends an email to the testing team that says, "Hey! You're logging bugs, but we can't really diagnose them because debugging isn't turned up. Please remember to set the debug level higher when you're testing."
  2. I send an email back that says, "Whoops! We can do that. But I was thinking, if we can't debug it here, how are we going to debug it in the field unless we also turn debug up there?"
  3. A dev sends email back that says, "Good thought. Let's turn the debug level up by default. It only adds about 5-10% additional size to the logs."
  4. A totally different dev chimes in with an email that says, "Well, what if the logs roll? Maybe we should log at debug to one log and log at info to another log so we get duration and detail both."
  5. I send an email that says, "Works for me. We already have a script that interlaces logs from the various systems, so we can just put it together back here if we need to."
  6. A couple of devs pair on the change set and check it in to head.
(I should note that most of this is emails because some of us are in meetings... and maybe not paying full attention! That's a blog post for another day.)

Now, the first thing to say is bad engineers. We didn't follow the process, and this was an enhancement. We should have written a story, let the customer prioritize it, estimated it, and checked it in.

The second thing to say is that we had a cool idea that doesn't change the customer experience (except possibly to make debugging customer issues faster and easier), and we implemented it quickly. This kind of responsiveness and turnaround is a sign of a functional organization.

So what's the right thing here? How do we balance between following a process and getting things done?

There are a series of questions I ask myself when I'm in these scenarios where process maybe isn't happening:
  • Am I following the process?
  • Am I following the intent of the process?
  • Why am I going around the process?
If the answer to the first question is that I'm following the process, well, there's nothing more to be said. Hooray for the change!

If the answer to the first question is that I'm not following the process, I have to ask myself whether I'm following the intent of the process. That is, we've (hopefully) designed a process that is intended to get good software into the field as quickly as possible. If I have to violate the process to follow the intent of the process, well, something's not right. Either the process is broken - usually too much overhead - or my understanding is way off.

If the answer to the first two questions is no, then the answer to the third question becomes important. Sometimes we violate process because of a true customer emergency. Patches often fall into this category, and that's valid. (Our process should accommodate those scenarios, but that's also a separate blog post.) Other times we violate process because we just don't want to follow it; we don't want to go through the bother of making the story, etc. If that's the case, well, shame on us. We need to make the process less burdensome or revise our expectations.

How do you handle the transition from idea to existence when process maybe isn't your first instinct?

No comments:

Post a Comment