One week in

Maybe I’m crazy. I sat in a meeting today where I found out a couple companies will be consulting for HealthTronics. In the end, that’s exactly what I want to do.

But, I walked away from a position where I was the HR/Skills lead for the Policy department in North America, and had a title very similar to that of the person giving the seminar today. He is over a few more people than I was, but our responsibilities are similar. I could have been better, that’s always the case, but I was very good at my job. I’m passionate about software craftsmanship and people development, and that helped me to be a very effective leader.

I’m sure there are plenty of stories out there about a person working in a similar situation as what I had, where they began consulting and doing speeches here and there, building the demand, until they finally had to leave.

While I’ve done that somewhat, I maybe cashed out before I hit my peak demand But, to make it, you have to take risks, and this puts me where I need to be.

The big difference I see between these companies that will be consulting and myself is that I have built my brand as Damon, I haven’t yet built the brand of Penguin Creek. think that’s key, and that is what people expect when they hire me. But at some point, I have to find more people that are passionate about the same things that I am. Otherwise it becomes an intricate facade (read: lie) and I’m just not OK with that.

On my own, I have the ability to pursue lectures, consulting opportunities, and so on. At Accenture, I had those opportunities as well, but to me, for some reason if I were profiting on it outside of Accenture, that would feel wrong. And to me, profiting doesn’t necessarily mean making money, as there is the sweat equity of building a brand.

Maybe I’m the only one who views it that way. Regardless, I now have the freedom and opportunity to follow my folly, and the future is looking great.

A New Venture

In just one week, I will be leaving Accenture Duck Creek to venture back out on my own. It is something I have wanted to do for a long time, and I was provided with an opportunity that greatly reduces the risk.

I can’t say the decision was easy. No-brainer, quite possibly. But, I’m walking away from an awesome company and culture, one that has been responsible for a lot of my growth across the past three years, and that I feel I have helped grow into an even better place to work.

The people are awesome, we have a good niche market, there is plenty of collaboration and debate, and people pride themselves on teamwork, their craft, and delivering value to the company. In addition, it plays nicely to my strengths. I am a developer by trade but am charismatic and have always loved to lead, and that combination has made me an effective leader. It is hands down the best place I have ever worked, and in exiting, I feel like I’m losing a piece of myself.

But, the time is right for me to make a move. The market is showing signs of an upward trend, and I am at the point where I have plateaued a bit and need a new outlook and skills refresher, so I was going to have to change my role anyway.

This opportunity is an exciting one for me. I’ll be contracting for a software company that was recently purchased (first buyer) and is relatively early on in the Continuous Integration life cycle. It will be an opportunity not only to get the skills refresher I am looking for, but it should provide the opportunity to continue to brand myself at the things I love, Software Craftsmanship and continuous improvement.

Wish me luck!

Short article on Focus

Heath recently shared this article with me related to focus. It does an excellent job of stating a few things I have mentioned in the past, but with much fewer words.

One item NOT mentioned in here is a tip I recently read about how to effectively “surf,” and it’s ironic because there are links in this article that want to steal your attention.

The theory is simple.

When you are in the reading / researching mode,

  • click on all the links you want to read,
  • but make them load in the background.
  • Then, start reading them one at a time until all of your tabs are closed.

A Kickoff for Focus

There have been a few efforts and discussions here and there around the office to improve our ability to focus.

We have spoken to tuned-in time, going underground, and focus. I think we can all agree that improvements in this area would be nice. But we may not ever stop to think about more than the immediate why.

A new push

Going forward, our department is going to take a hard look at this and we are committing to it as an initiative. Big shock, I’m a bit passionate about this topic so I will be heavily involved. Included in that, I intend to somewhat formalize the process I have used in the past when it comes to analyzing what I’ve termed “productivity sneaks” for looking at these, as well as drive towards establishing a clear goal of what we hope to achieve.

I will be ever more mindful of the long-term effects of these efforts. While improving our focus, we still have to maintain our ability to change and increase our ability to innovate. To me, that means questioning everything we have come to accept (and thus, not think about) as part of our daily routines.

What is the goal?

To some, the discussion of focus and tuned-in time may make it seem like it’s all about squeezing even more efficiency out of an already busy schedule so we can pile on even more tasks. To others, it’s recognized as an effort to provide people the time, space, and environment they need in order to work on long-running or thought-intensive tasks.

I can assure you that my intentions have always been the latter. I realize though that often times I am led to look for productivity sneaks because of the former, trying to get more stuff done in the same amount of time. As we explore this topic more, I will remain mindful of my tendency, and will focus on finding (and resolving) the problems, not the symptoms.

I think the best way to sum up what I hope to achieve is that we can answer this question and implement any necessary changes:

What steps do we need to take to enable ourselves to be more successful?

I believe that this will end up being a great step forward in our pursuit of engineering breakthrough experiences.

Going forward

Do you want to get involved? There will be no committee; there will be no regularly occurring or repeating meetings. I might explain the details in a future post, but the “why” is obvious: Focus.

To get involved, start by becoming mindful of the items that impact your focus, and help brainstorm about what we can do about it (and why we should).

