Amazon.com Widgets Tweet Expansion: Butt Time and Brain Time

Tweet Expansion: Butt Time and Brain Time

By Nick at April 29, 2012 17:53
Filed Under: Delphi, Leadership, Software Development, Tweet Expansion

A while back I tweeted the following:

In software development, we often measure Butt Time, when what we need from developers is Brain Time -- which is much harder to measure.

Some tweets call for further explanation and expansion, and so I’ve added a new category called Tweet Expansion to cover posts that do just that.

Here at Gateway Ticketing, we have an interesting development and business model.  At our core, we are an ISV.  We sell a software package that we build to customers.  But, we also will customize our software to meet customer specifications.  That makes us sort of a VAR to our own product.  Thus, we do both enhancements based on customer requests and our own internal product development projects to make our product more valuable in the marketplace. 

This distinction – between internal projects and projects driven by specific customer requirements – makes for some challenging project management.  But we have a solid team here at Gateway, and we make it all work.  But because we do work that amounts to us being consultants, we end up having to closely track our developer time.  We do that for a number of business reasons, the main one, of course, is profitability.  You need to track your time to ensure that you are actually making money on a given endeavor.

Now I know that no one really likes to track their time.  It’s a pain.  It’s challenging to be accurate.  It’s hard to get time properly categorized.  But it is also invaluable for making those important business decisions. 

But there is a bigger problem with measuring time.  The only thing you can really measure is “Butt Time”.  Butt Time is the actual amount of time someone has their butt in a chair while working on an issue.  You need Butt Time to get any work done, of course.

But Butt Time isn’t really what you want from your developers.  Butt Time isn’t at all equivalent to productive development time.  Butt Time includes reading email, answering questions and generally handling any number of interruptions, meetings, and other distractions.  And those distractions, however minor, break a developer’s concentration.

And when you get right down to it, development is all about concentration.  With a coding project of any size at all, doing development requires your complete focus and concentration.  You need to build up complex data structures and patterns in your mind in order to really be productive.  Doing so takes time --  I’ve heard it described as building a house of cards in your mind.  Building that house of cards can take upwards of fifteen minutes depending upon the project.  But here’s the bummer:  It only takes a second for that house of cards to come tumbling down.  One distraction can make your fifteen minute investment disappear. 

And of course, time spent in “The Zone” – with that house of cards constructed and true, highly productive work getting done – is what we all are seeking.  We’ve all probably had that awesome experience of getting into that zone for hours at a time and wondering where the time went.  We know how cool that is – and how precious.  That’s what we want to measure – Brain Time.

But that’s a really hard thing to do.  Getting accurate, meaningful Butt Time measurements is difficult enough.  But how in the world can you actually measure Brain Time?

I’ll argue that you really can’t.  In the end, Butt Time is only a poor proxy for Brain Time.  What we need to do is to try to increase the Butt Time to Brain Time ratio by providing an environment where Brain Time is maximized as a percentage of total Butt Time.

There are ways to do that – ensuring that your developers have an office with a door that they can close is an important first step.  The book Peopleware is really the Bible for this, and Joel Spolsky has talked a lot about it as well.  Uninterrupted quite time is the key.  Leaving developers alone is the key to maximizing Brain Time.

Seriously – you need to get and read Peopleware if you have anything at all to do with leading developers.  This is the definitive book on managing software developers.  Be sure to get the Second Edition.  The physical book is, I believe, out of print, causing the price to be pretty high,  but I was delighted to notice that you can now order it on the Kindle

Another thing we need to do is to respect – indeed, celebrate – those developers that are quiet and don’t say much.  We have a not small number of developers here at Gateway that, well, don’t say much at all.  They come to work, write great code, and go home.  They don’t have a lot to say.  But sadly, we don’t always respect this.  I’m as guilty of anyone of too often saying super-clever things like “Stop being so boisterous, Meredith” or “Did you say six words today?”, instead of recognizing that Meredith is maximizing her Brain Time and, by being quiet, not breaking other team members’ concentration.  Being quiet is a very valuable virtue in a software developer – both because they themselves are being productive and they aren’t breaking other’s concentration -- and we should give honor and respect to that.

Butt Time is easy to come by and fairly easy to measure.  Brain Time, however, is a precious and hard to measure commodity that needs to be nurtured and respected.

Comments (4) -

4/29/2012 11:42:40 PM #

Moz

I had a really good response to this but the receptionist next to me started talking about her kids again and I forgot what it was[1].

Some companies get this, some don't. I'm a bit over the Australian thing of treating programmers as a kind of support staff. We're put in an accessible area where we're able to see and hear everything that goes on and anyone who wants us can see whether we're busy. "Just typing" is not busy. In reality programmers are more like mushrooms - we like to be in a cool, dimly lit place with a good supply of food and water.

I've worked in a couple of open place offices that worked better than most, I think largely because the office area was quiet and I got to face the wall. Add headphones and a reputation for asking "what have you done to solve your problem" and I got quite a lot done. But private/two person offices do make a huge difference. Even glass wall ones, if I don't have movement in my line of sight.

Most productive times are still when I wake up early with a clear idea of how I want to solve a problem, log in from home, and code until the design is obvious from what's there. A big pile of failing unit tests is a good result of this Smile

[1] I wish I was exaggerating for effect, but I'm not.

Moz Macao S.A.R. |

4/30/2012 10:17:59 AM #

nick

Well made comments, Moz - thanks.

nick United States |

5/2/2012 10:09:02 AM #

Anders Isaksson

I made a little app running in the task bar where I log my time, just one right click and one click on what I'm doing. There's also an Interrupt/Pause button. As everything is logged I have the possibility to see *how many* interruptions there have been. My habit of clicking on the 'taxameter' when people come in and ask something is irritating them, but the log is a good argument in discussions over worked time vs. results.

Anders Isaksson Sweden |

5/2/2012 12:14:34 PM #

nick

Good idea.

nick United States |

Comments are closed

My Book

A Pithy Quote for You

"If you don't buy the tool you need, you will eventually pay for it, but not have your tool."    –  Henry Ford

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.

Month List