Tuesday, March 18, 2008

Do you suffer from DID? Part 2

I Think Its Happening Again!

When is one likely to suffer a DID episode? If you recall from my previous post one who suffers from DID, "Transitions from one identity to another are often triggered by psychosocial stress." If its true that stress triggers DID, then simply reduce stress in order to reduce the likelihood of future episodes.

First, identify what causes stress on the team. It could be anything from an unstable code base to a physically uncomfortable work area, whatever the cause bring it out to the light! Motivate your team to take an hour out of the schedule to identify the stress points, preferably in an informal environment but make sure that everyone knows this is a serious meeting!

Once your team has identified what your impediments are, get rid of 'em! Don't try and change everything all at once because you might find yourself getting overwhelmed and not fix anything. Focus on one problem at a time until its out of the way and then tackle the next one.

Identify "The Problem"

I once worked on a project where I was the "new hire", the rest of the team was composed of a few junior developers, our project lead, and the project manager. The project, which was a few months behind schedule, was for a strategic client and success would mean we would land several other deals with their teams across the globe! The developers where only working on the project two weeks and on my first day we were moved into a "war room" to start "crunch time".

war room (noun):
  1. a room at a military headquarters in which strategy is planned and current battle situations are monitored.
  2. any room of similar function, as in a civilian or business organization.
crunch time (noun):
  1. a period of intense pressure; a critical situation: "It's crunch time for high-tech companies."
In our case, the war room consisted of a corner with a bunch of broken down cubicles. I thought great, this will improve communication in the spirit of "sit-together" and "whole team". However when mixed together with summer season crunch time (12-hour work days plus Saturdays), our communication manifested itself as annoyance, disruption, arguments, and often silence.

Our team would blow off steam drinking alcohol, which allowed us to let our guard down and started revealing all of our concerns about the project. Everyone would exclaim how much we hated the project because of changing requirements; impossible deadlines; brittle code; slow computers; no A/C on the weekends; long work days; 3 am international conferences calls; slow feedback from a manual QA process; and many other things we don't have time to mention.

Although we would get together outside of work to "get things off our chest", it did not improve the quality of life or make the software any better. All we did was identify the problem but some teams don't even do that much because they are in denial.

Deal With "The Problem"

It's not enough to speak but to take action! As I mentioned earlier its best to deal with one issue at a time. Start with one you can get done in less than a week and of course the one that is in your control. In my case I was able to deal with the brittle code problem by encouraging my team to use test first development. I knew that writing test cases would help us because...
The more stress you feel, the less testing you will do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel. [Beck in TDD By Example]
When I took on my first tech lead project, I stood firm and told them that I would not accept any code that was not tested. Tim agreed under the condition that I give him some time to write the code before working on the test cases. I told him that we could work together to set up Eclipse and write some of the test cases when he was ready but told him it would be easier if he wrote the tests first.

The time finally came when we sat together to write some test cases. During our first session the tests revealed that the components he was working on were tightly coupled and we eventually caught a few bugs. Tim was so impressed that he vowed never again to write code without tests!

The Results

For the first time, our team was confident with the code we were releasing and having a suite of regression test gave us the support we needed to start delivering code faster! The project manager was amazed to see the JUnit report and how fast we were able to deal with bugs and adjusting to add new features! Simply writing a few test cases helped us reduce our stress exponentially. For the first time we were making promises that did not require us to work 60 hour work weeks!

Today, I am proud to say that a few of my former team members continue to use TDD and have moved adopt other agile practices. Tim, for example, is a Scrum Master who practices XP and he is a contributor on the Eclipse BRT project. If you are reading this aren't you glad I turned you on to it?

So why don't you give it a shot? Identify what's wrong and fix it one problem at a time! I guarantee that it is going to reduce your chances of having another DID episode!


Tim Myer said...

This is Tim. Indeed, I am very grateful for that great introduction to TDD. This is the story from a different perspective:
It was 5:30pm, which at that time was particularly early for me to consider leaving work, even though I had already been working a 10 hour day. I knew that if I could leave work before 6, I would be able to find parking; any later and I could end up driving around for at least an hour.
On my way out, I noticed that you were getting frustrated because of an impending deadline and because you were finding some areas of code where tests had been written incompletely. I asked what I could do to help and you described some of what was on your plate. One particular chunk stood out, and I said that it would take me 20 minutes to get that feature to you. You asked if that included tests, and I just brushed it off. Even though I had been advocating automating test cases in the company for a couple of weeks because it made sense "in theory", I had never written any, and I figured this notoriously un-testable area of framework code was not the place to start, especially if I wanted to get home at any decent hour.
20 minutes later, you poked your head in and asked to see my test cases. I laughed, figuring that I was doing you a big favor by taking personal time to get you a high-priority item quickly. You said to me something to the effect of, "Go home. What you're writing isn't going to do me any good because, as soon as just one bug is opened for it, I will have to spend twice as much time figuring out what you wrote as it took you to write it." That opened my eyes -- I had a good reputation as a very competent CYA-coder at the company, and here you were rejecting what I was writing without even looking at it. I took that as a challenge. We paired for that first test case, as you showed me where to find good testing resources and which atreas of code were going to be hardest to test. If only we had paired from the start!
One time is all it took to get me hooked, and, you are right, since then I have not been willing to write code without corresponding automated tests, even in companies where the culture does not value TDD, or perceives that kind of built-in quality is an inefficient use of a Software Engineer's time and would rather leave (the often manual testing process) to a separate QA department.
After one test case, all the "theory" that I had been hollowly advocating showed immediate practical value, and, as we discovered areas in my small chunk of code that would have been problematic or where the APIs were not quite what you were looking for, I realized that without test-driving my code, the favor that I thought I was doing for you was, in fact, a dis-service.
It took me a long time to find parking that night (and I was even pulled-over for a missing license plate and for having NJ registration but living in Inwood, but that's another story), but it was the night that I became re-invigorated about developing software and that I started on the road to becoming a professional Software Engineer and not just a guy who writes code.

Ariel Valentin said...

Thanks Tim!
When I read it from your perspective I now realize how tough (rude) I was on everyone...
I will try not to sugar coat any other examples from now and on!

Tim Myer said...

I should be the one thanking you, so no thanks are necessary on your part.
I will say this -- if you had not challenged me to expand my own horizons and to think beyond my own small contribution to the project, I would not be the developer I am now. For some developers, not only myself, shame IS an effective motivator.