I expect that the hardest part for you will be committing to actually implementing the ideas we come up with and turning them into habits, and looking forward far enough to see whether this will actually help.

I can promise you I’m committed to improving this and will be giving it regular, well umm, focus.

NCrunch: On the Fly Testing in Parallel

A Visual Studio plug-in that runs tests in parallel and asynchronously as you change code.

The Build-Up

A few weeks back before I was about to deliver the Unit Testing Workshops to some of our new developers, Sam Warren stopped by and asked if I had heard about NCrunch. I hadn’t! :–) And, this was about 10 minutes before I was set to start, so off I went.

What is NCrunch?

Basically, although I’m sure the author could do it more justice, it’s a Visual Studio plug-in that evaluates your tests in parallel as you write code. It works with the standard MSTest, as well as NUnit, XUnit and a few others.

Think of that: on the fly test evaluation. Assuming you already have written tests to cover what you are working on (or that they already exist) you can see whether your code changes pass without having to press the chord ctrl+R,A to run all of your tests and wait for it to complete.

18 tests in progress while coding:

image: Tests in progress indicator

In addition, the tests can run asynchronously, and you can configure it to ignore specific tests, as well as a few other things.

It’s currently in Beta, so the author wants you to download it, try it out, and provide feedback. You should download it, try it out, and provide feedback. :-D

So why are you just now writing about it???

Good question, I’m glad I asked that for you. ;–) This week, I took a break from the office to work from home and get caught up on a couple things, one of which was a coding effort using PostSharp for Aspect Oriented Programming (AOP). The beauty of AOP is that you just put it in place and then you don’t really have to think about it until another six months go by and you need to add it to a new solution.

And that’s where I’m at, so I checked in my manager whip and checked out my developer card and headed to the home office to sling some code. In the process of doing this, some of the real power and beauty of NCrunch became quickly apparent. There’s your answer.

Really, why NCrunch?

The scenario doesn’t matter much, however you will find the most value in this tool will come from the Test Driven or Test First disciplines, as the whole idea is that you must have a test to pass or fail in order to know what impact your code will have.

What I had seen up to this point is that it provides nice coverage indicators, as well as a bit more friendly approach to seeing the error. Have you ever double-clicked on a test error in the Test Results window of Visual Studio? It takes you to a page that tells you it failed, not the actual failing test; that takes an additional click.

A failing test:

image: failing test

The context menu for the failing test:

image: context menu of failing test

The failing test count:

image: fail count

All tests good:

image: pass indicator

The visual indicators will actually show you what line in the test is failing, plus what the error or failure is, as well as indicators on the covered (and non-covered) code. Throw a Thread.Sleep(500); somewhere in your code, and you’ll see this line indicated in yellow (on my box) to display a slow-running process!

A slow-running test or unit:

image: slow code

The ability to run the tests in parallel with development is pretty big, as this prevents you from having to stop developing and run all of your tests just to see the outcome.

Because it runs your tests concurrently!!!

But one of the coolest features and why I cannot see ever writing another line of code without this tool is that it will run your tests concurrently, and this is HUGE!!! as it will help you identify processes that are not thread-safe.

The value of this became apparent when writing the Aspects. I was trying to add tracing to an overall solution where I only had a portion of the code and did not have access to the entry point. This prevented me from being able to initialize a new TraceListener in the beginning, and meant I had to do a bit of a kluge.

I knew this, and I was ultra-paranoid and wrote all of my tests. Testing around AOP isn’t the easiest thing in the world, but, I managed to do it and all my tests passed. I shipped the code, and FAIL. Why? Maybe because my developer card was dusty, but really it came down to me not fully knowing the state of the Aspects.

So back to the drawing board, I read up a bit and became familiar with what was fired off at compile time versus what was fired at runtime, and I went back to clean up the code. This time however, I had NCrunch in place.

Tests that passed the standard, synchronous approach of MSTest now caused 8 failures under NCrunch, because all of them were trying to access the same resource (which was not thread-safe) at the same time.

Having this in place was huge, because it allowed me to clean up my code and see the impact of the tests immediately. Keep in mind I’m a keyboard junky, so I have no problem firing off ctrl+R,A and yet this tool cut out so much waiting time.

My Configuration

Each time you add NCrunch to a new project, it will walk you through a wizard. Unless you have an overly-clunky solution, I suggest the following options:

  1. Parallel Test Execution: Change this to “Yes – run my tests along side each other!”
    This allows NCrunch to run tests asynchronously, and unless you have a clunky solution, ignore the performance warning and enable this. Actually, ignore it either way, and just buy more RAM or clean up your solution. This is the bit that may help you track down threading issues, you want this enabled.

  2. Engine Execution Mode: “Run my tests automatically when changes are detected”
    It’s not entirely silly to install NCrunch and not enable this option, but it’s pretty close. Choosing something else will require you to tell it when to run the tests every time. With this enabled, you can still do that, so the only reason you would to choose something other than this is if you’re working on painfully slow code and tests, and if that’s the case you have other issues.

  3. Ignored Tests: Change this to “Let My Tests Run – I will ignore them as I need to”
    This will possibly require you to go back and tell it specific tests to ignore later, but this option gets the most value. I have encountered three so far that depend on deployed resources at build time that NCrunch didn’t support. Also, the tests are extremely easy to ignore when you find you need to do that.

