Wednesday, April 25, 2012

Agile In A Flash - Bias toward testing

Wordle: AgileInAFlash-April2012
I was surprised to find that Jeff and I have been talking so much about testing over at Agile In A Flash.

Jeff and I are quite emphatic about the importance of TDD and automated testing in general. Some of our most popular cards are about testing.  It shows our bias that a lot of the value of Agile methods are lived out in the elevation of testing to a first-class concern.

We always want to know that our code works. We never want to be in the dark about it. Quality should be a given in an agile project. Heck, quality should be king in any project. High-quality, low-functionality enables iterative and incremental development whether the team is agile or not.

We always want tests to set the goal for us.

While the blog (and deck) are not just about testing, testing holds a special place in our minds and hearts.

I guess it should not have been surprised at all.


Tuesday, April 17, 2012

Rewards and Performance Revisit

I know it's going to sound like I'm trying to talk my boss and yours out of giving us both raises, and of course I'm not, but I keep hearing people tell me they're worried that they can't work in teams because their system pits them against one another.

Usually it's an excuse or reason for not pairing. "If I improve my colleague, he will beat me to the incentives" or "if we do his work first, then there's a chance I'll fall behind."  I'm not a fan of individual work assignments, and I'm not a fan of competitive incentives. Rather than rant about it, I'd like to point you to some other authors and how they feel about the topic:

I don't make any money from slamming people who are trying to do a good job, whether in software development, testing, management, or consulting. I certainly have all sympathy for people who are trying to make their way and Do The Right Thing, including doing right by their bosses. I think good soldiers and good citizens are worth their weight in gold. I'm not slamming anyone.

What I am doing is asking that people consider what the science says. I've been on a couple of mind-bogglingly good teams in my life, and we didn't worry about forced ranking and annual reviews and how one of us might get more than their fair share. We just worked. When it's all about the work, we can be colleagues and friends and coworkers and good things can happen.

I have alternative views about career paths, and you can look there when you feel the urge.

Maybe I'm pining for some of my glory days, against my own best advice, but I would love to see people able to surpass the best working relationships I've seen personally. I don't think it's impossible, just impeded.

Monday, April 16, 2012

Retrospectives: What was that about hats, again?


Did you watch Monty Python's The Meaning Of Life? There is a great scene that takes place in the Very Big Corporation of America, excerpted here:
CHAIRMAN:...Item six on the agenda: the meaning of life. Now, uh, Harry, you've had some thoughts on this.
HARRY: That's right. Yeah, I've had a team working on this over the past few weeks, and, uh, what we've come up with can be reduced to two fundamental concepts. One: people are not wearing enough hats. Two: matter is energy. In the universe, there are many energy fields which we cannot normally perceive. Some energies have a spiritual source which act upon a person's soul. However, this soul does not exist ab initio, as orthodox Christianity teaches. It has to be brought into existence by a process of guided self-observation. However, this is rarely achieved, owing to man's unique ability to be distracted from spiritual matters by everyday trivia.
[pause]
BERT:What was that about hats, again?


The Pythons struck a fairly deep chord in me with this humorous indictment of human (and particularly American) shallowness.

Agile methods are anchored in empirical Inspect and Adapt methods (most famously the PDCA cycle).

Without action anchored in observation and reflection, nothing really improves and the scrum rituals and practices become meaningless. However, when teams become responsible for their results and begin measuring and experimenting there is no limit to what they can do.

Has your team started its process of guided self-observation? You might find some hints here on how to make your retrospective more effective.

Sunday, April 8, 2012

Fish Among Kangaroos: A Leadership Failure Tale


One day, a fish came to visit some kangaroos. He saw right away that the kangaroos spent all their time hopping on the dusty ground and browsing among the shrubs. Their habits would never work, and surely lead to their deaths, if they were to come to the ocean reefs even for a single month!


