Time Box

I'm sure one day I'll move away from being a developer and move into being more of a process consultant of some sort. In every job I've worked at I always try to find better way to get work done. It has resulted in numerous conflicts with management, and it has also resulted in some great successes. At my job with Matt, I was lucky enough to experience Agile. For those not familiar with the concept, I suggest you get familiar with it - it's the best way I've found for a developer to feel good about his job.

My most recent success in applying a process is in the selection of this blog space. Matt had invited me to blog with him on developer related topics. I had been wanting to blog on a place that was separate from my personal blog about that very same thing. The choice was easy for me, I said "Yes" before I could finish reading his email. He had a day off and had planned to sign us up for a blog on that day. The criteria was pretty straight forward:

1. Must be able to accommodate multiple authors
2. Must be able to paste in code snippets
3. Should be easy to use
4. Should be part of a development community

He looked all day (or at least that's what I imagine), wading through all kinds of blogs. Some were explicitly for devs, but didn't really allow multiple authors on a single blogs since it was like one giant blog with a ton of authors. Others weren't so easy to use and paste formatted text into. The options were overwhelming. So much so, that anyone would be paralyzed by the choice.

Fortunately, there's a mechanism for dealing with such situations, one which is regularly employed by Agile, and more specifically, Scrum. It is called "time boxing". No, this is not seeing how fast you can get through the old school NES game of Mike Tyson's Punch-Out. This is about setting a reasonable time limit to make a decision. The idea is that a certain amount of research is appropriate, but at some point, you just have to pick. Spending four hours and making an OK decision is way better than never starting at all. We want to deliver. And that's just what Matt did, he put a time box on it and he had picked a blog for us to use within a few hours.

The Application: Time boxing is good for forcing decisions that otherwise might drag out unneededly. Let's say every month you have a meeting with management to discuss what to do next. This meeting is aways scheduled to be one hour, but it ends up becoming four hours when everyone chimes in, gets derailed, or just tired. If you enforce the time box of one hour, people will decide what they can in quick fashion. They will table the things that need more investigation (which should also have a time box on them), and everyone can move on. To enforce a time box on yourself, just set a timer. To enforce it on others, you can approach it one of two ways: 1) When the time box has elapsed, simply get up and leave. The first few times, they'll "finish up" without you. But if you're consistent, they'll clue in, especially if you can get more people to leave the meeting with you ("I have to get lunch, pizza anyone?"). Or there's option 2) do it the CEO way, "I've got a meeting at 10:45, so we need to be done by 10:30." This lets people know that the meeting is time boxed and there's nothing you can do about it. The blame is off your shoulders, but people still feel motivated to finish. The trick is, you still have to leave at 10:30 like you said you would. If you box it for 10:30, and stick around till 11, you're not doing anyone any favors.

The pros: Stuff gets decided. You can get started. You don't get stuck in meetings that take half a day and make you want to curl into an anti-social ball when you get home.

The cons: Yes, you run a good chance of not finding THE BEST SOLUTION EVER. But you have to weight finding something that's 90% as good against getting a decision made. If you're coming up with solutions that only meet 50% of your expectations, maybe a longer time box is in order. Maybe you need to reassess the goals.

Remember: This isn't work specific. Any time you get stuck when trying to make a decision, just slap a time box on it.

About Matt

I worked with Matt for about 18 months at Passageways, starting in 2007. I was immediately intimidated. I had worked on web projects before, I had even developed for portals before, but I had also just taken a year off from software to be a fencing coach. I was rusty, and here's a guy who was in my same class at Purdue, and he's teaching me things about software engineering so fast that I feel like I'm drinking from a fire hose.

Having been through a number of jobs in and after college I thought I knew what I was doing. I knew how to use inheritance to cut down on code duplication, I could tie into a database with the best of them, I was at the top of my game, especially for my age - or so I thought. I learned the ropes of the product from my team mate, Dustin. After our project was finished I had a lot of overlap with Matt. I'd check in my code, he'd inevitably have to add something to the same class, and so I got my code reviewed all the time those first few weeks. Things that I knew about, but was lazy about mostly - using the finally statement to dispose of my IDisposable objects, using StringBuilder when I was appending several strings, and so on. And there was polymorphism opportunities that never occurred to me.

I learned to love the white board as Matt had. It's a great medium for team-oriented design, so everyone can see what's being developed and respond to it, instead just assuming the note taker got it all. We both liked it because the design wasn't the responsibility of just one person. Anyone with a good idea on the team for the task at hand could make it better. Instead of an architect, we had a team, who pulled on the various experiences each one had.

At the company, Matt was a Development Lead, a role that wasn't very well defined as to what it was. it wasn't a management of people position. It wasn't heavy in product vision based on customer input. It was often times, providing a product vision based on technology - helping to meet the needs of both customers (as defined by the product owner) and the needs of the developers, leveraging the technology available to us. Often times his biggest obstacle was getting the new technologies set up for all 150+ customers.

After the initial growth, and tightening of my code style, Matt and I struck a good balance. We both had areas we liked to focus on, and for the most part, they didn't interfere with the other's aspirations. When we did cross over, we'd get frustrated just like any other relationship, but we had a strong enough social and professional foundation to always talk it out. Now that I'm 2,000 miles away from Matt, I expect this blog to be an extension of that same dynamic. He has his focus, I have mine, and we'll step over and disagree occasionally, but I expect that's the time when we (both Matt and I, as well as you, the reader) will grow the most.