After the wizard completes, I suggest changing the colors, as for me it was tough to tell the difference between the covered and non-covered tests.

I use the default circles, but set the colors to:

  • Green for successful
  • Yellow for slow-running
  • Red for failures
  • Gray for non-covered (default is purple, and with the size of the dots it looks a lot like red).

To change these settings, either do it in the initial wizard, or in Visual Studio go to NCrunch: Configuration and click on All Solutions. This will take affect across all of your solutions. It is also shared across Visual Studio 2010 and 2008.

image: config

References

NCrunch – VS Plug-in for parallel test execution

PostSharp – Post-compile Aspect Oriented Programming suite

XUnit – For when MSTest just won’t do.

A Proud Day, Some Big Wins

Taking development to the next level.

Intro

As a manager almost entirely removed from the code, I constantly face an internal struggle to find wins and battle with whether I provide enough value on a daily basis. I know I make an impact and it’s usually good, but that sense of accomplishment that you get after completing some code is long gone.

I often find myself looking in the rear-view mirror and longing for the development past, yet enjoying the journey and company in the car with me and I’m unwilling to let that go.

So, when I get to see some sort of sign that my efforts are paying off, it’s a huge boost.

The Context

I suppose it’s a bit sad that what triggered me to write this is an email I received from a recently former “duck” that decided to change companies. Sad not that it was an email, but that this duck has left the pond.

That’s just the event that pushed it over the edge, there are really three big items that make this a huge day.

Item 1 – Advisory Board Meeting @ SBU

The first, and the one that started the day off, was being asked by my company to sit on the Advisory Board at SBU. This is really a huge honor to me. Some would view this as a chore, and I know that because it was “sold” to me, but for me, this is awesome!

We all know that college programs have their strengths and benefits, yet almost all struggle with connecting the academic world with the workplace. College is about preparing you for the workforce, yet there is a definite disconnect, and the really good programs try their hardest to bridge this.

This is the opportunity to come together with leaders of other organizations and provide feedback as to what we feel is most important; skills that we wish graduates would come to us with.

I cannot begin to explain how excited I am about that! I would guess that the talent coming out of schools are around the same levels as that of the years past, but the difference is the immersion in technology. Those graduating now have grown up with technology. That’s not to say that my generation did not, but technology in those days were Atari’s and TI’s.

Yet, there are still things that I thought, wow, if they knew this, they would be game changers on day 1. And for the impact that will have on our industry and our teams, I am geeked.

Item 2 – A Random Conversation

I was speaking with a coworker this afternoon about development, and they brought up the topic of what they wished they had learned in college. I promise, this was instigated by them and not the events of earlier in the day.

Guess what they mentioned… TESTING!!! They said that they were exposed to it through Test Driven Development but they really didn’t USE it until right before their senior project. I’m paraphrasing, but after describing how they were introduced to TDD, their statement was

> "I don't know why we weren't taught to code this way on day 1."

While this person has not sat in on my workshops, this conversation was confirmation of one of the thoughts from earlier in the day that I had, which was something like:

> I know I'm going to recommend that they begin testing as early as 
possible, ideally their freshman or sophomore year, but what else should
I recommend?

I’ll have a few other suggestions, but this made me think, well, I’m pretty much covered. Speak from the heart about what my passions are and what I look for in developers and that will tell them what they should strive to deliver in their curriculum.

Item 3 – The Kicker

This is the one that did it. Before I checked my email this evening, I had considered writing this post because of items 1 & 2. It will be a new topic no doubt, but I passed over this because of two other things I really wanted to write about:

  • The Need For Offices – Part 2
  • A Retrospective & Efficiency Adjustment

I will be posting the above two by the end of next week, and started the brainstorming around them tonight. Yeah, I usually do that in my head and just being spouting random thoughts, but I did prioritize and actually did it on that old think called paper!

And then, then I trumped that. I opened up the beast to begin writing, and checked my email first to kick it all off. There was a specific email that pushed me over the edge on this and I decided to put the two above on hold.

You’ll see in them when I finally write them (follow me on Google+, LinkedIn, or go old school RSS :-7 ), expect that within the next week.

The email?

> **Subject: "quick question about that unit test class you taught last week"

A lot of that material looked like it may have come from a book. I was
wondering what book that might have been? If it didn't come from a
book, do you have any recommendations for books on unit testing?

Thanks

At this point, I feel like I’m standing behind a podium, holding up a trophy, trying to get in all of my gratitude to those who helped me get here before I hear the exit music.

That taken from a book thing? Nah, that was me, inspired by many things. First, it came from me reviewing some code and thinking “AGAIN?!?!? Another copy / paste / hack implementation of command line parsing???”

Here We Go

So I set off to “fix” it. By fix, I really mean start it on the road of improvement. I took the TDD approach, and in doing so, I realized this would be the perfect topic for TDD. I remember my early exposures to it and the problems I encountered:

  • Where do I start?
  • How do I start?
  • A general aversion because I’m going to suck at this…