"Foolish kangaroos," he called to them, "heed my words and live! This hopping and browsing is pointless madness! You must learn to paddle and snatch live prey from among the rocks! The ocean is no place for hopping air-breathing creatures, so come follow me and learn the better way!"

The kangaroos, amazingly well-adapted to their un-ocean-ly environment, dutifully ignored the fish. They looked for common ground for conversation, but somehow the topic always turned to the futility of hopping and the unpleasantness of a dry environment. Sometimes they asked polite questions, and the patient among them tried to explain that their way of life was forever on solid ground where browsing and hopping are pleasant and efficient. They explained that attempting to swim in the dust and snatch prey with their teeth would be as foolish for them as it would be for the fish to hop and browse.

The fish, increasingly frustrated, tried all manner of convincing argument. He tried to explain that their way of life would never free them from the solid ground (a mere 25% of the planet) and teach them to survive among the reefs. However hard he tried, he could not reach them. It was simply not to be.

The kangaroos stubbornly refused to follow the fish, despite his superior sea experience.

Monday, April 2, 2012

Really TDD-ing: Less simple than you think


TDD is a pretty simple system, as popularly described.  For an individual doing a kata or playing with some example code it is really just three steps. On card #44 of AgileInAFlash it looks like this:

It's the right way to think about TDD, and the right way to get started.

When you get to a real project in a team environment you have many other issues to consider.  In a modern team environment, with a DVCS, it looks more like this:
  1. Get the current code (git pull, get clone, hg pull -u, whatever)
  2. Run all the tests and be sure they're all really green, to avoid blaming yourself for unrelated breakages.
  3. If there are no tests, write a trivial failing test ("assertTrue(false)") to prove your testing setup (ide, scripts, makefiles) really work. Then delete the trivial test.
  4. Write one "real" red test. INSIST ON RED.
  5. Write code to turn it green.
  6. Local commit "save your game"
  7. Refactor (or intentionally choose not to).
  8. Check to be sure you're still green.
  9. Local commit.
  10. Push your change to the shared repo (or have a darned good reason not to).
  11. Start from (1) again.
The first two steps are really important, because our peers may have checked in code without being sure that all the tests pass. We don't always work with perfect Agile coworkers (especially in a company with multiple teams, or one in transition, or both).

If you don't commit on either side of a refactoring (steps 6 and 9) you can quickly end up with no recourse but to revert and lose minutes or hours of work. Because the hard part of programming is the learning and thinking, losing code is really a triviality but it isn't fun to have to retype the code you have already built once.  It's good to have a known "green" state to return to, and the more recent the better. 

There is more to the flow than I listed, though. If you get a red test, you have to back up a few steps. If you did anything significant, you will want to push to the main code line after each refactoring and possibly after each green bar (steps 9 and 6, respectively). 

It's often wise to put the "real" code to turn the test green (step 5) into your test class initially, and then migrate it to the production code during the refactoring break (step 7). It keeps you from having to bounce around between a bunch of files and tightens your cycle considerably.

Since you are pair-programming -- as sensible people do -- you might switch pairs at every red (step 4) or every green test result (step 5). That's a small ritual that keeps everyone's head in the game. 

If you have a messy code base and/or a refactoring that touches code in a great many places, you may want to do the refactoring (step 7) in the fresh main line code, and then pull the refactoring back to your local copy. Trying to keep large refactorings in a branch will cause a lot of integration pain. Best to get it to everyone soon, and get it over with.

If you use feature branching (God help you) then everything gets harder to do, and you'll feel a pressure to avoid pulling code updates and rerunning tests (steps 1 & 2). Avoiding them makes it worse. The longer you're off the main code line, the worse all your merges will be. Get back on soonest.

If you don't have a DVCS (again, God help you!) then it all gets rather messy because non-distributed version control means you can't have a local commit. Some people say that's better, but I say it ain't*. A remote commit takes a lot more time than a local savepoint, and having dozens of them at once, every minute or two from every pair, can drag a reasonably good server to its knees.



* Apologies to Billy Joel, and of course my 4th grade English teacher.