And I recalled an example I had run across around learning TDD that was based on writing a spreadsheet application. What a daunting task for starting to learn TDD. It’s great for the ones who looked for this challenge, wanting to go into it head first. But for those that need a bit of a warm up, that sucked.

Command line parsing offered a topic that we all know, and most of us have written parsers WAY too many times throughout our career, so it removes the unknown requirements and where to start bit. It also tugs at my soul, because you know how much I hate the mouse.

So, I wrote the program. Then, afterward, I documented it in as close to presentation form as I could get, and of course, I went from memory. I presented this for the first time last year, and it was rough. Luckily, the first session was a pretty advanced group of developers that were able to help identify and navigate the steps that I forgot to call out.

I also learned that I really suck at writing requirements! There are so many things that I assume that I really shouldn’t. In that first session, Danny was able to make it through the first session with three lines of “actual” code. :-D He kept saying I know this is going to come back to bite me, but you said write as little code as possible. :-D

The Finale

Since then, I think I have given this presentation internally about 10 more times. I have records of who has attended, but the only “record” I kept about how many times I presented are the folders source/tdd\d that I happen to see on disk.

I’ve tweaked and improved based on feedback each time, some retrospect on my part, some tricks I’ve picked up, some advice from a professional trainer / former teacher, etc.

I’m proud of the sessions and presentations, they have turned out really well. On my last trip to South Carolina, I went back to the storyboard and polished it a bit more. My next area to improve on is to ensure I’m providing the necessary content while being terse. Imagine that. gedit tells me I’m on Line 99, and that’s hard wrap, not soft.

References & Thanks

It’s my Grammy speech, but it feels appropriate.

I can’t possibly thank all of the people who helped today happen, because inevitably I will forget more than 90%. So, I’m going to list a few that really stick out in my head, in somewhat slightly chronological order:

  • Tom Pepe, for turning me on to Misko’s blog a while ago, and then engaging in some of my “Yeah, but…” debates.
  • Misko Hevery for writing the blogs.
  • Michael Dwyer for supporting and encouraging me to lead this for our company.
  • Numerous other writings and discussions around testing, both for and against.
  • The stubborn, skeptical people (just like me), challenging me to recreate my experiences for you.
  • All of the attendees and the feedback you have provided.
  • Patty Hunt. Thanks for the tips ;–)
  • My ‘rents, for constantly challenging me and instilling the yearning for continuous growth and improvement.
  • The three people referred to in the items above.

Hiring a Pair of Programmers - Crazy?

The Idea

I had a thought earlier today. It was definitely not well formed, however I bounced it off some people I respect to get their opinions.

The thought was while we are seeking candidates, why do we not post something like:

“Are you a dynamic pair of developers? We want you.”

C-Level executives and Sr. Managers usually try to take teams with them as they go to other companies. Why? Because they know they gel, they know they succeed.

So why, when teamwork is so imperative in a development environment, do we not solicit this?

The Initial Responses

The responses ranged from, yep, you’re nuts and this is a horrible idea (3-4 people) to crazy, risky, but interesting (3 people). As an aside, that’s how you know you’re working with good people, they’ll tell you you’re off your rocker.

The response I heard from several is that this is not really different than what we do now. We hire Developer A who proves themselves and then eventually recommends Developer B. So, why change?

The comments about risk included items such as:

  • One’s a rock star, but we don’t want the other. What do you do?
  • What if they come with a strong personality and do not fit in with our culture?
  • What if the pair cannot function? We have wasted money training them both.

There seems to be a fear and a belief that this opens us up for more risk. I couldn’t disagree more.

One interesting response was that you bring in new management to make a change, and that is why they bring their own team. I see this, but I think there is a lot more to it than that.

My Retort

Reality Check

Come on, I’m talking about rock-star pairs. These people stick together because they know they are water and fire and they balance each other out. One is not going to feel sorry for the other and make a recommendation and go into an interview knowing that. No, they will take someone with them that they know perfectly compliments their style and guarantees their success, and their counterpart feels the same.

We then just have to weed our way through those that think they’re rock stars, and those that are. We’ll say yes to both, or no to both.

A Scenario Based on Real Life

Picture this scenario. I would bet that you, or someone you know, has been in this situation at least once.

Developer A and Developer B gel. Their current employer may or may not recognize this or support it, but A & B do. You put them on a team, great things happen. You would be foolish to break this up.

Then one day, for whatever reason, one of them decides they want to seek employment elsewhere. Do you think this happens without both of them being aware of it? I guarantee it does not. I have personally been in this situation at least twice.

What happens is Dev A says to Dev B, I’m thinking about leaving. Recommendations of places to work fly, and they settle on something along the lines of Dev B saying “You get on at Duck Creek and then bring me along.”

Dev A gets hired. Dev A loves it. Dev A tells Dev B “It’s time to apply,” and tells their super that they must talk with Dev B.

Finally, The Retort!

From here, many things happen. Some end in Dev B being hired, some do not. The risks mentioned above are around what if we hire Dev A & Dev B and they’re both duds. Terminate them both. Sorry for being so cold, but that’s how it is.

The bigger risk however is in what happens when we ONLY hire one of the two. There are so many scenarios that can come out of this, and only one ends well for the company.

It all starts from the premise of Dev A cannot get Dev B on, but this is a part of their dynamic duo. You are destroying the universe by not letting these two work together! Dramatic, I guess.

The best possible outcome the company can expect is that Dev A pairs up with someone else and can crank out the quality work without Dev B, and that they are happy and stay.

But that never happens. The reality goes a little more like this.

  • Dev A comes to said company.
  • Dev B stays at former company, and Dev A cannot get Dev B on to said company.
  • Both Dev A AND Dev B have to make a decision, and this decision will impact said company.

Possible outcomes are:

  1. Dev A returns to former employer.
  2. Dev B goes to new employer and solicits Dev A. Dev A leaves.
  3. Dev A and B leave both employers and go at it themselves.

All of these cause us to lose Dev A. All of these cause us to invest money in training that is wasted.

You know that there have been plenty of examples of all of the three options; how many have you seen? Do you still believe we are at more risk by hiring the pair?

By living in fear of an undefined and really non-existent risk, we block ourselves from some potentially great candidates and great reward for the business.

Some Proof

“Proof” A

Well, it’s not scientific. But, the VP of my former employer approached me in the first week and said “I want your recommendations. Who can you bring on?” I was going from middle management into a development position with no opportunity at that time for management. This was based on me being a developer (back when I still had a conceal & carry developer card), and yet I was still personally asked to bring on my counter-part. I suppose it’s possible they hired me because of Dev B, but I don’t think so because there had been no mention of this yet.

At all of my employers, I have welcomed and requested referrals; that is nothing new. Additionally, I have reached out to some individuals, and I know others have done this as well. The bottom line is that we want referrals; why is it so crazy to ask that they come in as a pair?

“Proof” B

In the above scenario under the retort, I am projecting myself based on a couple different situations I have been a first person player in, as well as picturing similar scenarios I have seen.

In the most relevant, I was Dev A, and I was unable to get Dev B on to employer 1. So, I went to employer 2, and I was still unable to get Dev B on. I also found another Dev B, and it took me a while to get that Dev B on. With the first Dev B, it was not because of reasons by the company, just random circumstances with Dev B. I have decided to stay with the company, but you can bet that there have been a lot of talks between Dev B and I about how we were going to do it our own way, especially during employer 1.

What kept me here? My team, and a select few individuals. And my team very validly pointed out that people want to come back here because of that. To me, that’s proof of this idea.

I like what I do, and I’m having fun at it, but it’s the people you work with more than anything that make you want to stay.

An aside, I refer to the first to leave as Dev A; I hold my Dev B’s in high regard and would say that they can code circles around me. They are listed as B because I made the move first.

Closing

Are you a dynamic duo? I want to talk to you. I cannot promise that anything will come of it, but let’s talk.

And to Dev B out there, thanks for being patient. You rock!

All Night Hockey Tournament benefiting the Wounded Warrior Project

What: All Night Ice Hockey Tournament & fundraiser benefiting the Wounded Warrior Project in Mark Olving’s name.

When: Saturday, January 28, following the Mizzou @ MSU Ice Hockey Game.

Where: Mediacom Ice Park, Springfield, MO.

Background

As many of you know, I play ice hockey on an adult recreational team in Springfield, MO. I served in the US Army and am on a team that is comprised of active duty and prior service.

One of our teammates, Mark Olving, was deployed to Afghanistan about this time last year and was injured in an attack. He has recovered and has the Wounded Warrior Project to thank for their aid in the times of healing and beyond.

With Mark’s support, we are hosting an overnight tournament starting Saturday, January 28. This tournament will begin following the game of Mizzou vs. MSU at the Mediacom Ice Park. All of the proceeds raised are donated to the Wounded Warrior Project in honor of Mark Olving.

The Mediacom Ice Park, along with the Springfield Park Board, have graciously donated the ice for this cause. In addition, the Mizzou Hockey club and Missouri State Ice Bears have offered to help, and we are working through the details of what we can do that will be fun and unique.

Fundraiser Event Highlights

Here are some highlights:

  • Teams are donating $100 to play.
  • Many local companies have sponsored the event and will be featured on T-Shirts which are handed out to all participants.
  • The referees, although blind, have volunteered to referee the games, as well as they have donated $100 to play as a team. We intend to make sure at least three of them are in the penalty box at all times during their games.
  • The Springfield Park Board and Mediacom Ice Park have donated the ice for our use.
  • The Mizzou Hockey club and MSU Ice Bears have offered to help, and we are working through these details. A couple ideas include an open skate with the players ($5 donation recommended) and auctioning off of signed jerseys.
  • The game between Mizzou and MSU is always fun to watch, whether you are an alum or not. This has developed into a great rivalry over the years and is usually a series you do not want to miss.

Interested? You can help!

Here’s how:

  • Donate directly on our page at the Wounded Warrior Project. Your donation through this site is tax deductible, and a receipt will automatically be sent to you.
  • Read more about the Wounded Warrior project here
  • Attend the game on Saturday, January 28 at 7:00 PM at the Mediacom Ice Park and participate in one of the fundraisers.
  • Tell your friends!

Proud Sponsors

The following companies, listed in alphabetical order, have contributed $250.00 or more:

Notes:

  1. The TinyUrl donation link redirects to the full link of https://support.woundedwarriorproject.org/group-fundraising/12hoursofhockeyteam
  2. The link for the Blind Mice is hosted on Wikipedia, which will be down the day of 1/18/2012 in protest of SOPA and PIPA. Don’t worry, they’re blind mice, they won’t notice.

Thank you in advance!

The Need For Offices

There are a few areas that I am extremely passionate about. Efficiency and productivity get me fired up, especially when I identify items that are impacting it.

Recently I’ve had a few posts about tweaking systems or habits to squeeze more out of your current habits. Those are valid, and should apply to just about any situation.

However, each of those posts were a regurgitation of things that I have said before, and those things have been shaped by what others before me have said. I took the time to post them when the need arose to pass along the information. Meaning, I saw a specific sign that someone could benefit from one of those suggestions.

Specifically, I’m thinking of Office Hours, Tuned-In Time is Underrated, and Email Doesn’t Own Me. These are symptoms to the bigger problem, which I also love to rant about, and that is the need for offices.

My Business Working Environment

There is one thing I hate about my job. Not the thing I hate most, just one thing that I hate. The environment SUCKS!

Am I being dramatic? Well yes, but… I worked in the call center at Bass Pro. I said a call center; you know, phones ringing off the hook, and your job is to take orders and up-sell. Bass Pro also doesn’t care at all about their employees in the call center. That might even be written into their corporate statement.

Where am I going with this? My digs there were far superior to mine now, and that includes my recent move and reorganization of my desk space. Call center versus software development company, and the software development company loses. That should hopefully give you an idea of how bad it actually is. What I find funny is that I have been wanting to write about this for a while. I’m pushing a case at work to fix this, and someone pointed me to a post by Joel Spolsky from 2003. His complaints were the same as mine. I guess it’s the other way around. He said as the owner, he was finally in a position to do something about it, so he did. I think that I am too.

The Reasoning and Intent was Good

Where our current set up came from and the idea that it’s based upon is extremely valid. Our founders wanted open collaboration and did not want to deal with offices because they wanted to avoid status. They wanted to be approachable.

The problem is that the company has grown substantially since that point. If you take ten people and put them together on the same project in a building with cubes and open space, it will almost definitely work out well. These people work closely together, and anything one of them has to say is relevant to the other nine.

However, when you grow to 150 people in one location, this model no longer works. We stuck with the model because that’s what we had when we were founded. It supported the goal of not using offices for status and offered open communication. What we failed to do and failed to realize, is that we need to make small teams, like the first ten, that have private work space. We have the teams, but we do not have the private work space, and the teams do not have dedicated space.

Signs & Symptoms That Your Work Environment Sucks

A sign is something you can see:

  • I can see all of the developers with headphones on.
  • I can see that ALL 15 of our conference rooms are occupied!
  • I can see that Individual A has about a quarter of their time tied up in meetings, and many of these are with members of their own team.

A symptom is something you feel:

  • At the end of the day, I feel like I have accomplished nothing.
  • I have to stay late just to keep up, and I’m never getting ahead.
  • I don’t have time to process all of my emails.
  • It feels like my title should be “Meeting Attendant.”
  • I need to be able to collaborate with Individual A, but when I’m free, they’re in meetings or we can never find a space to talk.

You may be saying to yourself “but I’m the most productive when I have my headphones on.” That may be, but I would bet it’s for banging work out; tasks that Assistant You are doing, and they don’t require thinking or creative design. You’ve put all of that in already (and probably struggled to find time, peace and quiet to do that effectively) and now you’re simply just being a code monkey.

Again regurgitating the statements of others, the authors of Peopleware point out that music stimulates the creative parts of your brain; if it is occupied by music, how can you possibly be doing anything else creative?

And picture this. We have a building with about 150 people in it. We have 15 conference rooms, which includes a huge one that seats about 100 people:

  • Developer A needs to speak with person B, be that a manager, a customer on the phone, another developer, QA, etc. The two then proceed to walk around and find out that all 15 of our conference rooms are taken, by others in the same scenario. By the time they finally find somewhere, they have likely lost time and quite possibly energy or enthusiasm about the task at hand.

The authors of Peopleware explain a lot more signs and symptoms in the chapter titled “You Never Get Anything Done Around Here Between 9 and 5.” I highly recommend you read or revisit the book. It’s available on Kindle now, which is awesome for regurgitating quotes! :-D

The Goals and Motivation Behind Offices

  • The biggest one is to make the signs and symptoms go away. I will gladly welcome the new set of signs and symptoms that ensues, and I will happily put some guidelines in place to make sure we limit the new potential problems and that this is successful.

  • Individuals should not be inhibited from meeting. If Developer A needs to speak with QA B, or a team wants to do a war room or brainstorming session, their question should not be “Where can we go?” but rather, “Your space or mine?”

  • The need for formal meetings should be drastically reduced. Teams and individuals should have the appropriate space to meet and discuss spontaneously. Communication should be available without the concern of it impacting another team or individual. Creativity should never be hindered by the work environment. War rooms should not need to be scheduled 3 weeks in advanced, any developer’s office should be able to be used.

  • Employees spend a good portion of their time and lives at work. Therefore it should be a place that they enjoy hanging out at, a place they are proud of and look forward to going to rather than something they dread.

  • Establishing a first-class environment will send the message that we are a first-class organization. This will help us draw and retain the best talent, and furthermore, it will allow the best talent the opportunity to deliver at their full potential.

The Needs

  • Every thinker needs a private office. While my span is developers, I think the same needs go for QA & Doc.

  • Offices should be large enough to accommodate a couple individuals comfortably and should allow for brainstorming or creative thinking.

    • They need to be a minimum of 100 square feet, with at least 30 square feet of desk space. 150 square feet per person would be preferable.

    • Desks should not be stuck directly on a wall. The recommendation is that the nearest obstacle beyond the desk be at least ten feet away. This not only helps prevent poor eyesight and fatigue, it offers a boost in productivity. This also justifies 150 square feet per person.

    • White boards should be present in every office.

    • Sufficient space should be allowed for live plants. These clean the air and offer a positive boost in attitude and mental state.

    • Anyone should be able to host a small brainstorming session, war room, pair programming, etc comfortably and effectively in their office. If I’m Developer A and I’m working on something, I want QA B to be sitting right beside me shooting holes in it.

  • Ceilings should be high, at least 9 feet. Low ceilings generate the feeling of being boxed in and prevent free thought.

  • Offices should have windows to the outside world. You wouldn’t fathom a bedroom, hotel, or apartment that doesn’t offer this; your office should provide it too.

    • Offices should feature sufficient ambient light. When this cannot be provided directly by ambient outdoor light, it should be made up by staged, indirect light rather than overhead fluorescent lights. Just as you use multiple layers of light in your home, the same should apply in the office. See this excerpt on the effect of fluorescent lights for more information.
  • It would be ideal if a group of offices opened into a common space for a team.

    • This would allow ad-hoc meetings to happen and greatly reduce the need for formal team meetings as well as dedicated conference rooms.
    • It also allows teams to work the more formal meetings around any schedule that the teams determine, rather than being at the mercy of when a conference room is available. This should increase the amount of [Tuned-In Time][tunedIn] each person has.

The Metrics

Being that this is a push for increased productivity and efficiency, you must have metrics. They justify the expense and give you something to fall back on when questioned about your decision to double or triple the cost in office space. Managers love metrics. When they take away our developer cards and swap our brains out with pre-programmed chips, we inherit an affinity for metrics. (An upcoming rant of mine will be on the difficulty of gathering metrics… they should be a side effect of people doing their job, not a separate, tedious effort. I’m talking about you, TeamTrash!)

There are many things we can measure both before and after. I would expect to see a spike in each of these immediately due to the Hawthorne Effect, but given sufficient time to let them balance out, I expect that we will see a huge improvement overall in each area.

  1. How many people turn us down our offer for reasons other than compensation levels?
  2. How many more applications do we receive?
  3. What is the velocity of teams?
  4. What is the satisfaction level of the individual?
  5. What is the defect to feature ratio?
  6. How many people list the working environment as a reason for leaving in their exit interviews?
  7. What is the number of meetings per week across the department?
  8. What is the total number of hours spent in meetings across the department?
  9. Has Damon moved on to nag or rant about a new topic?

Support

Our people are our most expensive and most important assets. Why then do we try to skimp on the items that support them? Because we fall victims to the items that we can measure on an accounting ledger. Office space shows up there; the cost of the reduction in productivity and increase in defects do not.

Office space makes up such a small, insignificant portion of the fees that we hurt ourselves to try to save money in this area. I’m making up completely hypothetical numbers here to prove a point, and to make the math easy, probably mostly for my benefit.

Let’s assume that all told, including the overhead of benefits, infrastructure (office, internet, electricity, etc) and corporate taxes, an employee cost you $100k per year.

Of that, based on 50 square feet at $10 RSF / square foot / year, we spend $500 on a person for strictly office space. How much of an increase in their productivity do you need to see to make it worthwhile to spend an extra $500 per year on that person? A whopping total of $1000 per year per person? HALF A PERCENT!

And how much does a bug cost you? If it’s less than $500, or even less than the total $1,000 I want to spend per person, I have an awesome outsourcing opportunity that will benefit us both!

This is why I adamantly state that any time you try to cut costs on office space by reducing the facilities you provide to your employees, you are doing more harm than good.

Summary

As free thinkers, managers, people with voices and opinions, we need to fix this. It’s costing us too much not to.

References

Peopleware, Dorset House Publishing, 2nd Edition, Tom DeMarco and Timothy Lister, 1999, ISBN: 978-0-932633-43-9; Amazon link

Tuned-In Time & Office Hours

I recently introduced a new (to us) concept called Office Hours. This is an approach to recognizing and supporting the need for communication external to the team while balancing that with the need of the team to focus internally.

The end goal is to increase the amount of time you are able to focus on your core responsibility, and to group these periods of focus into as large of blocks of time as possible.

In order for it to be successful, there are a few guidelines that need to be followed.

Tuned-In Time

The key to this being successful is for everyone to be aware and strive for tuned-in time. It also means that managers, PMs, or anyone else that schedules meetings should be aware of your hours and try to respect these hours.

Tuned-in time is defined as a block of time, equal to or greater than one continuous hour, where you are focused on one task or responsibility. This does not mean that you cannot discuss code or your task at hand; collaboration is part of the development process. It simply means that all work performed during that period is dedicated to the task and hand and free of interruptions.

Set-up

The easiest way to do this is use Baralga. Your approach may vary, but I will describe a simple set-up, using two tasks:

  • Chores
  • Focus

Chores are communication or other items you must do, such as email, IM, old-school people talking to each other, other social media, meetings… I think you get the picture.

Focus is for whatever your core responsibility is. You can also substitute a task number and name to make reporting to your time tracking system easier, and Baralga will sort by this. For example:

359915 – Code Coverage

Recording Tuned-in time

While in your tuned-in time, if someone interrupts you, simply stop and start Baralga. You do not need to change tasks.

If you need to take a break other than lunch, simply stop and start Baralga when you leave, and stop and start when you return. You do not need to change tasks, nor record this time as being on break. The important thing is that the interruption appears. You will likely find that after about an hour of tuned-in time, you will need to get up and walk around for a few minutes to clear your mind and refresh.

If however you are switching over to Administration, change topics; Baralga will mark the current task closed, and then mark the new task open.

And, if you go to lunch, record this as a hard stop, then record the start to the appropriate task when you return.

Reporting

At the end of the iteration, export the time for the iteration to CSV or Excel. Set up conditional formatting to highlight lines where the duration of the activity are greater than or equal to an hour. Sum these, and this is your total tuned-in time.

Maximizing Tuned-In Time

Set Office Hours

Agree to a schedule for “office hours.” During this period, you check and respond to email, IM, or any other forms of outward communication.

Pick a schedule, such as first thing in the morning, just before lunch, right after lunch, and at the end of the day. During this time, you read and respond to email or IM.

You can also plan these hours around existing recurring meetings, such as 30 minutes before the meeting. This gives you time to prepare for the meeting and you were going to be interrupted anyway.

The rest of the time, these applications are CLOSED!!! Not minimized, closed. This is very important, because an email or IM toast will take you out of what you’re doing and tempt you to reply at this point.

The number of blocks and length of these blocks for Office Hours will depend on the amount of outward communication you are responsible for. In RJ & Danny’s recent experiment with this, they started with three blocks per day, each at 30 minutes long.

They may have tweaked this a bit, and you’ll have days where you have to violate this, but the goal is to have general Office Hours that you try to adhere to.

Set Preferred Meeting Hours

Rather than trying to set your Office Hours so that they are long enough to handle one-off meetings, pick a preferred time for these and communicate that with your bucket.

If possible, coordinate with your team members to pick the same slot. If you’re really lucky, you may be able to coordinate with your entire bucket to pick the same slot!

Share Your Availability

Once you have determined your Office Hours and your Preferred Meeting Hours, it’s time to communicate that.

There are two very simple ways to do this. One is buy an open/closed sign from your local office supply store, or create a print out. Post this, and make sure you can see it too, because this is just as much for you as it is for everyone else.

Next, update your calendar to reflect your availability. Add recurring events titled “Preferred Meeting Time” and mark the time as available (or tentative, depending on your calendar). And add recurring events titled “Tuned-In” and mark the time for these as busy.

Q & A

I’ve received a few questions and suggestions around this topic. I have summarized the questions, these are not direct quotes.

  1. Is this required? No, I did not require it, although I highly recommended and strongly encouraged everyone to try it. I will be following up with a push for this again soon. I urge you to encourage your teams to try it out for at least one or two iterations. You will be surprised how much of a difference this makes.
  2. Is this rigid? No. That wasn’t the exact question, but the idea is try this out and tailor it to your needs. Also, there are always circumstances that arise; strive for time-boxing, but you have to be flexible.
  3. What about remote teams? That changes your approach a bit, since your communication is over chat, Twitter, etc. You would probably want to leave IM open but mark yourself as busy (Communicator should handle this for you). The team members can then communicate with each other in the busy state, but outside members should strive not to. If you are in something where you need absolute isolation, even from your team members, change it to Do Not Disturb or go offline at this point.
  4. What about Support? Again, tailor this to meet your needs. You may find that you want to make your Office Hours a bit longer, or allow more blocks for Preferred Meeting Times. Or you may want to flip this and list your Closed hours instead, carving out a few blocks for yourself for tuned-in time.
  5. What about calendar reminders for meetings? Keep Outlook open but set it to offline mode. Or try out Rainlendar.
  6. What about people in other locations or departments critically needing to reach me? Worst case, someone picks up the phone and calls you. This disrupts you and others around you, but the point is that if they need you, they will find you. This goes back to flexibility and tailoring this to meet your needs; if you want to keep IM open but in the Busy state, make sure you communicate to others what your office hours are.
  7. Is this about metrics? I paraphrased again, but no. This is about getting more tuned-in time for each of us. Those who have tried this, love it. Well, those who have tried it that I have solicited information from!