Agile Otter Blog

Why not C++ all the time?

2012-01-19T09:24:00.000-08:00

In the why-we-don't-prefer-programming-in-c++ exhibit of evidence:

python:

  result = line.split(',')

C#:

  var result = line.Split(',');

C++:

  vector<string> result;
  ostringstream sourcestream(sourceString);
  copy(
     istream_iterator<string>(sourcestream), 
     istream_itearator<string>(), 
     back_inserter<vector<string> >(result) 
  );

Special thanks to StackOverflow Zunino at Stack Overflow for this answer, one of the most concise and standards-respecting.

Join Fresh Start Week 2012

2011-12-05T18:31:00.000-08:00

Soon we'll be on the other side of Christmas and starting a new year.

How about for the first week of January we try doing without copy-and-edit programming. What would happen if we were to write code off the top of our heads?

Don't just hand-type the example code you would have copied anyway, but try writing it as if the code you really wanted already existed. How would you have liked to initialize that class? When you are writing a test, do the order of the parameters of that method make sense? Are you doing three- or four- or five-step operations that ought to be their own function? Is the method you need a member of the object where you would expect to find it? You can't find out by doing copy-and-edit programming.

Let's all try the grand experiment of not copying ANYTHING for the first work week of January. What could it teach us? What could it hurt?

The hashtag will be #freshstartweek.

See you there.

Single-Return, AKA: Elephant-proofing your bathtub

2011-12-02T12:09:00.000-08:00

Single-entry, single-exit programming was a great breakthrough that led to a serious improvement in the lives of many programmers. In the jurassic period of software development, anyway. In the modern era, among good programmers, I think that single-exit is an example of the many once-best practices that outlive their usefulness.

Method length and nesting are our primary enemies. Multiple returns in nested, long methods turn trouble into disaster for the poor developer who has to understand and debug a routine, not to mention the guy who lost the coin toss and has to actually modify it. Once code is bad, multiple returns makes it far worse.

Start with pure function length:

In a 500-line function two returns is dangerous, and five would be maddening.
Drop to 50 lines, and it's still pretty daunting.
Drop to 10 lines, and the risk of missing a return or misunderstanding the method is slight.
At 5 lines, there's no hint of the problem that single-exit solves.

Switch to nesting depth:

If you are nested 15 conditionals and loops deep, that extra return is obscure with a capital O.
At 5 conditionals deep it's frightful. It's hard to tell at a glance which lines are being executed and when.
But what if you're never more than two levels deep in a function? Returns are crazy obvious.

See how this one rule serves you supremely well when your code stinks, but does you no favors when your code is short and clear?

Q: "Doctor, I broke my arm in two places! What should I do?"
A: "Stay out of those places!"

Single-entry/single-exit can even be harmful to the readability of an otherwise short function if it forces variables to be created up front instead of at first use, or if it causes code to be more deeply nested.

int doSomething(int parameter) {

int result = 0;

if ( 0 != parameter ) {

result = x/parameter;

}

return result

}

Here the real feature of the function (the division) is hidden inside an if clause. It makes the code seem as if its goal is to return zero, and that the division is a side effect that occurs when a condition is just right. It'a s funny de-emphasis of the essential goal of the function.

Let's invert the condition to create a guard clause instead:

int doSomething(int parameter) {

if ( 0 == parameter ) {

return 0;

}

return x/parameter;

}

The actual functionality is exalted, and the early return is more clearly an effect of having a parameter that you must protect against. The readability here is not degraded, but instead enhanced. This is a good time to remind the reader that the shortness of the function makes it so.

It is no worse even if I squish an if onto one line (another no-no in many shops).

int doSomething(parameter) {

if ( 0 == parameter ) {return 0;}

return x/parameter;

}

The same rule seems to apply when there are more parameters to check and when the work to be done is more than a single line:

int doSomething(int parameter1, double parameter2) {

if ( 0 == parameter1 ) {
return 0;
}
if ( (parameter2 < 0) || (parameter2 > 1)) {
return 0;
}
double part1 = parameter2 * x;
int result = int(part1/parameter);

return result;

}

We have the advantage that the function is divided into checking parameters and returning results, so it is still pretty readable and clean. There is little nesting, and few lines. On the other hand, the astute reader will notice that we're up to 11 lines now, and with a little more expansion we could have a Long Method on our hands, at which time the single-exit rule will apply again (welcome back to the Jurassic period).

We will outgrow an awful lot of our hard-n-fast rules by writing small, clear functions. A lot of "best practices" are really just "ways to tolerate poor practices."

Some of our old 1970s C programming rules were very valid in their time, but following them when they don't apply is as silly as a Chicagoan elephant-proofing his bathtub.

Performance Appraisal Time?

2011-12-01T07:29:00.000-08:00

As you head into year-end appraisals, here are a few resources for you.

Note: most of you employees do want time with their bosses, they just don't want a once-a-year backward-looking judgement. They'd rather the boss was a part of their team and gave forward-looking direction all of the time. More feedback is better than less, and more engagement too.

For some other pointers, see:

Preserving Wasteful Practices

2011-11-18T10:00:00.000-08:00

If We Had Done The Right Thing To Begin With

2011-10-28T05:38:00.000-07:00

Error-avoiding is overrated. Too often people want to wait surprisingly long periods of time before making a move, in fear that their move might be the wrong thing to do. The amount of fear and pre-thought we put into projects can be staggering.

I'm not here to say that design and architecture and platform design aren't important. Clearly there is value to having a workable plan and a goal in sight. However, the idea that you must be right on the first day of development flies in the face of all our experience with application development. You only need to be "right enough" at first, and able to correct as time goes on.

We can become invested in concepts, ideas, development stacks, and architectures to the point that we forget that all up-front design decisions are just guesses. It's akin to a man walking up to the blackjack table with the intention to draw twice on the first hand and once on the second, even though those hands have not been dealt. The problem is that many smart developers will stick to the plan even if it fails to make development fluid and predictable, but if the gambler draws an 18 he wil decide not to draw twice after all. Do we realize that design is a bet? Do we continue to evaluate it, or do we take it as law on the day it is handed down from The Architect?

There are a small number of problems with being "right to begin with":

You'd have to know what "the right thing" is. A lot of systems have emergent designs that surprise their developers. Larry Wall is famous for saying that he had no idea Perl would look like it does today. An application may be written well in many ways, how can you know the One Right way in advance of actually building it?
You'd have to know that "the right thing" is right. In a system with many choices, any number of right-seeming ideas may be wrong. The iPhone showed us that a radical design may be more right and more influential than many conventional ideas of what is right. Countless other unnamed products have shown us the reverse. Being convinced of the rightness of their conventional design, one large mobile phone company ended up missing out on the most lucrative phone design of our lifetimes.
"The right thing" would have to already exist. It might be that the innovation your product needs will be invented/released/discovered six months into your product development effort. A Lean Startup approach involves constant "persevere or pivot" decisions, which can be applied to architecture as well as feature set.
The cost of discovering "the right thing" up-front needs to be less than the cost of discovering it through experimentation and development. If you took three months to design a system, and you could have discovered the same solution by building three three-weeks prototypes, you were not being responsible but wasteful. Always remember that design is a gamble.

The alternative is to learn and adjust as you go. It's no surprise that this is how software projects have succeeded (when they've succeeded) over the years.

From Agile Otter Blog

Architectural decisions are hard to make once-for-all in a system where functionality and platform and development practices change fluidly. A good choice of language, platform, and early features will give us a good early start, but these decisions need to change (with requisite changes in code) if they no longer serve the needs of the business, which includes the need for fluid delivery of functionality to customers.

Maybe finding the right thing is a combination of up-front thinking and ongoing discovery; maybe it always has been.

What should the well-dressed virtualenv wear?

2011-10-26T07:51:00.000-07:00

I'm back to hacking some python (fun stuff!) and have been noting some packages that every well-dressed virtualenv should have. I'm interested in knowing what you use, and for what.

Essential packages I can hardly live without:

bpython - because it's my favorite shell
sniffer - because CT is the bomb, and sniffer works on mac (autonose not so much)
mox - though I don't totally love it, I'm somewhat used to it now. May switch to something more context-manager-like.

Task-specific stuff:

BeautifulSoup - if I'm parsing stuff. I really like this library
mechanize - if I'm writing tests on a web framework. Other than js weakness, it's quite nice
feedparser - for rss stuff
PIL - because image manipulation is no fun without it

What do you feel a well-dressed virtualenv should wear this season?

Mercurial team workflow

2011-10-05T09:56:00.000-07:00

Dear Mercurial, I don't love you (yet).

This looks fine if you only spend a few minutes in the 2-3-2-3 loop. On the other hand, if you're in a very busy team and there are refactorings going on (and when shouldn't there be?) then you will want to have a loop from 3 to 1 pretty darned often (at LEAST a handful of times a day).

At step 1, "For a while" should mean "if a couple of commits have been made by coworkers."

The problem I have with mercurial is that the process of pull, merge, commit is too cumbersome. I have coworkers who swear by rebase, and others who have been bitten enough that they're scared to death to use rebase, and instead pile up the "merge" commits.
There needs to be some kind of change made, if only to fix rebase, because this work flow is broken for active, productive, agile teams.

The First Puzzle Challenge

2011-10-03T17:00:00.000-07:00

Today we held the first ever Puzzle Challenge at my client's site.

The goal of the challenge was for each team to pick a work style that aided them in getting the greatest number of puzzles completed in a very short time (10 minutes per sprint). The set of puzzles to solved was a mix of crosswords, mazes, word-search, sudoku, word jumbles, and number blocks. The teams were told that there was no partial credit at the end of the ten minute sprint. The teams were given a menu of practices to choose from:

Team members could one mode of adaptation, leadership, teamwork, noise level, and task switching. A style of 11111 would mean a 1 in each of these categories, a style strongly resembling an "ideal" organization in the buttoned-down 80s. A style of 33333 is basically a productive chaos, which might have been more widely recommended in the free-spirited 60s.

Teams made an initial selection, then were allowed some adaptation.

In initial selection of work style, teams tended toward twos or threes. As the challenge progressed and they realized how hard the "work" was and how short the time was, they tended to migrate toward 33333 in their style.

Is it surprising that when the chips are down, they opted for less command-and-control to help them increase speed?

Teams with the highest scores did a few surprising things. One is that they "cheated" by rejecting all work they could not accomplish easily within the 10-minute span. Although they were initially told that they should do the work in the priority order (as it was given to them), they quickly realized that the system was flawed and that taking on tasks larger than 10-minutes was a waste of their time and talent. Rejecting over-sized work gave them a distinctive edge. This is a lesson most agile teams should learn.

Another advantage went to teams where people chose the work based on their skills and interests instead of having work handed to them by a strong leader or by following strict priority. Doing work that interested them, in areas where they had already developed skills, moved them forward. Even so, they found a huge disadvantage in working alone. Most puzzles had at least two people working on them by the end of the second sprint, and this trend continued through the end of the challenge. Even when skills differed, there was no other advantage as great as having a partner.

Teams were further accelerated if they found the "Work-In-Progress sweet spot." If they had too much in progress, very little got finished. If they had too little in progress, stuff got done but scores were lower.

Some teams stopped taking on new work at the 2 minute (remaining) mark. There was little chance in starting jobs that could not be finished by the end of the sprint. Instead they spent the time talking about how they could perform better on the next sprint. Again, a lesson worth learning.

One challenge attendee said that he learned that chaos is hard to manage or predict, but it really helped get things done. I applaud his insight.

I was a little disappointed that some rebel didn't totally crush it by using a style I would never have chosen. That would have been cool, if puzzling. I suppose I'll have to settle for having my agile mindset validated once again.

Python History Visualized

2011-09-30T11:11:00.001-07:00

code_swarm - Python from Michael Ogawa on Vimeo.

Lean Startup and Efficiency

2011-09-27T10:25:00.000-07:00

Poignant quote on working in cross-functional teams with learning milestones:

"I predict that you pretty quickly will get feedback from your teams that the new process is reducing their productivity. They will ask to go back to the old way of working, in which they had the opportunity to “stay efficient” by working in larger batches and passing work between departments."

Ries, Eric (2011-09-13). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (p. 19). Crown Business. Kindle Edition.

Linus Torvalds Management Lessons

2011-09-27T08:32:00.000-07:00

See the recent article on management lessons from Linus Torvalds. Some important call-outs:

On external quality:

Torvalds concludes, “Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.”

On tooling:

“I don't think tools are all that fundamentally important.”
“Now, what is important is that there's a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don't necessarily really need tools. There's a lot of projects that simply don't have enough changes to really require any tools at all for their work flow; [...]"

Agile Coaching Camp wrapup

2011-09-26T14:19:00.000-07:00

I approached my second (their third) day of #ACCUS after a full night's sleep. The evening social time was great, because it involved some fine people.

I had two sessions, one each in the first and last timeslots of the day.

Pairing Styles

The first was a little workshop to identify and evaluate pairing styles. I was there to collect data primarily, and I did. We mapped the styles I had identified and added to them. The best part was the conversation among the attendees as we tried to evaluate them. The emergent thesis is that styles are not inherently good or bad, but that they reveal the relationship of the partners. All styles could be energizing, or could be draining, depending primarily on:

The involvement they bring to the session
The degree to which they both focus on the code instead of each other
The degree to which each recognizes the contribution of the other

The Coaching Oracle Deck

This idea was based on Brian Eno's famous Oblique Strategies concept, and the fun of fortune cookies. Glen Smith and I played with the idea years ago (he introduced me to the idea), and even had a little program to pop up the strategies. Sadly, that code and the original list of ideas were lost. It came back up at Agile And Beyond in Ann Arbor this year, and I happened upon those cards while sorting through my stuff at ACCUS.

We play-tested it informally in the common area while sessions went on elsewhere. I figured it was worth a more formal play-test.

I think that the session hit two snags. The first was that people were feeling much more emotionally involved as a result of other sessions going on that day, and the other was that I wasn't managing the pacing very well. Rather than play-testing a fun technique by stating a question and rating whether a randomly-drawn card just happened to be good advice in the scenario, we entered into a deeper talk about problems and possible directions. I really hadn't intended this to be a problem-solving session with deep emotional impact, but at an open space whatever happens is the only thing that could have.

I suspect that the primary value of the cards is that they are generally good things to think about, the randomness of the draw means that they'll come out of left field, and considering them will help take us out of ourselves. This thesis was not supported by our session. Instead, they were deeply considered, contextualized to the person drawing the card, and considered for their ability to point out a solution.

Agile Coach Camp U.S. - Saturday (#accus)

2011-09-24T15:14:00.000-07:00

I missed the Friday session. I worked a full day in Des Moines and then drove 11 hours (and into an earlier time zone) overnight. I only arrived this morning at about 4:30 or so and got parked and checked in. I slept from a little after 5 until 7, and then got up and headed to the conference after falling down some stairs and finally finding the conference site.

Even tired, slightly battered, and a little frustrated, I had a wonderful day.

I was pleased to meet up with many great coaches, devs, managers, and non-IT people here. I even have some new "new best friends."

The morning sessions involved growing learning cultures, integrating project teams, and systems thinking. They were had great questions, wonderful discussions, and prankish humor. It was a great morning.

I had intended to participate in the afternoon sessions, but the first one (on complacence, coincidentally) I missed to talk about other passions of mine with some of my coaching friends of old, and some brand new ones. We talked about coaching psychology, whether our coaching was necessarily agile, and how to avoid "going native."

Entirely without any intention to do so, I missed all of the afternoon sessions. It was a really great time, though, and the contacts are very important to me.

Tomorrow I'm running two sessions of the three time slots available, so I guess I can't miss much.

In the morning we're cataloging pair programming patterns, and in the last session of the day we're playtesting an agile version of Eno's "Oblique Strategies."

There is a lot of interest in a new site/blog for posting and analyzing code, in the strategies deck, in Agile In A Flash, and in the new pair programming work that Jim Hood and I are starting to work on. I have great stuff to do and need to get cracking.

I'm hoping to move one of my sessions so I can join George Dinwiddie and friends in a talk about metrics, but we'll see in the morning. I even had a minute or two with Lisa Crispin.

I can recommend ACCUS for everyone in the business or in its periphery as a great meeting of minds. I'm tired, and yet it has kept me energized all day.

The Build is Broken, Now What?

2011-09-20T19:48:00.001-07:00

Your team is hard at work, testing and coding and planning, and suddenly the build breaks. Now what can you do? The broken build might not be your fault at all, and besides you have work of your own to do. You could go ahead and practice business-as-usual, but this is probably a bad idea.

Here's what I say:

Never pull from a broken build. Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem.
Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way.
Never push to the CI server if your local build is broken. If your build is broken, it inconveniences only you. If someone is working on the build and you push a second mistake, they won't know if they fixed it or broke it worse. If the build is not broken, why bother pushing errors to it?
If you're not fixing the build, never push a working local change to a broken build. This is a kindness akin to not walking in the dirt your mother is sweeping up. If you push a change while the build is broken, the person fixing the build will have yet another update/build/test cycle on his hands before he can push his fix to the server. Don't punish the volunteer by pushing your changes. Wait, pull, merge, retest.

We have installed annunciators for teams. Sometimes they are flashing lights, sometimes a glowing orb, sometimes speakers playing a particular noise, sometimes it's just a person standing up and yelling that the build is down. Usually there is some electronic communication (jabber message or email) as well.

Why do we all need to know that the build is broken, and how long it is broken? So that we can alter our behavior. Someone needs to jump in and fix the build quickly, and everyone else needs to let them or help them. By leaving the build broken, continuing to build and push code as always, or pushing additional errors into the build, we are just getting in the way of the team.

Build annunciators should let you know when you need to get out of the way. They don't have to be piercing and shrill or overly bright, but they need to keep the team aware that the build is not "green."

It's not just a good idea... well, actually it is.

Pycon: Examples of Atrocity in Python Programming

2011-09-16T10:37:00.000-07:00

A nice discussion about things that should not be done in Python code, but frequently are.Nice mention of Clean Code's naming rules (I'm a proud daddy).

Ambient Annunciators

2011-09-14T17:40:00.000-07:00

Jim Hood (of Pillar Technology) and I just installed our first ever "ambient annunciator" to announce our build's breakage. Well, technically our first two. What it does is watch for a build to fail in Jenkins, then start playing a series of randomly-selected choices from our assortment of spooky public domain sound files. Some are musical interludes, some are animal sounds, some are just weird.

Annunciator #2 video, woofer, and R/L speakers.

Our intention is that these sounds, playing through a decent set of speakers, will create an atmosphere of something being "not quite right." With both systems playing test noises, it was a tad eerie. You really felt that there was something different about the space.

It is a bit more subtle than flashing lights, and we're hoping this will be an advantage. Developers will know the build is broken, and will have incentive to get the space back to normal (it is a little annoying) but will still be able to have conversations and won't get headaches associated with flashing lights.

How Do Scrum Masters Know?

2011-09-13T19:29:00.000-07:00

How do Scrum Masters Know?

This time the question is how the scrum masters know if they're doing a good job. They answered with this short list of feedback mechanisms.

Scrum of Scrums
Changes embodied in team behavior.
Retrospectives
Status of Kanban boards
Things missed

Overall, not a bad list. Your thoughts?

Learning from bad examples

2011-09-13T05:53:00.000-07:00

I saw this in a python tutorial today:


if os.path.exists("/tmp/uPlayer"):
   f = open("/tmp/uPlayer/STATUS", "w")
   f.write("IDLE")
   f.close
else:
   os.mkdir("/tmp/uPlayer")
   f = open("/tmp/uPlayer/STATUS", "w")
   f.write("IDLE")
   f.close

Really, now? We start by duplicating the whole open/write thing in order to create a directory? Maybe one of the problems people have with clean coding is that their examples are poor. If you write, it behooves you to write refrigerator code.

Not to mention that close is a function, so it needs parentheses. This code doesn't even do what it thinks it is doing. It's closing the file when f goes out of scope, not when we reference the f.close bound method.

It makes me sad for the children.

Scrum Master Duties

2011-09-12T11:51:00.000-07:00

This is the result from asking a team of scrum masters what their duties entail.

What do you think?

You Cannot Possibly Do TDD after Coding

2011-09-06T07:29:00.000-07:00

Just for the record: it is flat out impossible to "do the tdd" after the code is finished. This is just a matter of definition.

You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip.

In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way.

In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating.

If tests were product, then it would make no difference whether you do them first or last, and redundancy would be silly and worth avoiding.

If tests are rightfully seen as process, then redundancy is "coherence" and not worth avoiding. It helps us move forward.

The biggest problem with TDD is that if you're not doing the process, then the product (tests) don't make sense.

Hate TDD? Then there's a good chance you're not actually doing it.

Poop: The Refactoring Method

2011-08-29T18:14:00.000-07:00

I developed an quirky technique for dealing with the intermediate states of a refactoring. I call it the "poop" method (no biological metaphor implied). This method is far less controversial than one might suspect, but it is mildly unsettling.

I find myself working in a legacy code base. Refactoring requires me to take several small steps, each of which leaves a sub-optimal intermediate state. I decide to mark the code with some kind of comment that will indicate that the work there is incomplete.

It needs to be a word that doesn't normally appear in code, and which is clearly and obviously undesirable. If I put TODO, it will either get lost in the other TODOs left by well-intentioned people, or else will be stopped by a lint tool that takes such things seriously. Most obscenities would also be a little too likely to be duplicated by someone having a bad day.

My marker comment should not be something so obscene that it will offend or embarrass myself or my reviewers. Something common in baby-talk and yet biologically insensitive will work. I add a comment that says merely "poop." The fact of the comment being in my code creates a mild sense of uneasiness. After all, I don't want my colleagues finding it in production code.

As I finish my refactoring, I do a global search. Sure enough, the word only appears where I've written it in as a marker. As long as I clean up the code and remove the markers, nobody will find a "poop" in my code.

Actually, once my friend George and I left a "poop" in our code. Our coworkers found it. It was easy to tell we'd been caught because the pair looking at the code were laughing and asking why it would say that. It was a little reminder that all was not complete and tidy in our little world. We immediately fixed the code and removed the comment.

I have also used this as an indicator that I need to rename a method. If I don't know what to call a method or test initially, the word 'poop' reminds me that I need to revisit that code and determine why it is hard to name. Usually poor naming is a sign of poor design; well-designed components seem to practically name themselves.

Maybe you object to the word, but that's okay. The value of the poop method is ensuring you will be uneasy in the presence of unfinished work. Come up with your own variation (be nice) and see how it changes your work habits.

Agile2011 Day 4

2011-08-12T11:11:00.000-07:00

This was a wonderful, long, crazy day.

I woke up with a meditation on my mind. I was feeling calm, happy, centered. Morning routine was a breeze, and the walking route to the conference hotel is much more comfortable than the old one.

I spent a lot of time in coaches' corner again. I met some really nice people and had some great talks. I learned the "S.C.A.R.F." acronym and how to use it. I saw old friends. I met new friends.

The Grand American hotel is a wonderful conference hotel. It is comfortable, attractive, and divides into smaller areas nicely. The staff are ninjas, keeping the place clean and preparing for all the events and reconfigurations quickly and quietly. In fact, if you turn your back on your soda, it may totally disappear. James Grenning gave me a glass emblazoned with his book cover, and I had to guard it carefully lest it be swept away by cleaning ninjas. They are so quiet, polite, and efficient that one can never be annoyed with them. They are all superheroes.

I saw the few remaining Agile In A Flash cards (all sold out by end of day) and the three signed copies in the auction (also gone now). This has been a good week for us as authors, and there are new connections and new initiatives that have opened up to us because of Agile In A flash. It is all the more satisfying because the idea was so unusual and only Pragmatic Programmers understood what we were up to. I had a good time talking with other authors, coaches, consultants. I fear to list them all, because I will not remember all of them, but will mention that I really enjoyed chatting with Diana Larsen who I just met. She's invited me to a greater participation in some work at the Agile Alliance fringe and with other professional coaches like myself (perhaps better).

I was sad to see that my Industrial Logic colleague, Bill Wake, was scheduled give a talk on breaking down stories at 3:30, the same time as my Agile Apologetic talk. Then I found that my coauthor, Jeff Langr was scheduled to give his talk about whether to buy agile tools at the same time. My talk was small but we were engaged and attendees seemed to have a good time. Jeff's and Bill's were better attended, and I hear they were quite good. I suspect my lightning talk on Tuesday will the be one most likely remembered.

When I was done in Coaches' Corner I made it outside to see the freerunners, and was in a cloud of people (new friends and old) which was swept into the grand ballroom. Matt Barcomb and I appropriated an empty table, which soon became the "cool table" as we crunched together to allow more people to join. Lean Dog brethren joined us and entertained us. We watched a trampoline team do arial skiing and arial gymnastics and arial snowboarding. They were amazing olympic athletes, and one was even a contestant in American Ninja Warrior (obstacle course game show). The final scheduled entertainment was a band playing classics old and new, but they were sadly plagued with sound problems.

Following the scheduled entertainment I was invited to a room party which included many recognized great people of the Agile community and many sharp newcomers. Bonnie introduced us to fire spinning via two led-light green balls on chains, which stood in the place of actual fire. We took turns being schooled in elementary moves and it was a good time. I also had time to argue with Bryan Beachum. I talked with Diana and George and Jeff about the possibilities of helping to create cirriculum, and talked over general coaching stuff with James Shore. It was a really great time, but lasted longer into the evening/morning than I'm accustomed.

I've new friends and new ideas, and so ended day 4.

Free, Cheap, Scheduled: retrospective technique

2011-08-11T09:01:00.000-07:00

I was telling Esther Derby about a little trick I worked out some time ago at one of my clients. The retrospectives had gone stale, with team members offering the same "we should..." list iteration after iteration. I suspected that they didn't feel that they really had the authority or permission to change their process for the better.

I had a good relationship with the CIO and wandered into his office.

I said, "we have some changes we want to make, and they won't really cost any money or affect other departments, and I just wondered if you think it would be okay to do them." The CIO looked at me incredulously, "Of course. That's a silly question to ask."

"Alright, then there is this other change. It might take a few man days out of each iteration, but it will be helpful for the team. Would that be okay?" He sighed, "If it's a few man days per iteration, we can afford that. Go ahead and take that time. You don't need my permission for that."

I paused a few seconds for effect. "We also have recognized some tough changes we need to make. They might take a few man weeks out of an iteration. Would those be okay?"

This time I got a few seconds of silence in return. "Tim, we can do that kind of change, but we have to schedule it. We can't put releases at risk, and we have promises to fulfill, so we just need to make sure we do them at the right time. They need to be worth it, but we can do that."

I thanked the CIO and wandered back to my team in time for the retrospective. The team identified many of the same problems, and proposed the same solutions they hadn't worked on the last few times. I went up to the flip chart and divided it into three sections called "Free", "Cheap", and "Scheduled." I explained that these categories had been approved by the CIO and we should begin making changes immediately after the retro. I asked them to pick things they really wanted to do.

The team put changes into the correct buckets, and we picked the ones they felt that they had the energy to work on. The scrum master took the task of moving the "scheduled" items into the schedule, the rest we started on immediately.

If your team is having trouble believing that they really have permission to "spend money" making changes to they way they work, maybe you will find this technique useful.

Agile2011 Day 3

2011-08-10T22:50:00.000-07:00

I just can't get it in my head this was Wednesday. I'm very tired. I'm an introvert, you know, and we draw energy from alone time or time with a small number of close friends. Being in rooms with hundreds of people most of the time is really work. On the other hand, I get energy from my work, and spent a lot of time talking about work.

I spent the morning with Michelle from NavTeq, talking about people, processes, transitions, and strategies for making other people more successful. I'd re-met a fellow from NavTeq after my talk on pairing yesterday, so it's cool that I'm seeing so many of my Chicago cousins. I'm hoping to see more of them in the future.

I attended a tool demo later, but I didn't realize it was a testing tool for C#. I thought it was going to be a talk on how to bring testers and coders closer together and blur the lines between them. I left disappointed, but on the way out met a nice fellow who is a new scrum master. We chatted until time for lunch.

Lunch I had with a number of my Deere friends (heh). Deere sent a lot of delegates to this conference, which really speaks to their level of management support. Thanks to the John Deere executives who made it possible for all these good people to come, absorb, learn, and converse with the constellation of Agile dignitaries here. May they pay you back tenfold in fresh learning and new techniques.

After lunch I went to GeePaw Hill's talk on geek leadership. I learned some useful techniques that I will put into practice in the near future. It's good to have smart friends.

Later I ended up mostly hanging out, populating coaches' corner, and eating food. I saw a lot of good people. I met people who have been following my blogs (always a kick for a blogger) and showed off the card deck. I also had some good responses to my talk yesterday "will pair programming ruin my company."

Today there was an announcement that Industrial Logic and Version One have a strategic agreement. Announcements focus on V1 market our eLearning as part of their offerings. I have new brothers.

Tomorrow Jeff Langr and I will be pushing the limits of acceptable behavior in our individual talks. He has a talk on "the only agile tools you really need" (a must-see, controversy-stirring feast of common sense) and I will present "the fundamental agile apologetic." Actually, I only hope it will be a fundamental apologetic, but I have decided to allow the talk to go in new directions if need be. Teaching, learning -- I'll be doing at least one of the two.

It's hard to say what tomorrow will bring, but it should be interesting at least.

Pairing Styles

2011-08-10T13:06:00.000-07:00

Overall, pair programming isn't as controversial as you've heard. It depends on your styles of pairing. Some styles of pairing are very common, even among non-agile teams. They tend to be episodic, and last just long enough to get or give some aid. The good news is that they work. If a team views pairing with trepidation, these are common, non-threatening forms to start with:

Rescue Pairing
Training Pairing
Brainstorming
Experimenter/Researcher

Others are such bad ideas that they are rightfully avoided by all sane teams I've seen so far. If you are considering pairing, and a team member balks, you should see if their mental model of pairing matches one of these styles. I suspect a team should decide that these styles will never be practiced personally, or tolerated within the team's pod. You have my blessings to object to pairing if "pairing" means:

Worker/Rester
Worker/Watcher
Master/Slave
Bully/Victim
Writer/Critic
Ball-and-chain pair marriage

And then there is the form of pairing that matters most.

Peer pairing

Peer pairing is about two people who know what they are doing, who have skills, who are not stuck or lost or confused, designing and implementing ideas as fast as they can. A peer pair constantly vets ideas, tries alternatives, detects surprising failure modes, revises plans, teaches, learns, experiments, laughs, tests, commiserates, and grows together. At least for a few great, exciting, exhausting hours.

The problem with peer pairing is that to the observer it might seem like rescue pairing or training. If you are always being trained or always being rescued, then you might seem like you're not much of a programmer. In this case, seeming is the enemy of being. A team may be so concerned about seeming competent by not pairing that they don't increase their competence by peer pairing. I suggest that this is a human foible, and we have to recognize.

When we talk about pair programming, we usually intend peer pairing (and the other good types at the top of the list), but people often hear us as meaning one or more of the bad types in the middle.

I hope to rephrase the question. When you tell me you "don't believe in pair programming" then I hope to ask you about the pair programming you object to. Chances are I will feel the same way, and with that out of the way we can talk about the kinds of pairings we might actually try.

Agile2011 Day 2

2011-08-10T12:30:00.000-07:00

A lot of today was spent in the Coaches' Corner, where several more convention-goers were served with expert advice.

I spent a chunk of my "alone time" today working on my "Agile Fundamental Apologetic" talk for Thursday (Fringe stage). I hope to establish that if we weren't doing agile, we would have to do something very like it. I even got to pair on some of the slides, which was a great time.

Jeff was finalizing his Test Abstraction talk (based on our Agile In A Flash card), in which he showed some poorly-composed Fitnesse tests, and some much more well-composed, abstract versions of the same test. It was practical and useful. I think he opened testers' eyes to new possibilities, and that 7 minutes talk will have reverberations in many places.

After Jeff's talk was my own. Mine was titled "Will Pair Programming Ruin My Company?" in which I answered a few questions I've heard from managers over the years. Given how much controversy and resistance arise over this crucial practice, I think the talk was well-timed. It was also well-received. I had a great room, appreciative and inquisitive and thoughtful.

I also did a very small, personal session on my Agile Coaching Metaprocess. Actually, it was a conversation with two people, one of which has heard it a million times already. It wasn't a box office smash, but I've given the same talk with others through the week.

Quite a bit of time was spend in talks about consortiums, guilds, and interest groups. There are many great ideas bubbling under the surface of the Agile Alliance umbrella. I spent the evening (late into the evening) having supper with an impressive group of agile luminaries. I know I was impressed. We talked about providing programmers with an agile education. Of course, as an Industrial Logic member this was of interest, but it has also been a long-term interest of mine as an agile coach. Thanks to Matt Barcomb for putting the evening together.

Agile2011 Day 1

2011-08-08T20:35:00.000-07:00

This has been a very good day. I was able to staff the Coaches' Corner and visit with other coaches when we weren't engaged with convention-goers. I enjoy the interaction, though I'm admittedly an introvert.

Jeff Langr is here, and we were able to talk about many things and even promote the Agile In A Flash deck. Three copies went to the live aid silent auction.

I was looking dapper in my blue Industrial Logic shirt and sharing the Agile love and coaching philosophy with people who were interested. We talked about measurement, e-learning, and raising self-coaching teams. We talked about business and busyness and listened to many stories. I was also given a Lean Dog fuzzy hat, which I sometimes wore when I wasn't feeling to warm or was unconcerned about creating mental ambiguity about my situation.

This place is a who's who of object mentor alumni. All my old friends have new gigs and new ideas and it's wonderful to see them all.

The ice breaker is over, and I'm about to wander off to join some friends, but I wanted to mention to any attendees that I'm speaking tomorrow, a lightning talk on "will pair programming ruin my company." Teaser: it just might.

Good night to all.

Leadership

2011-08-01T05:22:00.000-07:00

I'm doing some reading and some experiencing, keeping my eyes open for the concept of leadership.

One can see leadership as a combination of visibility and confidence. This seems to work out pretty well, as an observation in arrears. Leaders who are successful often have high visibility and make decisions with a high confidence that things will work out well.

When leadership works, I see it as the leader understanding the team and promoting the team by improving the teams alignment with the hierarchy of the company and its customers, making use of the team's strengths, and helping . Such a path seems to grow confidence, and the success gives visibility to the team and its leaders. This is the slow, steady path.

I see some leaders succeed by other means, some seeming rather virtuous and others less so. I'm particularly critical of those who see leadership as wresting authority from others though political games and social manipulation. Such leaders may actually inspire confidence, since the leader is seen as growing in influence and respect. It may bring such a leader up the hierarchy quickly, but will also tend to give the leader a shaky support base. For such a person, support is something comes from the hierarchy and the role of follower must be inflicted on competitors. It is a quick path, but the innate self-centeredness competitiveness may result in a very unpopular position and many enemies.

A juvenile view of leadership is that it is about being seen and telling others what to do; a starring role with the hierarchy and team as supporting cast. This seldom translates into the kind of leadership any organization really needs, but is quite reasonable. After all, a leader is visible and has authority.

I'm leaning toward the idea that he leader I want to be is the guy who prepares the way for the team, aligns them with the hierarchy and customers, and looks for ways to help them achieve their goals more fluently.

I'm still most motivated by our B.E.S.T. leadership card. I find it sums up all the best leaders I've known.

Fun with Squish and Python

2011-07-18T19:25:00.000-07:00

At my current gig, we are using Squish to test a new QT-based GUI app. It's been a hoot. Squish is frameworks, eclipse, and python. Oh, yes, squishy yummy python.

To start with, we used the QT interface to start measuring and checking UI widgets. There are some very exacting standards on color, placement, and size of visual elements and squish is helping get the specs converted to a runnable form. This was my original goal for the tool.

The team was recording tests post-facto, so I jumped in and we build up some libraries and syntax sugar so that it's easy to build the tests before the code. Hopefully we'll see a lot less code being returned over minutae now that programmers can run the specifications while they're building the code.

The next step was to automate to the simulators that sit under the app. This was delivered last week, and we added some more sweet syntactic sugar to make it easy to script simulators in the gui tests. It's still not lightning-fast, but it does the job. There was quite the buzz about it, as it enables the company to do a lot of end-to-end testing and demonstration.

Squish is an interesting environment, and they did a few things I didn't care for like adding an 'object' module which hides the built-in type. I've learned to work around some of the gotchas so those don't bother me too much. It was just an interesting learning experience.

What I love is that the environment allows me (a developer) to provide rather powerful support to the testers on the team, and allows them to do quite a bit of programming in a way that it resembles simple data tables and English. Those who've stopped by for the demos have remarked that the tests read clearly enough that they can understand and critique them.

Our next trick will be using Squish and PIL to test some aspects of UI rendering that are not really feasible in native Squish and QT. This has been a fun trip so far, and we'll see where it takes us next.

I have mixed thoughts about gui testing. It is slow and requires you to stand up a complete image (with all that mean in setup and teardown). It scales better than manual testing, but can have a certain brittleness that manual testing to textual scripts does not. Even so, Squish does a good job and covers our platforms, so I think I'll stay with it.

Microtesting Python Album

2011-06-28T08:20:00.000-07:00

I'm working with Industrial Logic's newest Python album on microtesting (not yet released) and was lucky enough to get to test out the automated critique.

So the way this eLearning works is that you download a problem to work on, and you're given tasks to perform. In this case, it's all about writing microtests for some simple python code. When you finish, you upload your results and an automated critique system digs through the code and gives you ratings and pointers. This is rather like having a mentor sitting with you, reviewing the code.

I tell people that the eLearning here is something like they've never seen, but people think I'm marketing or something. Today I have a story for you:

Yesterday I made a mistake and the automated critique busted me. The mistake was one where I constructed an object incorrectly and invalidated the premise of the test, yet I did this in such a way that the test passed for the wrong reason. I was feeling so sure I'd done it correctly that I thought the critique was wrong. I pasted a copy of the test into my error report before I realized I was in the wrong.

The coolness didn't stop there, though. Through all of this, my tests looked nothing like the tests that were presented in the course material. The eLearning system allowed for my stylistic differences only flagged the actual error in my code.

Slightly humbled, I corrected my test and uploaded it again for analysis. This time I was 100%. The online course gave me advice and allowed me to try again.

When it comes to developing skills, anyone in the business will tell you that guided experience is the best teacher, but I've never seen a system guide my skill development like this one does. Today I found out there's even more guiding intelligence on the way. Watch this space for details.

Short Reach Revived

2011-06-21T16:38:00.000-07:00

This first appeared on the Object Mentor blog in 2007, but I had to get a cached copy from google to reread it. I'm reviving it here so we don't lose it forever. I think it is still carries a valid point, and I would like to revisit it in the near future.

Short Reach
Posted by tottinger on Monday, April 23, 2007

I’m always trying to find newer, better, shorter, more powerful ways to explain what Agile is about. I suppose I’m some kind of obsessive about expressive power and economy.

Finally I decided that Agile, as I understand it today, is about the short reach.

It seems to me that all of the agile practices are about shortening our reach, the distance in time-and-space that one leaves an assumption, decision, or line of code untested and unconfirmed. All the practices seem to follow this one rule.

The customer/analyst is keep in the same room, in the same short reach.
We feed back the iterations to the customer/analyst so that his every decision has a shorter reach.
We do iterations to ensure our planning has short reach.
We keep our teammates very close, in the same room, so that it’s a shorter reach to them.
The test is written first, so that implementation has shorter feedback on correctness.
We compile/test frequently because our code time should have a short reach.
We pair so that our code is instantly vetted through a peer. We don’t pile it up and review it after the tests pass.
Our planning is based on “yesterday’s weather”, data collected a very short time ago.
We don’t plan the team structure and the assignments, we self-organize so that tasks are waiting for the shortest time possible.
We talk face-to-face, not across chat and email and official company documents.
Tell-dont-ask and the Law of Demeter guide us in keeping the reach of our objects very short.
We use unit tests to exercise a class directly, and we isolate with mocks to reduce the reach of our tests through the system.
Shared code ownership means that the guy sitting behind your keyboard has all the permission he needs to do excellent work, even if it impacts existing design.
Test-first development means that the guy who makes a change knows very quickly whether his change is safe or not. He doesn’t have to wait until the week before integration when the “real” tests are run.

Where does Agile run into logistical or operational difficulties? Wherever a long reach is required or imposed. Where an organization chooses to continue in waterfall-style management, where the team is distributed among managers with appointed “point of contact” and “official channels”, and where the developers are not placed in a common work area agility is very difficult.

I’m not saying that agile techniques can’t work for large companies, but that is an area where a lot of experts are trying (maybe succeeding) to extend the agile techniques and where the average “agilist” finds challenges. When it works, it is almost certain it will be because someone has found a way to shorten the reach of the teams so that all they need to know is never more than a few seconds or minutes away.

At least that’s my half-baked observation of the day. Let me know if I’m wrong here. Or if I’m more right than I think I am.

Get Back On Track

2011-05-19T08:30:00.000-07:00

There are hard times, and things can pile up. Don't wallow. Don't spend time trying to feel better. Try to get back on track.

Things can get you down, so you need to borrow energy from others. Try user groups, pairing, friends, fun programming exercises.
Quit thinking you should be able to do new things all alone. Getting up to speed is always dicey, and best done with someone who is already up to speed.
If problems are short-term, like a flooded basement, broken lawnmower, minor health troubles, a child's academic crisis, take time for them so you can get back on track sooner. Get it over with.
If the problem is long-term, start building up the emotional muscle to deal with it, which means getting on with life despite the long-term trouble and trying to cope with whatever "long-term trouble" is going to mean.
When you're not feeling particularly confident (ie depressed) don't get caught up in large meta-issues. Keep your focus on smaller things you can achieve. Build a quick triage rule to help determine what you can deal with right now. Big issues will stop you dead in your tracks.
Get UNSTUCK.
Don't waste time, find new uses for it.

GOing to Software Craftsmanship McHenry County

2011-05-17T19:41:00.000-07:00

I was a little overwhelmed with how slowly I'm absorbing information, especially while dealing with household issues (like gas fumes from garage and flooding in basement) on top of trying to do something worthwhile (ANYthing) at work. It's just the way life comes at you sometimes.

My escape for the night was running out to a meeting of Software Craftsmenship McHenry County (SCMC). This was my second meeting ever. I mis-timed the trip and ended up a few minutes behind the start of Steven Degutis' slide show. Pizza and pop were in good supply though, so I settled in and enjoyed a presentation on the language Go.

Go is a strange little language, but a lot of fun. We had a quick presentation, thankfully mostly consisting of code examples, and then were given time to dive in. Even though I'd been kind of blue and a little angry all day, I was soon laughing and having a great time while we tried to find ways to clutter a perfectly simple little problem's solution with threads and channels and anonymous functions. It was almost a reverse kata, where the goal was to be as overly sophisticated and absurd as possible.

In the course of making and fixing mistakes, we learned a little, shared a little, and bonded over the absurd joy of it. I left in a much better mood than I came, and in that joyful mood I'm writing this blog entry.

I'm reminded again that when I stagnate, it's because I allow myself to feel the enormity of the world of things I don't know and to feel alone in the face of it. I find again that the answer is to join into a little community; pairing or comparing, learning or teaching, playing or working. Sometimes there is a lot of release in having a silly little problem and some crazy peers to share it with.

If you are in the far NW burbs and like to program or like to learn about programming, give SCMC a chance. It's a group of people of varying ages and experiences where you can feel unashamed and enjoy programming education as a harmless pastime. Heck, you might even learn something useful.

Chicago Code Camp 2011

2011-05-16T06:50:00.000-07:00

I spent the day at Chicago Code Camp. It's a good thing because it's a pretty pure conference for programmers. It's all run by volunteers, all free, all in one day, all short talks (1 hour).

CLC had good wifi, plenty of space. Actually, one of the problems we had was finding out where the registration desk and refreshments were "hidden" in the huge Technology Building. I came in a different door than organizers expected, as did dozens of us who were found wandering the halls. We like calling that the "mandatory fitness segment."

One of the things that is particularly good is that you can quickly guage where you stand with the community, what people want to hear about, and what people want to talk about.

The first presentation I attended was on refactoring javascript, and programmers were rapt. They wanted to know about testing and test frameworks, how to do the refactoring steps, and how to incorporate the tests in in CI. The introductory topics included refactoring, unit testing, and dealing emotionally with 'tangled code'. I sometimes felt that the presenter was quoting from things I have written about naming and the like, but I think that mostly he was pulling from the same sources as Jeff and I did with agile in a flash. I picked on the presenter a little, and gave him a deck of Agile In A Flash cards as a kind of apology. I hope he likes them.

The second talk was on git. I was surprised how few people knew about git and how to use it. There were more microsofters there than I expected, and they were using VSS and the m$ team server stuff, subversion, and cvs. There were few of us who used git, bzr, hg. I suppose that means we need to talk and write and present more on agile version control, or it means we're far enough ahead of the parade taht nobody is really interested. Folks in the group would get confused and walk out.

The third session I had planned to listen to either Michael Norton (@docondev), but against my earlier plans I ended up checking out the talk on WebSockets and Pusher with Damien Tanner (@dctanner) and Dave Hoover (@redsquirrel). Damien was a surprise guest. It was handy that the author of the pusher shows up to join Dave's talk. One feature of the talk was the audience's impatience to see code. God bless the Code Camp audience. Questions about performance were not long in coming.

The latter part of the day was spent in Clojure with Micah Martin (a face from my old Object Mentor days) and Gnu Smalltalk with Steve Kim. Both were enjoyable. I am not a Clojure nor a Smalltalk guy, but I was able to keep up and enjoy both the presentation and the conversation.

A few quick observations:
* People were using vim, textmate, and emacs; they were not using IDEs much
* Macs are platform of choice even though this conference series is known for windows devs.
* The ratio of sexes was far skewed to the male side.
* The age mix was much more even. There were probably as many 50+ as teens, and 40s as 20s.
* Even with a rep for having microsoft developers, there were many platform-agnostic language talks.
* Organizers did a very good job for a free (sponsor-supported) conference.
* CLC in Greyslake, IL has a great facility.

Agile Coaching Stories

2011-05-10T13:18:00.000-07:00

This is your turn to brag, complain, and post observations.

If you were on an agile transition, it is likely that your company hired a coach. The coach may have been awesome, may have been horrible, and may even have been me.

I'm interested in your stories. Were you pleased? Disappointed? Did you learn things you didn't even know you needed to learn? What was the long-term impact on the coach your team, your skillset, or your company?

Adhesion Example

2011-05-07T17:12:00.000-07:00

A while back, Glenn Vanderburg wrote an article about software cohesion v. software adhesion. Today I got a great example of adhesion.

We are starting our second year in the house. It is a quirky house and I know it was managed by people who were self-reliant, so there are always some odd surprises here and there. It kind of reminds me of a legacy code base, because the product (house) is pretty good, and mostly meets our needs and many of our desires. We got it because we liked it and because it fit our price range, and it helps us with other goals (close to train station, 15 minutes from church, nearer friends, nearer my son's school, etc).

Today I needed to change a bulb in the upstairs shower for the first time. I was stymied at first, because the cover didn't have any visible way to remove it. The glass cover didn't have a catch, didn't screw off, didn't have a release detent that I could twist to release, nothing. I finally decided that the outer plastic ring must drop down, but it didn't want to.

The cover had been caulked and painted to the ceiling, rendering the incandescent 70-watt bulb a permanent fixture of the house. Think about that for a minute. In order to change a lightbulb, I have to tear into the ceiling of the shower. When I pulled down the outer ring, I found it was indeed made to pull down and release in order to change light bulbs, but I suppose the former owners were in a hurry when they put it in.

The ceiling was cut a little larger than it needed to be for the fixture. With the ring up, it leaves a little opening here and there. To fix that, it looks like they just glued the hole with caulk and then painted it over so it didn't look so bad. It seemed fine when I bought the place.

It sounds like a particularly bad design to me, because in order to solve one problem (not enough light in the shower) I have cause and then fix another one (holes in the ceiling). It is more disturbing to me because I'm not skilled in drywall repair or showers. I'm going to have to ask for help now (another problem for me) to make sure I fix this in a way that doesn't cause more trouble in the future.

It didn't have to be that way.

This house really is organic in the way that legacy code is organic: things just sort of become the way they are through minimal effort and short-term problem-solving. Nobody designed the house to have a hole in the ceiling or a permanent lightbulb, but that's how it is. It's is as if "crappy" was a feature, and it probably sounded like a good cost/benefit tradeoff at the time. After all, a lightbulb over the shower should last for years, and caulking and painting are not hard to do.

I am not going to obsess over the issue, and I've got the bulb changed, but I am going to put in a fix that makes the lightbulb a supply instead of a permanent fixture. I'm putting in a florescent bulb this time, and it may last a long time, but the next time we need to make a change it won't be a big hassle. It will be easy. I don't want to become accustomed to doing unsatisfying hacks in my house.

Organizing Stepwise Considered Harmful

2011-05-06T15:07:00.000-07:00

There are different ways to organize repeating code.

One is step-wise, in which near-identical steps are stacked together:

button1 = QPushButton('Button 1')
button2 = QPushButton('Button 2')

button1.clicked.connect(lambda: self.on_button(1))
button2.clicked.connect(lambda: self.on_button(2))

layout.addWidget(button1)
layout.addWidget(button2)

The other is subject-wise where the code for button1 is separated from the code for button2:

button1 = QPushButton('Button 1')
button1.clicked.connect(lambda: self.on_button(1))
layout.addWidget(button1)

button2 = QPushButton('Button 2')
button2.clicked.connect(lambda: self.on_button(2))
layout.addWidget(button2)

The step-wise version makes the code repetition more obvious, but the novice code-cleaner is likely to extract constants to variables and leave it alone. In the second case (subject-wise) the code-cleaner is more likely to realize that there is a multiple-step process that can be extracted to a function, leaving something more like:

CreateButtonWithAction(layout, 'Button 1', lambda: self.on_button(1))

CreateButtonWithAction(layout, 'Button 2', lambda: self.on_button(2))

At this point it becomes obvious that the only difference in the two lines is two constant values, which might suggest more ways to simplify the code. The astute observer will also recognize that the first parameter in the call is always the layout class, which suggests a wrapper class or "move method" which will in turn result in a more well-developed abstraction. Well-developed abstractions make writing client code easier and quicker.

layout.CreateButtonWithAction('Button 1', lambda: self.on_button(1))

layout.CreateButtonWithAction('Button 2', lambda: self.on_button(2))

I'm not saying that this is the ultimate, optimal form for the code to take. I'm only saying that once it is organized subject-wise, the refactoring starts to flow very naturally.

Why Not?

2011-05-03T07:43:00.000-07:00

I have officially declared 2011 the year of "Why not?"

I don't mean "why not" in the sense of doing anything possible without thinking about it. I'm actually thinking it is a good year to ask why we can't do things, or why we won't do things, because it is interesting to understand the forces behind it.

Take personal development. Who among us has done all they planned to do regarding new tech, new languages, projects to start, products to build in the past year? Who would not have benefitted from reading a book, doing some kata, learning a new language, or writing something new? And yet we do not.

Let's refuse to commit the Fundamental Attribution Error here, and not say "because they don't care" or "because they're lazy." A ton of information is available about improving a person's ability to program, or the number of platforms and tools they can program with, and yet most people don't reach beyond the level that is absolutely necessary for them to muddle through at work.

Why not?

Java's Greatest Hits And Misses

2011-04-21T08:53:00.000-07:00

If you were mentoring someone who is pretty new in java, you would surely tell them about JUnit and your favorite mocking framework and the language grammar. However, you know that Java is a culture and a history and a spoken language as much as a written language. You would start talking about jakarta, or tomcat, or a DI, or a bean, or a war file, or eclipse workspaces and your apprentice would scratch his head and stammer. The truth of the matter is that the grammar isn't but 10% of what java programmers know.

Which projects would you have your student study in order to soak up the rich history, culture, and language of the java programmer? What are Java's greatest hits and misses?

"Managing" Velocity

2011-04-08T20:04:00.000-07:00

The term velocity is very well-chosen. It means speed in a certain direction, with the intention that it refers to the teams rate of travel toward a product release. I have suggested that velocity is just capacity and my intention was good and maybe even right in many ways. Velocity is the practical measure of our capacity being applied toward the completion of a release. The term still stands superior to my older suggestion.
Lets start with the definition that velocity is the speed of progress in a given direction.

The direction part gets missed. People (including my slightly younger self) want to do things like track bugs ("failure demand") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really. We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity down; that's what velocity measurement is for. If bugs are driving velocity down, wrap a bunch of tests around your most volatile or hottest code and clean it up. Watch what happens to velocity after an iteration or two.

Some think that when I don't offer partial credit or bug points or meeting points it is because I don't care about velocity, but it is actually because I care too much about it to pollute it. Done well, velocity is the speed toward a goal.

The fact that we use words like "velocity" and "sprint" makes it sound like we are in a race. Indeed, one can see the goal as one of releasing as quickly as possible, and we can all applaud that goal. What, then, is the ideal velocity of a team? Infinity? Isn't faster always better? It feels wrong to have a velocity "dip" and teams will go to great lengths (often the wrong ones) to shore up their numbers.

Too often a team will turn to chronic overtime to fix the velocity problem. This is a huge mistake. Velocity is the amount of capacity spent in the direction of completing a release, and attempting to inflate capacity does not solve the problem. In fact, overtime just leads to bigger, more unpredictable problems. Agile method are supposed to uncover problems, so just be transparent and let velocity become useful.

Instead, we should actually increase the amount of capacity toward a goal by eliminating wasteful practices, wait states, wasted efforts. We should increase our capacity by making the code more workable and the team more skillful. We might improve our velocity quite a bit if we do it in ways that make our future easier than our past has been. The work might get easier and more pleasant over time instead of being a never-ending "trudge in the sludge."

This leaves us with velocity as the rate progress at constant, sustainable pace toward a goal.

Even so, velocity will fluctuate. You don't have the same capacity to expend every week. Maybe you're tired from overtime, or life at home is requiring more attention. Maybe it is because estimates are imprecise or because each iteration has troubles of its own. Maybe exciting new features need to be vetted by the team. Maybe a member gets pulled out for sales support. There could be an illness or a birth. Don't bother trying to force velocity. It will stabilize well enough if you don't mistreat it. Then you can separate normal variation from special variation and can monitor the trends over time

If velocity is going to have some normal variation, then wise managers know to plan with a little slack. If you run your team at 100% capacity, there is no reserve to help with technical or requirement issues, no way to allow a programmer to participate in the proposal process or vet sales' ideas for new features. One dental appointment or sudden bout of the stomach flu would ruin your plans of success. Too much good content is written for me to try to do this topic justice, so I'll spare you.

Velocity should be a measure of actual, non-waste progress toward a goal at a sustainable pace. For planning, velocity is the same but with a prudent amount of slack figured in based on the team's history of normal variation.

This is a lot of opinion and some link-mongering, but I only promised to write up a quick summary of my thoughts. I've done my part. According to the deal on Twitter, it's your turn to start beating on it so we both may learn something from the exchange.

Cheers.

Overtime on Agile Teams?

2011-04-04T15:23:00.000-07:00

My recent article on Overtime and Agile Teams was accepted and published in Software Quality Connection. Here are a few statements extracted from the article to summarize its direction:

"Predicating project plans on constant overtime is a bad idea."
"Agile requires whole people."
"Overtime is for bumps."
"You have to ask if your overtime is hiding problems instead of exposing them so that the team can solve them."

My OSS Software (inventory)

2011-04-04T09:06:00.000-07:00

What I need to replace when I get the new machine:

Chrome, Firefox, Midori: Browsers - usually two or more open at one time.
gvim, git, svn, poor ole' cvs: Essentials for software dev, b/c I often have three or four bash sessions open.
Miro, Gpodder: audio and video subscribe/play - free video, audio, kept consistent.
FBReader, Calibre: ebook & magazine readers -- I need to move my ebook collection, too.
OpenShot, Arista transcoder, mencoder, Istanbul: video editing, transcoding, and screen capture
Inkscape, Gimp, F-Spot: svg drawing, image editing, image manager
OpenOffice: free office suite w/ word processor, drawing, spreadsheet, presentation
FreeMind: mind mapping
Skype, TeamViewer: remote pairing
Rhythmbox: music player and access to UbuntuOne DRM-free music store.
Eclipse: rare instances when I need to use an IDE (I don't do much Java).

Most of the stuff I do is with these. I am surprised that it's such a short list, but programming is mostly in gvim, using python (pip, etc) or a little ruby, and some fun stuff in bash. Not as many apps as I thought. An awful lot of what I do is "in the cloud" rather than local these days, and hopefully more if it will move that way.

Sell Me A Computer?

2011-04-01T18:23:00.000-07:00

I do everything as a geek would do it, because I am a geek. This extends to buying a computer. I'm picking out my next home-wherever-I-am now, and I'm wanting to ask questions that nobody answers. Here's what I'm about:

Does it come with a non-shiny screen? I don't know how "glare" ever became a feature.
If I'm just reading and editing text files, will the battery last all through a 6-hour flight?
How much battery life can I get if I'm programming in python with autonose running?
When I put Ubuntu on it, will it find drivers for everything? Video? Wifi? Camera?
Which extended function keys won't work in Linux?
Will the oversensitive touchpad register a mouse activity when I come within 1/2 inch of it? Can I shut it off?
How badly will I get burned if I put the laptop on my knees while compiling a .NET project?
Is there enough RAM for me to run my OS, a windows virtual box with VS.NET and resharper in it, a browser on the side?
Can I use it comfortably on a train or on an airplane, even if the inconsiderate jerk in front of me slams his seat back against my knees like usual?
How long is the fan going to last? Is it going to die after a measly 4 years like my previous two full-sized laptop computers?
How much does it suck battery when suspended? How much does it eat on reboot if hibernated?
Can I hook it up to digital video? HDMI?
How water-resistant is it? If I spill one drop into the keyboard, is it gone forever, or is there some hope?
How sturdy is the hinge? I've seen too many laptops gone forever when the hinge weakens.

I know that's not the normal set of questions, but that's why I'm so much fun to shop with.

I've had great luck with Thinkpads and my Asus EEE PC is just wonderful with Ubuntu. I don't have the battery life I want, but a guy makes compromises. We're pragmatists.

My only problems with the Asus EEE PC have been the oversensitive touchpad, lower battery life than desired (2 hours + with Ubuntu), smallish hard drive (160G), small RAM (1G originally), and being vga-only (later models solve this). For the money, I can heartily endorse these little netbooks. Actually, despite these problems, I've come to love the little beast. It's just underpowered for my needs now.

I'm thinking about a Thinkpad T410s, loaded with RAM, 500GB drive, and 9-cell battery. I'm betting it will come as close as anything to what I want.

I'm still considering a Mac, though. I don't like OS X as much as Ubuntu, but if it is solid and my windows VM runs okay, I bet I can comfort myself with a real *nix file system and a good bash shell. Last time I was frustrated by not having a great APT/YUM repositories (ports was not as good) and the whole issue of native app updates. Either each app checks for itself, or you have to go check for them and download new versions. On OS X, I had to do a lot more manual system management, and Windows was worse than that in addition to being slower and buggier.

On the other hand, OS/X had some great power management and ergonomics and the MBP had some really stellar hardware. It did work well, only crashing maybe twice in the year I had it (far better than windows, not as good as Ubuntu). The only thing I would consider superior about windows is its power management. My son's Asus EEE is identical to mine, but windows stretches the power use over a much greater period.

Well, unless someone talks me out of it, it will either be a MBP or a Thinkpad when I place my order. It will be either Ubuntu or OS/X and windows in a VM.

Fun times in Honeymoon Mode

2011-03-31T07:31:00.000-07:00

I started the new job at Industrial Logic. In addition to receiving online training from my peers here, I'm getting into the source code of our products (some cool stuff in there). Yesterday I got to exercise my google and stackoverflow skills as we dug into a windows-based product. My .NET work until now has been web, not native, so this was new territory for me and I had a great time.

In addition, I'm getting involved in contract work here and strategy. It's only day 4, and I'm feeling like I'm really a part of the team. You would not believe how much we are in contact even as remotes. I probably talk to my coworkers ("boss" included) much more often than you cubicle-dwellers do. I still get think-time alone, but I'm getting to know and enjoy people pretty well.

Enough of this, there's code waiting...

Industrial Logic

2011-03-24T17:45:00.000-07:00

Your agile otter has joined Industrial Logic. We have so much in common that it didn't make sense not to join forces. I will be neck deep in products, courseware, metrics, and all of the other work that makes them so cool. This will be like chocolate and peanut butter, friends. I can't wait to join all my new best friends!

Uncle Bob's Clean Code Video

2011-03-18T20:14:00.000-07:00

The latest Clean Coders video by Uncle Bob Martin covers Chapter 2 of the book Clean Code. This is a chapter that is near to my heart, since it bears my name and Uncle Bob even presents some flattering introductory material with a decidedly unflattering picture of me (all in good fun). The video is $12.00, but is quite well done and interesting.

The less entertaining version which was the source for the well-edited version in Clean code is still available, and has examples in Python rather than Java. Bob's presentation has some thoughts not included in my paper (and which I endorse). The paper is not a replacement for watching Bob's zany and entertaining video but it can give you some of the same material while you ponder spending your hard-earned ten-spot-and-change.

Make the Retrospective Effective

2011-03-16T06:25:00.000-07:00

With my last employer, we had noticed that our retrospectives were starting to lag in effectiveness and attendance. People felt like they were too busy delivering stories and solving problems to do anything substantial toward meeting retrospective goals. I knew that it wasn't the kind of company that would accept stalled improvement, yet developers were instinctively afraid to invest time.

To resolve the problem, I talked with the CIO. Our discussion ended up with this set of triage rules for retrospective follow-ups:

If it is free, just do it.

There is no reason to delay implementing some changes, including (but not limited to):

posting a graph,
composing a "top-ten" list,
swapping pairs more often,
trying pomodoro technique,
changing how stand-up meetings are performed,
making better use of QA, tech writing, or Customer resources
instituting changes to coding standard

There is no reason to delay this kind of work. The CIO told us he considered it our job to keep improving the team through reflection and experiment, or else he would have asked us to stop months earlier. Other behaviors developers were skittish about (refactoring, speeding the tests, getting legacy code under test) were considered part of the job but programmers were afraid of "losing" productivity to those tasks. Our enlightened management re-affirmed a commitment to quality work.

If it takes a couple of man days, just do it.

The team was surprised that they could peel off a member or a pair to do technical work that would improve the team. This allowed the team to take on tasks like improving the build system, metrics gathering, checking out new mocking libraries, solving version control process problems, performing global clean-ups like duplication removal, writing instructions on the team wiki. We were, in fact, not permitted to not do these things. We happily devoted a few man days per iteration to accelerating the team.

If it will take longer, we should talk about it

There were architectural changes, large legacy code reworks, and grand experiments that came up in the retrospectives. Some people were afraid to even mention something that might take *weeks* of developer time to complete. People were surprised to hear that management was not against such things, but merely wanted to be measured and cautious with goals, measurement, and timing. We did some large things, and we failed some grand changes (as one might suspect) but we didn't fail for lack of permission.

This triage system worked, and for the next several months we had items in all three categories.

No retrospective technique I've found will be able to single-handedly keep retrospectives fresh and vibrant and productive in perpetuity, but this one was useful to shake off a fear of lost productivity long enough to get some good changes in place and to conduct some good experiments. We did a few large-scale changes, which really were also experiments. A lot of the work paid off.

If your retrospectives are going stale, you might talk with your C-level supporters and bring the team a policy that clearly spells out their permission to try, change, and grow. Developers want to be productive (a fact worthy of a blog series if not a new book), and may need to be encouraged to look past the stories and tasks to work that might accelerate the whole team.

Agile And Beyond Party

2011-03-15T20:55:00.000-07:00

Here is the table from Agile And Beyond last weekend. There are a few interesting features here. You can see the cool phones, the notebooks, the Agile In A Flash cards being shared on the table, and to the left of the diet coke is an Agile Otter business card.

I attended only two talks, and spent the rest of the time hanging out with my peers and having fun. The two talks were Mary Poppendieck's talk about where she sees post-agile going (a nice talk, btw, well given) and Dr. Michael Norton (docondev's) talk about technical debt.

I was ill-rested, over-caffeinated, and a little eager. I had motormouth, but it was still a great time )for me). I hope that Mike Hill, Tracy and Angela Harms, Matthew Weitzel, Patrick Wilson-Welsh, Michael Norton, Zachary Spencer, Nayan Hajratwala, Matt Barcomb, Jon Stahl, Bill Tozier, and all the rest (drop me a note if I forgot to mention you) all had as much fun as I did.

Best wishes to my colleagues on the other side of the lake!

Stop hating on the command line

2011-03-09T07:55:00.000-08:00

Let's begin with this simple assertion: command.com sucks. It has always sucked, and always will. Powershell might be nicer, but most people haven't learned how to use it, and it's only available in one operating system anyway.

If I say "command line" to a Windows-only person, they're thinking "command.com." Avoiding that command line is a huge part of making their lives pleasant. I am not slamming on hating the windows command line. All of us Unix/Linux geeks hate it too. I never feel much less productive than when I'm in command.com. I avoid it too.

I started back when CP/M was the killer operating system. Its command line was not so great either, but it had a strong free software community who shipped programs to each other on floppy disks. As a result, we had this language called "submit" (and later "supersub") which you could actually do stuff in. It was like a real language. The command line suddenly was pretty decent.

When the PC came out, it pretty much got rid of the CP/M market, and with it the community. DOS had batch files and command.com, and those were okay. You really had to use those tools, because there was not much else. Eventually GEM and DESQview came along, and multitasked your DOS text apps nicely. They were taking hold when Windows first came out and destroyed the market and community for those programs. But that's neither here nor there.

What happened in the 80s that turned me into a command-line fan was my defecting to Unix and learning to use a proper command line. Bash and Zsh are the popular, ubiquitous shells these days but in the days when I jumped in the world was divided into csh and ksh users. All of these shells are command-line interfaces to the whole freaking operating system, and the Unix designers (then and now) worked to make everything available to the shell. Instead of a crummy one-line window to slow-key commands into, these were full programming languages with proper variables, decent flow control, error reporting and handling, wildcarding, extensibility, event-handling, online help, and access to system innards. It went far beyond meager batch files.

It just got better with each generation of shell. You an launch subshells, and stack shells so that you can "pop" back to an earlier context. Each subshell has its own current directory, and any one shell can have a stack of directories (pushd/popd/rotd), each shell has history and history search. There is process control and the ability to pull processes into background and foreground. There are rich stream-oriented languages and tools for processing data. There is more functionality in the command line than you can take in at a glance.

The manual page for bash (arguably the most ubiquitous shell) is over 3000 lines long. I know because I did "man bash | wc -l" to find out. Considering that the documentation is terse, that represents a heck of a lot of functionality. Zsh is so feature-rich its manual has been broken into 17 chapters.

Of course, these are available via cygwin for you windows machines (if you really have to use windows) but will be slow because windows file systems are slow, and are a little crippled because windows has a different design philosophy than the Unixen do.

But the point is that "avoid the command line," however reasonable when the command line is command.com, is hardly a universal goal. Instead, mac and linux and unix people almost universally embrace the command line, often preferring it to gui tools to do the same jobs. It is explorable, scriptable, powerful, and useful.

So stop hating on 'the command line.' Next time, windows users, say "I hate my command line." Install cygwin (or better, Ubuntu) and give the manuals a little light read. You will be surprised what power lies just under the GUI.

For the record, GUI is kinda cool, too.

Python for Everyone At My House

2011-03-07T22:40:00.000-08:00

I started teaching my youngest son python years ago. I started him with the turtle package and he drew circles, lines, and squares. He had a great time doing things like creating variables that carry his brother's name and setting them equal to "llama butt." Now he's older, and wanting to do some more programming.

We decided to start with a simple guessing game, and picked "battleship." I also decided that he's old enough to get a handle on tests and classes.

Tonight we decided what the rules were, and wrote some tests for creating ships and blowing them up. We'll be revisiting the stuff we've done, but by watching me and copying the text I typed he was able to run the tests a few dozen times, create a class, and start dealing with syntax and logic errors.

It's just a start. We'll have to get into it more deeply before we'll know if he really likes it, but I'll keep you posted.

A Fun Teamwork Experiment

2011-03-04T19:58:00.000-08:00

I want to take four teams of four people and arrange them in groups. Each group gets an identical book of crossword puzzles (or maybe a web printed book of a dozen puzzles of varying difficulty).

The first group divides the book in four pieces and each member does 1/4 of the book.
The second group takes one page at a time. The first guy does as much as he can and passes it to the second, and so on.
The third group divides the book in half parts and solves puzzles as pairs.
The fourth group has no rules about how to divide and organize the work.

We would count finished puzzles once per minute per team. We would let the experiment continue until one of the teams finishes its set of puzzles.

Publish the findings, and publish notes on how each team *felt* about their work style, and what they think they would do differently.

That's it. I would like to see how it comes out. If you have the time and enough people to try this, please follow-up with a comment here to tell me how it went. Better yet, write it up on your blog and send me a link. This could be a load of fun!

Stepping up Django Efforts

2011-03-03T18:42:00.000-08:00

Today we stepped it up a bit. Jeff Langr and I worked on our little project (shhh! it's a secret) and spent much of the day in django learning to test things. It cured a number of my developers' diseases and we got a bit done.

We started out trying to use Lettuce, which is a good idea and worth improving. We got a couple of tests working, using the client to send get results from the server and BeautifulSoup to parse the returned html. It was mostly a good experience, but then we found out that our handlers weren't specific to the scenario or the feature or even the file or directory. If you register a 'before' it's 'before' everything (it seems). Still we got some experience with it, and I think it'a great idea. With some scoping rules attached it would be totally awesome for ATDD, and I dig that it's pure python so you don't have to have a bunch of different languages & tools to do the work. It's a good start.

We picked up with more standard unit tests after lunch, calling the view function and letting it do the work. We figure that we don't really have to do a lot of through-the-browser testing, since django works pretty well and we're going to demo features before calling them 'done.' Heck, we'll probably try a few more ATDD tools before we're done.

We made a little progress on another page, and started to refactor it into a decent shape. I'll probably go on with that on my own a while. I think I have a good handle on this now, but will still do a fair amount of experimenting before this is done.

For django, my feelings are mostly positive. It's simple enough, works, and is fairly logical. I have not come to terms with which libraries I have to import everything from, but otherwise am gaining fluency. I have much to learn. I really wish that the objects were mapped to the ORM instead of being instances and attributes of ORM classes. They've gone to some lengths to make it easy to work with ORM classes instead of easy separation, but they've done a good job.

More later.

Regaining Humility and Thereby Sanity

2011-03-02T13:41:00.000-08:00

I got too big for my britches last week and was feeling kinda saucy. I figured that having read a tutorial some time ago should be enough for a smart guy like me, so I started up a web project and an app and slammed in some model work, splashed an url on, and was thinking I knew what i was doing. No tests, but heck it's only a few lines of code and some generated stuff.

Then the test thing got to me. I started searching to see some testing tools, and ended up reading three paragraphs of every tool tutorial I could find. I pulled down a few testing tools. I started writing a test, and before I could really evaluate whether I liked how it was going started to mix different test libraries together. Pull the html parsing from here, the basic test setup from there, the helper routines from another place and pretty soon...

Pretty soon I realized that I wasn't learning anymore. I was permuting and chasing error messages and flailing and feeling kind of frustrated and lost.

Today I deleted everything I was working on, started a new virtualenv with just the stuff I really think I want to use, and I'm going to do things as the authors intended instead of the way that seems right to me.

I learned a lot of little things while exploding in all directions, but I'd have learned more and probably been done if I had tried to maximize depth of learning and not surface-scraped too many things for my poor little brain.

A little while ago someone put up a tweet suggesting that when you are trying to learn a lot of stuff, you should remember to chew and swallow the information. I realized I'd stuffed my face. This time, I will respect that there is a rate of absorption, and see how much better I can get.

I had exceeded the WIP limits of my own brain. I can never pick on managers for that again, because we all sometimes are tempted to use the blender-funnel-and-plunger method of taking in too much too fast, whether information, work, or whatever.

Wish me and my newly regained humility some luck.

COTW: Build Superior Systems With Simple Design

2011-03-01T07:40:00.000-08:00

Our Card Of The Week from AgileInAFlash is #41

The original article is at the Agile In A Flash blog, and has slightly different wording. We adopted the phrasing from c2.com's page.

I was pretty jazzed about having this card in our project, because it really does capture almost all of the code values and most design principles all in four little rules. It has always been profound in its simplicity. I wish we were able to make all of our cards and articles as concise and deeply applicable.

My idea of a great teaching program would be to start with this card, a testing library, and a programming language. We would do some exercises following these rules. After doing some projects to get our testing and refactoring skills up to par, I would bring in the four big ideas one at a time, so we could see how to better focus our work. Then probably I would bring in the seven code virtues and SOLID. Then we would call it "a good start" and I would go home. The class could pick up books on continuous integration and refactoring, and probably be able to run on their own indefinitely.

Learning the language, frameworks, and operating system quirks would be the other side of the coin. Ideas and ideals sound simple until you get to some ugliness in the OS or the web server or browser oddities. That's when you go back to this card. With simple design, you can weather some pretty amazing technical crapstorms.

This card is one part checklist, one part process. The rules are in priority order (just like "make it run, make it right, make it fast, make it small"), and also in process order. Cool stuff, huh?

So, run all your tests. Write a new test. Make it pass. Look for duplication, and kill it. Do you and your current pair programming partner agree that it makes good sense as-written? If not, fix it. Now, do you have any leftover bits that you don't need, any architectural artifacts you can live without? Unnecessary round-trips? Extra "cool" technology you can do without? Run all your tests. Start over.

Easy flowchart for communicators

2011-02-23T07:12:00.000-08:00

I know it's simple, but why should it not be? Even simple things are hard.

Reminder to self: don't skip three out of four boxes.

Grandpa Tim Tells A Scary Story

2011-02-21T10:13:00.000-08:00

"Grandpa Tim, tell us about the old days."

Grandpa Tim set aside his reading glasses and programming text. "Are you sure, children? It's nearly bed time. Maybe a story about ponies and puppies?"

"No, Grandpa, we want to hear a scary story!"

Tim looked around to be sure the lady of the house would not overhear and scold him for giving the little ones nightmares. "Very well," he sighed.

"In the old, old, olden days programmers were isolated from each other by many barriers. Companies did not allow programmers in other companies to see their code, or to look at other companies' code. They built legal barriers and contracts that programmers had to sign if they wanted to make a living. This way, ideas could not be shared across company barriers. In many companies, they did not allow access to the internet for fear that ideas could escape from one company into another, or that people would spend time learning instead of typing."

"But if you don't learn, how do you know what to type?"

"This wasn't the way people thought in the old days. They thought that programmers should learn before working, not while working. They didn't send them to conventions, and they seldom offered training. It was before people understood 'maximize learning', so they marginalized it.

"This was not the full extent of isolation. Within the company, they further separated teams by splitting them across time zones so communication was more difficult. Then within any one location, they would separate small teams from each other with different management structures, and put them in separate rooms."

Big-eyed, Leah asked: "At least the people within teams got to work together, right?"

"Well, no. Within a team, the programmers were even more divided than among locations or companies. They were separated from each other by cubicle walls, and discouraged from talking to each other."

"Even by text messaging?"

"Especially by text messaging. In addition, each developer was given an individual task, so that the teams were not teams at all. They were all working on different things. One more division existed and it was more powerful than all of the others: they pitted the developers against each other and rewarded individuals instead of teams."

Ian reflected thoughtfully, "So the best programmers got the most rewards? At least that part was fair."

"Well, no. The rewards were based on everything but skill. They were given to the one who spent the most time in his isolated cubicle space, the ones who cranked out the most sloppy code to get features done, and the ones who could blame failures on other programmers credibly. Sometimes they were rewarded for conforming to the corporate structure better than their peers. Often the worst programmers would be rewarded, and promoted over their brethren. Most programmers realized that if they helped their colleagues, it would actually count against them. This was the most isolating practice of all.

"Yet beyond isolation was a problem even more troubling. Programmers and their bosses were afraid to write code. They worked on systems they didn't understand, and were not free to explore the code. They were not allowed enough time and communication to understand the design of the system, so any change they made could break existing features."

Ian interjected, "But Grandpa, the tests tell you if you've broken anything. It's not that hard!"

"No, Ian, it was not so, because in those days the programmers did not write tests before writing code. Managers thought programming was about typing the answers into the computer, and didn't realize it was about understanding the code and inventing good answers. They tried to improve productivity by cutting down on programmer testing, and some convinced themselves it was right to do so after seeing how difficult, slow, and expensive after-the-fact testing was."

"I don't understand, grandpa." said Ian. "If they don't have tests, how can they refactor?"

"They avoided refactoring. The programmers did not want to create errors, and had no good way to catch them before release, so they tried not to touch any existing code. They were afraid of undetected errors being released. Instead they would patch changes onto the software with the minimally-invasive techniques, like copying and pasting code or patching the code with flags instead of extending the design."

"But if they couldn't refactor, how could they steer the design?"

"They avoided changing. They hesitated to change direction even to please the customers who paid them. They were afraid that any change could wreck their existing plans and their existing code. In those dark days, programmers and their companies were very afraid indeed."

"Didn't the partner help them be more brave?" asked Leah.

"No, darling. Managers assigned work to individuals. They reasoned that two people using one keyboard would type only half as much code as two people working alone. Again, they didn't understand that the bottleneck was thinking. So without tests and without programming partners, the isolated programmer often didn't really understand the system he was working on and was rewarded on how fast he churned out features anyway."

Leah frowned. "If it was like that, why did people code at all?"

"They wrote code because they loved it and love covers many sins. They could overlook the poor workspace, the lack of community, the isolation, and the fear because ultimately they loved coding and testing and solving problems. You would be amazed what people will do out of love and the joy of creation. Even in the darkest times, programmers were people who loved their work. They would have programmed even with six-year old IDEs and outdated technologies and operating systems. They would program when the rewards systems turned against them.

"Even then a programmer could make enough money to support his family, so there were people who didn't like programming but did it anyway so that they could pay their bills and have other things they liked. Because they didn't really love the work, it was hard for them to learn new ways and improve their world. Few of these programmers survived past the Big Change.

"Around the turn of the century the world changed. During the 1990s and early 2000s the agilists started breaking down cubicle farms and replacing them with shared workspaces. They were successful in promoting pair programming and teamwork in many companies. They promoted communication within teams, among teams, and even got many businesses to allow access to the internet and the programming community outside the company. They had continuous testing, continuous integration, and continuous release. As we got into the 2000s, the craftsmen came and broke down barriers further, setting up programming studios where people could come and program with their developers on actual projects, for free. They promoted practicing programmer skills. They set up code camps and dojos and hackfests, and wore down the old ways with quality, teamwork, and community.

The old way did not die out right away, but over time all software developers found that the world around them had changed substantially. Some of them left the isolated cube-world for the open, transparent studio. As the new ways showed success, more conservative businesses started to change. A few bastions of the old world, some small and some large, held out until the end when the more agile companies started to gain market share on the strength of their flexibility and shorter time-to-market. It was a sad time for those who didn't learn."

"But it's good when the bad companies go away, right grandpa?"

"Ian, it is always good when people get new opportunities and learn better ways of doing things. It is always good when people start working out of joy and not fear. Yet it is always sad when companies close and when people lose jobs. Those who were content in isolation from new practices and the programming community struggled horribly when they lost their jobs. Some of them adjusted, some quit programming forever.

Now it's getting late. Don't worry about old times, they're all gone now. The world changes, and brings new things every day. It's time to go to sleep. Who knows what we might learn tomorrow? It's best to be fresh and excited and ready to greet the day."

Leah stopped by the staircase on the way up to bed. "Grandpa Tim," she said, "I'm never going to be afraid to write code."

"No," grandpa Tim said, "I think you never will."

Agile Otter Receives Love

2011-02-17T17:51:00.000-08:00

Here are a few of the recommendations I've received:

“Tim is the consummate software developer, with extensive knowledge and capability. I had the opportunity to pair with Tim many times over the course of year while at GeoLearning, and it was always the most enjoyable pairing session to look forward to. Tim is sharp, patient, knows how to explain things, and most importantly knows how to get things done. I'd pick Tim in a heartbeat for my "dream team" of developers.” J.L. February 1, 2011

“Tim deeply understands the fundamentals of agile, lean, and test-driven development and is able, like few others, to succinctly communicate their essentials in a practical, "this is how we're gonna do it" kind of way. Moreover, when reality and theory collide, Tim has the depth of understanding to help tweak and tailor practices and promote their implementation in way that meshes with an organization's existing culture/operations. If you want your development team(s) to improve what they do and how they do it then Tim's the guy for the job.” D.T. February 11, 2009

“It was a real pleasure working with Tim. His expertise in organizational dynamics with respect to software development is such that i would hesitate to put him in the same category as any other normal manager of software teams. This is to say that as a consultant viewing organizations from the outside, he got a close-up view of the ways that organizations can change, and the ways they can't, and it was always interesting to hear his take on things when we asked him how we could approach our process to improve it. Tim was also a spot-on developer. He created a bunch of testing frameworks that we used and built upon (and still use years after he moved on). There were some intricacies of these frameworks (especially Fitnesse) and it was incredibly handy to have him around to debug and decipher. I would enjoy working with Tim again and would consider him an asset to any organization that has him.” K.R. April 22, 2010

“Tim was brought in to coach our team through our agile transition. He worked with us in the ways we needed, and he always focused on our current state as much as where he wanted us to go. Tim adapted his approach daily based on our feedback, and when we ran out of questions, he would push us to the next level with a new idea.” K.S. October 1, 2007

I thank you for the kind words. The Linked-in recommendations are always appreciated and always useful. Hopefully we can add in a few recommendations for the books as well.

Self-Promotion and Resume-writing

2011-02-16T10:23:00.000-08:00

I've read some resume-writing tips and I've talked with good friends who have nailed a particular problem I'm having. I turn to my loving readership for general advice now.

When reading a resume, I often see flashy hyperbole and unnecessary superlatives. I think "of course he's trying to make himself sound great, he wants something from me." The more fantastically good the resume reads, the less I believe it. I will be extra hard on people who sound like a combination of superman and Einstein, and might bypass them entirely and try to find someone more "honest."

When writing a resume for myself, I strive to NOT trip that reflex. I write up my most satisfying successes as if they were workaday events, my biggest challenges as if they were normal problem-solving moments, and my best outcomes as if they were foregone conclusions. I don't try to make it sound as if I did 8 impossible things before breakfast and had time for an extra scone, but rather tend to be dry in description.

My friends and colleagues tell me that my resume, as a result, tends to not represent me well. It makes me sound boring, workaday, and unimpressive. They offer replacement paragraphs saying things like,

Inspiring software architect who can take any team and lead them through excellent example and solid teachings to higher levels of productivity, quality and responsibility. Keen understanding of the processes involved in delivering quality software on time. Accomplished author and educator. Able to communicate clearly with business as well as and tech people. Extensive proven ability to take legacy code base and help bring down bug count, increase customer satisfaction and decreasing [sic] development time. Never-ending enthusiasm for anything software development including new languages, tools and ideas.

If my former CIO says this about me (as one indeed did, word-for-word), it sounds positively inspiring. But imagine I was sitting down with you, and said the same things about myself. Would you flip the bozo bit, toss my resume to the circular file, and move on to someone with a less desperate grasp of self-inflating superlatives?

The question, dear friends, is how one can incorporate the praise of others in their resume in a checkable, responsible, honest way? If others recommend me, how can I make those recommendations known? Is there a way I can do so without sounding like I made them up?

I await your suggestions. Thanks for bearing with me in this rather personal interruption in the flow of Agile software topics.

The Wicks

2011-02-14T09:24:00.000-08:00

I had a good morning conversation with some good people in twitter (Jim Argeropoulos, Dean Goodmanson, others) about programmers and how many of them seem to have no real interest in the art/craft/vocation of programming. They tend to crank out the same code they did seven years ago, or longer, appending flags and if-then statements to masses of flags and conditionals, and never growing in their practice.

I offered a metaphor of candles:

A million candles, if not exposed to flame, will not light a room.

For the symbolism-challenged, candles are people in the programming vocation and flame is an active interest (if not outright love) of the work we do. Here is my extended analogy for your consideration:

Burning Wicks are those who love programming and spend time learning, reading, studying, and improving their skills. They are contagious in their enthusiasm for better techniques and programming meta-considerations. They have done quite a bit of self-study, and have connected with kindred souls in the programming community. They may have trouble fitting into some corporate cultures, unless the corporation values the kind of enthusiasm and learning-experiences these developers bring to them.
Dry Wicks are those who have entered the field of programming but never have been exposed to developers who have a burning love for the practice. They may have never heard about the issues of Coupling, Cohesion, Duplication, and Volatility. They may never have read Clean Code or Code Complete or the like. They have never heard a keynote speech or training session on better programming techniques.
Dry wicks are ready to be lit. If a burning wick is introduced, a dry wick might catch flame. It may not take the introduction of two or three burning wicks before it picks up, but it will eventually light.
Burnt Wicks have been lit in the past, but circumstances (difficult work situations, bad corporate policies, poor coworker relations, etc) have caused the flame to go out. Often a burnt wick can be re-lit, but it requires appropriate circumstances and a fresh application of flame.
Wet Wicks will not light. This is the true "just a paycheck" programmer, or the programmer who only programs so that he can do what he really wants to do (marketing, electronics design, management). It can be hard to tell a wet wick from a burnt or dry one at first. If a truly wet wick is found, the best thing to do is save your team from his influence by moving him to an area where he really has an interest. We can do better than "just a paycheck" programmers.

The question asked was what is the best we can do, then? I suggest that every programming team that isn't burning brightly needs a few burning wicks added. This infusion of fire can be in the form of contractors, consultants, or new team members. Some of us would be happy to come on as temporary full-time workers (say for a year or two). The first burning wick will catch some dry or burnt wicks, the next will pick up some more. After a few attempts, you will find out which wicks will simply not light.

It is not my practice to recommend any developer's termination, but if you have a few who act as a wet blanket on the others, or who refuse to develop any real interest in what they're doing for 8+ hours each day, you would be better to make a lateral move (do not promote a wet wick over a programing team!) or help them find a new place to work away from your burning-hot developers.

Rather than a pronouncement from a greybeard developer, I would like this to be a conversation starter. Tell me how you bring the fire to your team and what has not worked. Help me know where the metaphor breaks down and what you would like to see done about it.

4 Questions Film Project

2011-02-10T09:35:00.000-08:00

What would you say given only 60 seconds to answer:

What do you do?
Why did you start?
Why do you love it?
Why does it matter?

You can make a 60-second (or less) film, answering these questions (or a subset thereof) for our collection. We hope to impact decision-making among young people, encouraging them to enter the software craft.

Can you help?

World's Shortest Agile Summary

2011-02-03T08:08:00.000-08:00

Thanks to George Dinwiddie and Mark Levinson and that marvel we call Twitter, your agile otter presents the worlds briefest summation of Agile:

Do small things supremely well, and let them add up to large things.
Use feedback to steer to the results you want.
Defeat problems with teamwork.
Maintain an even strain.

The Great Giveaway Begins

2011-02-02T16:14:00.000-08:00

They're here!

Now that I have extra decks of Agile In A Flash, I want to give them away in person as a door prize or in a contest of some sort. The problem is that I'm located in the far NW 'burbs of Chicagoland. I can get to Chicago or I can get to Milwaukee, maybe out to Rockland or some points in-between. Invite me, and I'll see what I can do!

I love hanging out with software developers of all types but prefer the meetings to be about agile, some programming language, or Linux. I might even score some other goodies to hand out. Talk to me.

If you want to talk to me about coaching your team, I might bring a copy to the interview, but I want the community to have dibs.

Pairing, Competence, and Recognition

2011-01-28T07:00:00.000-08:00

parIt's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on:

There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases.

Rockstars

If you are the rock star of the team now, you will find that pairing will give you mentoring and teaching opportunities and respect that you've never had before. Invariably, a great programmer on any team (whether outgoing or quiet) becomes revered by the team. If you have the skills alone, you have the skills paired too. I've not seen any great programmers fall through the cracks. Sometimes a pair mismatch may be uncomfortable for a while, but you can elevate the skills of your teammate. Imagine what it is like when all the members of the team will listen and will up their game. You will find it is much cooler to be a revered member of a competent team than to be the high-and-mighty member of a mediocre team. You have nothing to lose and everything to win.

Bob Anderson named a strategy "Attack The Weak" (tongue-in-cheek), in which the strong member of a team intentionally selects a less-established or less-experienced partner on purpose, as a teaching and sharing opportunity. This is a good strategy, provided the strong member is nurturing and not dictating. The point is to raise the partner's skill level, not to expose them as weak. Not every pairing has to be of this form, but several a week is a good idea.

Growing Developers

If you are the weakest player on the team, you will find that pairing gives you an opportunity to learn from your teammates. In addition, as the partner shares the keyboard and ensures that you're doing test-first work, you will find that it's harder to make a mistake that gets through to integration (let alone release). You have a safer working/learning environment.

In a strategy I call "eat the rich", you choose a partner who knows something you want to understand better. That partner may be a tester, a UI expert, a performance expert, the local ruby guru, or someone who really deeply groks the platform. By pairing with them a few times a week, you add their skills to your own.

The Borg Collective

A common fear is that everyone will be assimilated, and the entire team becomes an amorphous mass of fungible "resources", that the strong and the weak will be indistinguishable, and that morale will collapse. Some fear that incompetent developers will be able to hide in the team and drag down efforts, or that brilliant developers will be unrecognized.

The fact is that people are different, and are drawn to different aspects of the work. We can all get better at everything, but some things will speak to us more deeply than others. As a result, we will have special strengths and weaknesses.

When you work entirely in pairs, everyone who works with you will get to know you. While it makes no sense to recognize and reward individual efforts in a team (thereby creating competition and sabotaging the team effort), there is no question in anyone's mind who the strong and weak players are. This information is best kept within the team, but there is no question. In a 360-degree review, the strong team players will be recognized. Think how great it would be if your coworkers were the ones who promoted you, because you have helped them improve and they respect the skills.

This is where the potentially sad part comes in. Some people cannot program well, but do it anyway. If an initially weak player shows potential and improvement, everybody is happy to see them grow and change. Sadly, some people don't get any better. If they don't take advantage of the team-learning and remain weak and unskilled, they will demoralize the team. Nobody wants to be hand-holding and nose-wiping and babysitting all the time. If someone is a continual drag on the team, and doesn't improve, and doesn't show any signs of potential, everybody on the team knows that too. In order to protect the team's morale and productivity, teammates may "vote him off the island" by asking their scrum master or project manager to consider counseling that person into a position more suited to their skills, even if that means another company. This is sad to the one who has to leave, but can actually improve the morale of the team. It is doubly sad if the one asked to leave has an inflated self-image and thinks himself a rock star. On an agile team, though, it should never be a surprise to be asked to leave.

School for Deserters

The other concern is that people will improve their marketability as developers. After all, they've had months of self-improvement and now can put the big A word on their resume ("agile", not what you are thinking) so now they could command a higher salary if they leave.

Okay, fair cop. You will suddenly have a team of developers that are the envy of the other companies in your area. Competitors and neighbors will start to take notice, and may extend some recruitment feelers into your team.

Think about the mixed blessing here: You have the team that everyone wishes they had. If you want to look at this as a problem, go ahead. Might you have to hand out some bonuses or raises based on the performance of the team? You might, but don't you want to have a team that is deserving of recognition and reward? Isn't that better than the alternatives?

Conclusion

Yes, when you become a true agile team, the teamwork does eliminate individual rankings in a traditional way. You can't say who completed a piece of work because the team did it (perhaps every single member had a hand in it), so old individual rewards are hard to give. Worse, individual rewards can break down a team if they create competition between the members, since competition can stymie free and open sharing of skills. On the other hand, peer respect is more to be coveted and can be measured.

Even if there were no way to reward people for being great team members and mentors, imagine how much more pleasant it would be to work with a team of capable, motivated partners instead of a mixed bag of people who don't really have the on-the-job opportunity to up their game in a meaningful way. It's an exciting thought.

All members of a team can grow and teach and develop in an agile pairing environment, and this makes the company stronger as well. It will fly in the face of some classic motivational schemes, but Agile is a little counter-intuitive that way.

Discoveries of the Week

2011-01-28T06:15:00.000-08:00

This week I made some social networking advancements and started to build a few other new skills.

The first is Tweet Feed which is likely responsible for you seeing this short article. I am not going to have to hand-tweet the AgileInAFlash or AgileOtter articles because they're auto-tweeted for me.

The second is that blogger's admin screens let me turn on the social button bar after each article, so readers may more easily promote anything they find interesting or outrageous. It's a small thing, but already I've seen a new tweet from the page. It's a very small thing, but sometimes small things matter.

I'm on ohloh now. My friend Sam Hart has prodded me a bit, and I finally realized he's right (it takes me a while sometimes) and I should take some credit for the work I've done in the public space, like the PDK. I never realized that I was the check-in leader there. Sam wants me to pick it up and make it a living project again, and I'm thinking he may be right. Mind you, I am a little more interested in the DITS concept, but I have opportunities.

A big social breakthrough is that I realized that taking the train downtown isn't as bad as I made it out to be. Now that I'm moved a bit south and am near a station on a different line, it's just $12.00 for the round trip and it's a bit over an hour each way. This is important because all my peers in the agile community are downtown and I could benefit much from being connected with the local community. It will help with the Talent Agency idea as well as Agile In A Flash, and we all know how iron sharpens iron.

I have entered the world of video production. I really am NOT great at it, but I made some progress in the video realm. I am now a fan of dead-simple transcoding front ends. Arista has been handy for me. While Open Shot is still my editor, I don't always get new content into the right format and size for media sites. I used Arista and encoded for iPod, and it turns out to be totally viewable by mac and windows users (the poor saps) in addition to more enlightened Ubuntu users (1/2 grin).

I ended up putting opening and closing title images on the "Deal" video, and put a drum track at the beginning and end. I still don't know anything about making interesting videos or screencasts, but I suppose that's the future. It's a way to connect, and connecting is good.

I also started with Django all over again. I've read a bit more of the book (on the train) and re-did the "Django for the impatient" and am getting to a point where I can more easily dig into the unit testing problems. I just needed some backgrounding. I've been invited to play in a nice open source project in Django, so I have a wealth of options.

I also am looking at a few good opportunities for my next gig. There is so much to learn, and so many good people to work for, it is an embarrassing wealth of options. Will I be Agile Otter or Django Otter next month?

One Video Wrapped Up

2011-01-24T18:07:00.000-08:00

I have our first video finished. Notice how my face never appeared. I'm going to have to get used to hearing my voice on these, maybe I'll do the full-frontal face thing in one of the future videos. Either way, we now have a commercial that explains what this whole Agile In A Flash thing is about.

Django Unit Test Hobby

2011-01-20T08:53:00.000-08:00

I have played with Django, but never really did any work in it. Even my toy app died before I got to a "good working model" state with it, because I did not maintain focus and wandered off too much. Since then I've developed a keen interest in learning more web technology, and so this time is Django Charge 2.0.

I visited some very nice, very smart people this week to took me into their offices and showed me some of their Django code. We started to talk about testing, and I made a small abortive attempt to do some plain-old-unit-testing in their python code base. It was not all that I hoped it would be (Dean, please revert that code if you haven't already). I ran out of time to play, but hopefully will be back to enjoy some pair programming goodness in the near future.

The cool and interesting bit about Django testing is that testing through manage.py will have you standing up an instance of the app complete with database. The setup is fairly onerous, but the tests run quite quickly. I think a lot of good integration testing can be done this way, but I wanted to do proper unit testing, where "proper" means that I do not stand up an application instance, don't use the database, and all of my unit tests (even when there are 20K of them) will run in less than 45 seconds. This becomes hard because Django's object mapper is in the DNA of django model objects. I guess I'll end up designing around that limitation, hopefully without my head exploding.

The other complication is the virtualenv. We definitely want to run the tests in the virtual environment, but don't want to launch a shell instance to do it. I'd like to autonose this, or better yet hook it into pyCharm and/or eclipse pyDev. It shouldn't be much of a problem... worse case should be launching the tool inside the virtualenv.

I'm not interested in doctest. I have a long-standing phobia against the use of magic comments. They offend my sense of how things should work. I'll be doing unittest (unless I succumb to pressure to write my own framework).

Today I begin my new hobby. I'll follow up here with links to interesting Django unit test links, and probably little discoveries. I'm not going to rush to solution, but try in code-camp style to work perfectly instead. It will be fun.

Agile In A Flash

2011-01-20T07:17:00.000-08:00

Today the deck is released for purchase. I'm getting tweets and messages from people who have either purchased the eBook or placed an order for decks. Thanks to everyone for their support in our crazy little project. So far many retailers are selling.

Remote Pairing Matters

2011-01-19T19:37:00.000-08:00

The one thing I haven't said about my time as a remote pair programmer is that remote pair programming is a brilliant idea and it matters. The reason I didn't mention it there was because that was work. This is personal development.

We improve our skills and our exposure in the world by pairing with more people. I've been a shy guy, not always jumping into the pairing sessions at conferences, and I'm the poorer for it. I could have been soaking up mojo from the greats instead of hiding out.

But remote pairing? You are not in front of a whole bunch of strangers who are potentially judging you. You're in a one-on-one situation with someone you couldn't have visited personally due to any number of travel constraints. It's just the two of you and your headphones. You can work on your code, or the other guy's code, and it doesn't matter. It can be 6am or 2am or noon on a saturday, any time your schedules just happen to coincide.

This is something I think we need to foster. We need a good system for hooking up eager remote pair partners with their peers, betters, and rising stars all over the world. Imagine how much good we could do if it were possible to pop onto some web site (a software talent agency?) and hook up with Ward Cunningham or Andy Hunt or Corey Haines for a couple of hours after dinner. It's not just name-brand acts either -- there are thousands of programmers who could teach me or learn from me in a session (maybe both). We could form up community that spans the globs, one or two time zones at a time.

The problem is that remote pairing tools all suck really bad or cost money.

Because remote pairing really matters, we need to all jump in the pool. We need to be filing reports for the likes of Yuuguu and WebEx and GoToMeeting or any other company with competence. We need a few open source projects to do screen-sharing or edit-session-sharing. Eclipse needs better sharing, though they've got an interesting start.

This is all solvable stuff. The technical side could be made to work. We just have to put ourselves into it. If we can solve the pairing technical problems, the remote partner exchange idea is just a simple python or ruby script away.

Wouldn't you enjoy jumping into someone else's code on the weekend or in the evenings. Wouldn't it be fun to put the next patch into some great OS project if you had a guide and peer to join you? Wouldn't you love to have good working relationships with hundreds of people who could recommend you for interesting jobs and projects around the country (or the world)?

Remote pairing matters, and it may be the way we all move the trade forward. It's a brilliant idea, and we need to support those who are out front, solving the big problems.

Reflecting on Being Employed as a Remote Pair Programmer

2011-01-15T07:52:00.000-08:00

Being a telecommuter or remote team member is considered a pretty sweet deal and is recognized as a more "green" way of working. Remotes don't share illnesses with their teammates, and yet work when ill. Remotes don't participate in office gossip or struggle with personalities the way locals can. The perceived problem with remotes is that they are unmanaged (in fact, they are impossible to micro-manage effectively). The actual problem with remotes is that they can be disconnected.

The solution to the perceived and real problem seems to be in the sweet spot of remote pairing. I was lucky enough to work for a few years as a remote pair-partner. As a remote, I worked common hours just as my peers did. I joined them in the morning, took lunch when they did, and worked until they went home in the evening. We spend most of the day on-camera together (or at least in voice via headsets), sharing the screen and development tools, writing tests and code, exploring technical problems, and building solutions.

It is not the "remote developer concept" that many have in mind. I worked from my home, but did not make my own hours. I did not go to an office by day, but also did not work for myself. I could not take arbitrary days off as self-employed or many work-from-home people often do. It worked well for me and for my employer.

We found a pretty sweet combination by using Skype for voice and video, git for version control, and Webex to do screen sharing. The latency for webex is surprisingly low, and suited our needs very nicely. I set up a netbook with a built-in camera for skype so the company laptop's CPUs could be fully devoted to programing and screen-sharing (so necessary when using cpu-hungry development tools). An Asus EEEPC netbook is under US$300 most places, and mine really does a great job. I have had a few headsets. They're inexpensive, but they also tend to get uncomfortable after a few hours, so I would definitely try several. I used a few logitech models and was more-or-less satisfied.

The other useful tools for a remote pair partner? I second monitor (a large one) and synergy. Synergy allows one keyboard and mouse to be used by multiple computers. It is easy to setup and use, and allowed me to switch between netbook and work notebook very easily. I found myself mousing among three screens attached to two computers, and never thinking twice about it. It all just became transparent.

If your organization is interested in using remote teammates, I cannot over-recommend the combination of WebEx, Skype, Netbook, Work Computer, Synergy. For very little cost, you have a powerful pairing system.

There are shortcomings to being a remote pair-programmer, though. You are not visible to your bosses, and can be forgotten sometimes. You do not participate in the conversations at the next cubicle, in the hallway, or at lunch. You don't see the same visual cues as to the team's progress. You can't feel the emotional charge in the room to know when people are afraid, tired, angry, or excited.

A remote does not have the physical presence necessary to be an agile coach or effective scrum master. Email and text will not truly fill the gap of rich, human communication. Your view of the team is the webcam. That leaves you out of mentoring opportunities, so you learn and teach less than you could have on-site.

Remote meeting participation is awful. The room is full of people, and there are one (or a few) mics. Inevitably the people doing the most speaking will be furthest from the microphones, and the most fidgety people will be close to them. There will be long stretches when you can't make out what is being said behind the rustling papers, pen clicks, rhythmic tapping, layers of whispering, etc. The worst interruptions in sound are caused by the the other remote who is on speaker phone but didn't mute their mic. Every time a sound activates their mic, all other sound on the line is cut off. It is almost as if someone were toggling the mic in the meeting room. One can lose interest in trying to keep up and return to coding, missing the reason they were invited to the meeting in the first place.

Finally, a remote is harder to promote and easier to release than a body you see every day in the office. That might be seen as an advantage to an employer, but will probably seem a little off-putting to the remote employee. My intention was to try remote development for a quarter or two, yet we stuck it out together for over two years. That's a pretty nice experiment, and I thank GeoLearning for the great and mutually-beneficial opportunity.

Would I be remote again? I think I would. I would remote with the same team in a heartbeat, because they're good people and we learned how to do this together. I still learned, connected, and enjoyed software development with good people. But I think I would like to go onsite again for a while. However convenient it is to be distant, programming is still a social act and still best done shoulder-to-shoulder.

Observation on Growing Disconnected

2011-01-15T06:50:00.000-08:00

People, software, and organizations often grow in this way: they accumulate without assimilating, and aggregate without integrating. As a result, they tend to be disconnected and fragmented and without a real focus or direction. In all three cases, it's amazing how functional they can be considering the shape they are in.

Perhaps this is the different between innovative young companies and the well-worn thinking paths of large ones, between young turks and hold functionaries, between greenfield software and legacy.

If so, then can we renew our creativity, youth, vigor, and clarity by ordering and integrating ourselves?

I would like to believe it is so. The idea, alas, is too grand for me. It's out here now, and maybe it will spark something more easily grasped and leveraged.

Software Talent Agency?

2011-01-13T09:05:00.000-08:00

I had some thoughts cross my mind today, and wanted to write them down before they fade.

I'm of some reputation in the agile community, a sometimes-recognized author, a consultant (ex-of Object Mentor, ex-of CSC Consulting) and an agile coach. I've taught thousands of developers to program in C or C++ or Python, how to do TDD in many more languages, and the intricacies of object-oriented design. I've refactored horrible code and tested and built tools and transformed teams.

I am also a 48-year-old man who needs to establish his personal brand. Many of us are introverts by nature, and those of us with rural, midwestern upbringing tend to self-deprecation. I've always found self-promotion abhorrent. Writing a promotional bio actually makes me a little sick at my stomach. The shame of it is that I could have learned to be comfortable with it a long time ago.

If I had begun the push earlier and had some coaching I would have made some different technology and career choices, but who knew? I jumped the track a few times, missed a few predictions, and didn't do some things that might have made me wealthier and more secure in my life and community.

Now imagine that you are well-known in your community, and you heard of some upcoming new Corey Haines or Ben Rady or other talented kid. You would have the contacts to introduce them around. You could help them to establish their web presence and write up promos. You could promote them among their peers. You could connect them with editors who could shepherd them into writing gigs with magazines. You could hook them up with local communities, find them speaking opportunities and help them polish their presentations. You could help them to write the kinds of things that get picked up on reddit, hackernews, and the like. You could find them side gigs, maybe help them negotiate rights to quote code and publish details on the work they do. You would have to learn about buzz and how it works, the way a publicist does.

It would be a talent agency for programmers.

With just one or two good success stories, you would raise the value of your organization and all of the people being coached there. Companies would be interested in using your people, and people would find value in joining.

It would be rough at first. You'd collect money much as a headhunter would. You would get a clip from placement, maybe a finders fee or the like. Maybe a clip from writing gigs you developed, deals you sign. There would be much to learn, but relationships would have a long tail. In time you could collect money on both sides.

I know that people already get involved in the community and connect and conferences, but not all people know how to do that or how to build momentum that way. It's a knack that some charismatic people have and others do not. Not all talented people can keep a room spellbound like Bob Martin or connect with people so easily as Corey Haines.

I wonder if the software world is big enough that we could have a talent development agency for software developers. It's a really intriguing thought, since self-promotion is not always what good techies do best.

I'm still the midwestern introvert, but I wonder if some of my extroverted peers see some value in the proposition.

About "Under Test"

2011-01-07T07:56:00.000-08:00

I wrote earlier about code being under test, and how advantageous to have a test "under" several layers of testing. As I was looking through my old google docs, I found this drawing I'd made to explain layers of testing in a web app.

Terminology is catered to the audience of the time, and will probably confuse some. For instance "controller" here is really more like the "model" layer with its duty of acting as facade and moderator for underlying objects. Its purpose is primarily ensuring business rules and performing a single broad function that includes potentially many objects at the lower level.

The "API" objects here are the business objects. Again, tailored to the local terminology. Apologies. Maybe the Agile Otter should redraw the whole thing sometime soon. Anyway...

The idea is pretty simple, but sometimes people don't quite understand why the code-behind needs to be thin and why they shouldn't re-implement functionality in the fitnesse tests. If we use good cohesion and manage coupling well, then the unit testing becomes fairly simple, as do the unit tests on the controller.

We can test the code-behind through the web but even automated browser-tests are slow, often running for hours. It is handy to have browser tests, but nobody wants to sit and wait for them to finish. Most shops will push them off to the build farm so they don't suck up developer time. If code it only tested by-hand through the user interface, testing is pushed off to a dedicated testing team who will script and re-run the sames tests month after month for hours. It quickly becomes too expensive to keep scaling that team, and they start selectively running ui tests, in which case errors will slip out to production and customer care will have extra work, and bug fix reports will pull programmers out of new feature engineering. Often a company will have to split off a separate full-time team to do production bug fixes and data repair. It gets expensive quickly. Automating the tests means that we might be able to run all the tests every day, so that fewer defects can get out to the customers. It's cost-effective, but again very slow. The less the code-behind does, the better we can deal with it being potentially untested.

Our integration and acceptance tests (shown here with FitNesse) are going to run many minutes, maybe an hour or more. If the tests take only a few minutes then programmers will run them several times a day, probably before committing or pushing code to the shared repository, almost certainly at the completion of a programming task. Ideally these tests will bypass the code-behind entirely, but not re-implement any of its functionality. In order to make these tests effective, we need to empty the code-behind so that it is little more than plumbing between the controller and the UI. The business function controller is pretty testable, but the tests are like integration tests with many objects involved and possibly significant effects. It can still be tricky to test at this level unless most of the interesting bigs are pushed down into the business objects. The less it does, the easier the testing is.

Finally we're getting into the individual business objects. These tend to be pretty easy to test, as they mostly act only upon themselves. Good news for us. We can write extensive tests to drive behaviors into the objects. They become robust and predictable and understandable to the degree we stick to what we know about coupling and cohesion. Because they are underneath layers of testing (UI, FitNesse, controller, and individual unit tests) we can have more confidence in the changes we make here.

Maybe the picture isn't perfect, and the terminology is a little twisted, but the idea here is very simple. It works out that we can save ourselves time and money and even save face if we learn to keep the upper layers of the application thin, and save the meaty implementation for the areas where it is under layers of testing.

Of course, all blessings are mixed and even dark clouds can have a silver lining, so simple ideas can have costs and side-effects all their own. But this simple idea seems to work and seems to reduce problems for development teams and companies which employ them.

Want Your Own Agile Otter?

2011-01-05T09:32:00.000-08:00

This is a limited time offer. If you would like to have The Agile Otter working for you, this might be your chance.

If you are looking to expand your technical team or need an experienced Agile coach, feel free to drop me a line (tottinge@gmail.com) and we can talk through particulars. I can work as a remote pair-programming partner (tech team) or on-site in NW Chicago burbs (coaching).

Explaining What I Do For A Living

2010-12-28T15:55:00.000-08:00

I had a friend once tell me that he didn't understand what it meant to program computers. He was not really a computer user, and was just getting ready to try email at the time. He wasn't a gamer, and frankly the whole computer thing seemed too weird to him. After all, it's a machine, right? How do you program a machine? Is it like choosing a darkness setting on the toaster? Typing data into quickbooks? What? That was many years ago, but it still sticks with me. Some people (most in fact) really don't know what I do. If I tell them, they don't know any more than before.

When most people hear "programmer" they think "IT", in which case I must be the guy who fixes network outages, distributes patches, and helps people when their machine crashes (admittedly, a weak view of what IT is about). But no, I'm not that guy. I love those guys, but I'm not one of them.

A cousin of mine took an introductory course on programming, probably in Visual Basic, I don't recall. He told me that what I do for a living is really easy, "just typing." Of course I do some typing, but I'm not employed as a typist. In fact, on my good days, the program I work on is net-negative in terms of lines of code. But then a one-semester course on music appreciation hardly makes one a symphony conductor, or even a musician.

A post on slashdot a while back asked how to disguise "think time" because people mistake it for slacking. Again, we forget that this is not obvious to non-programemrs. One follow-up from Ben Alabaster was useful

During their lunch break get them to do a simple task like as a crossword. Ask them to be conscious of the amount of time they spend reading/writing vs. the amount of time they spend thinking [or looking up the answer]. Tell them that this is exactly the same as the time you spend reading/typing vs. the amount of time you spend thinking and looking up answers.

Better still Sudoku because it can involve hours of trying to figure out where you went wrong and why none of your numbers add up. So while the task itself seems relatively easy, after all, it's just numbers in boxes it can take time. Get them to predict how long it'll take them before they start and see if their prediction is right - guaranteed it won't be. You can hit them with a double whammy for why your time expectations never quite add up either.

This is the only way I can really think of to get them to understand the way engineers work. I see lots of "those types just don't get us types" - people are adaptable, people can understand things if presented in a fashion they can understand, it's just that nobody's ever taken the time to present them with an argument they get.

I think it is a great answer. We don't type for a living, we understand, reason, mentally try different solutions, hypothesize, disprove, reason, and invent. If we already knew the solution, we would simply type it in and be done with it, just as someone who had already solved the sudoko puzzle could copy it onto paper in hardly a minute's effort.

The majority of my work, though, is in diving into a system I don't understand (having read only a small percentage of its total verbiage), learning enough to understand why it is broken, rearranging and rewriting things until they make sense, writing tests to prove that my understanding of the problem is right, making changes that should fix the problem, and testing that my changes don't introduce new problems, all within a system vast enough that no one person understands how it works. I guess that isn't so easy to understand.

I spend more time learning than problem-solving, and more time problem-solving than typing. Basically, programmers learn and think for a living, and type their solutions into computers.

I suppose the right analogy is that you are handed three pages in the middle of chapter 17 of a 40-chapter novel, and you're asked to make some plot changes in the next hour or so. There is no chance you can read the whole book and make the changes in time. You could ignore the book and make your little changes locally and hope it doesn't disrupt the overall plot line, or you can read the chapter you're in and wing it. Eventually you'll have a solution you believe in, and you can type it in... but you shouldn't dive in with a typewriter until you've assessed what's going on, and the first thing you type probably won't be "good enough."

But now imagine that the document isn't a novel, but a multi-million word legal contract. You have to be very, very precise. Any mistake might open the company up to lawsuits and issues and costly contract revisions. Now you have the idea.

A really huge crossword puzzle is still a good approximation of a software system. Any one letter of any word may be a part of several different words, and changing one word may force you to change several others, which might cascade out to several others as well.

Do you understand why solving crossword puzzles isn't "just typing", and why it's faster if you have partners and reference materials? Do you understand why you might spend more time thinking than writing, and why sometimes you need to walk away from it for a few minutes if you're ever going to complete it? Then you probably understand programming well enough.

Where's Tim

2010-12-13T10:06:00.000-08:00

I've been quite busy of late, partly with holiday season, partly with medical matters (wife's ankle surgery), partly with church, partly with Agile In A Flash, and partly with the series of articles Jeff and I are writing for PragProg.

Last month's PragProg article brought some good feedback and kind words from some of you and we're thankful. We have two more "big topic" articles to go (abstraction and volatility) and then we're back to the stories behind the AgileInAFlash cards (on pre-order via online outlets and expected in January). Please keep up with us there as well as here and at Agile In A Flash.

I'm looking at some new projects next year, hopefully some that pay and some that allow me to improve my chops on open source development. I don't foresee another book just yet, but some writing is definitely in the works.

The only other news is that I dived into Ruby for a little while, and will be chasing that down via the three books I now own. I'll likely be playing with IronPython and other CLR languages this coming year, and I still have to get some Javascript skills together.

It has been a great year, and I expect next year to be greater yet. Stay tuned.

Under Test

2010-11-03T21:21:00.003-07:00

Today I was thinking about the phrase "under test" as in "we've got to get this code under test so we can fix it."

I started of thinking about the way the app we were discussing was laid out. There was (at rock bottom) some persistence stuff. Above that was (on one side) reporting and query, and on the other was some business objects. Above the business objects are some model-like objects (sometimes) and above those are UI-related code.

Starting at the "top", with UI presentation, we can test through a browser. That makes it the territory of human by-hand testing and also of browser emulators, browser drivers, and screen-scrapers. Such tests are going to exercise a fully-integrated system, and can be slow due to many features such as database access, file system access, network access to services, etc. Human testing is particularly slow, as it involves reading time, typing time, and time to evaluate results. Human tests we can measure in minutes per test. The automated tests are much faster, but we might be able to measure single-threaded testing in dozens per minute. There is a practical limit to how many of these slow tests we can tolerate. Human testing is most expensive and slow, so hundreds of thousands of tests per week is not reasonable, let alone per day. Human testing can be reserved for the areas requiring special, creative, intelligent effort.

Under the UI layer are code-behind classes, which are testable via normal unit testing techniques. The tests won't be very interesting, but mocking and dependency injection can make them crazy fast. We could have many thousands of these trivial tests, and they could run in tiny fractions of a second each. We could tolerate a lot of tests here without feeling like our development is dragged down. We can afford the tests to be plentiful and trivial.

Classes that show good cohesion will have some kind of Model class under them, allowing for an alternative UI like fitnesse or cucumber. The AT framework will take up some time in overhead, but hundreds of test steps per second are still possible, and tests can relatively straightforward to write. We can make many tests and tolerate hundreds of them before it becomes too expensive and they are pushed offline to the CI system. Badly written tests can be hard to write and very slow to write, and are not uncommon. These hasten the day when running "all the tests" is too frustrating for developers.

Using mocking, we can do a lot of tests on the Model classes, crazy fast. Model layer tests might be some of the more important tests we run, as they ensure that the code behind the interfaces is sound. This is a great place for us to load up on fast unit tests. We should measure their execution in thousands per second.

Under Models are the business objects, which can be tested with normal unit testing techniques, and many thousands of tests can run in just a few seconds (if we can keep the database out of it). This is an area where we need a lot of tests, and can easily afford to run them all many times per day.

Queries and reports are a different story. We can write tests for them, but we can't tolerate the cost and expense of sitting around waiting for them. Reports are particularly rough, as there are going to be some onerous setup requirements for those. We're probably going to run them in CI and also maybe just once before pushing code to the CI system if we are diligent workers and think we might have affected them.

So what's the point? With this in mind, consider what "under test" means. Testing is arranged in layers from the top of the system to the bottom. Code in the UI is up high, not "under" many tests. It may not be tested very well at all, depending on how thorough the UI tests are and which ones the human testers choose to run. It's sketchy.

So if a system has code making decisions in the HTML templating system, that code is barely under test at all and may never be safely under test. Changes there will always be dangerous. Changes to the code-behind only slightly less so. If there is a model layer, though, it starts to look pretty healthy. The business objects, are under their own unit tests, the model layer's tests, and the UI tests. They have a thick blanket of protection, and can be refactored with relative impunity.

Get it? "Under Test" is all about confidence to make changes. Code in higher layers is under fewer tests, so code needs to be extracted and moved downward, downward, downward until it is just high enough above the persistence layer to be tested quickly and well. Get it "under the tests."

C# Curiously Nested Production Class

2010-10-12T06:08:00.000-07:00

We tackled some code for refactoring, and I found an unusual construct. To wit:

public class Base: Many, Varied, Bases {
    private int x;
    
    // ...

    public class Derived: Base {
        public setX(int value) { 
            x = value;
        }
    }

    // ...
}

So here we have the derived class nested in its base class. I am quite comfortable with nested anythings in python or a few other languages, so that's not a problem. I nest 'testable' classes in tests all the time so I can override or stub a few methods. In python it's a normal way of life to nest functions and classes.

This one is odd because it is a production class, nested inside a production class, and deriving from its outer class. It makes me think of a pregnant female, having a child inside it whose dna derives from the mother.

So what powers does this odd nesting convey? My first thought is that it is some kind of closure, but this turns out to be false. There is no real closure involved. The whole closure that derives from the parent made my head swim just a bit, but it is a wild goose chase. Nothing to it.

What does happen is that the nesting bestows readability on the private variables inherited from the enclosing parent. The x in the setX is the Derived.x inherited from Base. It is referencing its own variable, even though that variable is private instead of protected in the parent. Indeed, resharper refused to move the class to an outer scope because its own variables would become unreachable to its own methods. To do that extraction, we made the variables protected in the parent.

The other thing that it did was hide the class from an automated test program. These classes are both code-behind for web pages. We have an automated tool that searches the namespace for all classes derived from our base web component class and ensures that they all have page generation tests. This one did not.

I am wondering if there is some interesting way to use this like a private interface class in C++ or Java. It was curious, but I'm wondering if it can't also be useful.

Explaining Refactoring

2010-10-08T21:05:00.000-07:00

I recently collected up some information from Jira and git about our software process.

I am mulling over an idea, and a little feedback is welcome. To help understand the context, among our products we have one codebase that was originally written pre-agile in a non-TDDed manner but greatly improved during and after the company's agile transition. It is pretty good stuff, and constantly improving in quality and functionality, consistently delivering real value to customers. We're pretty of proud of it and its future. There is a great team working on it. Sometimes, though, we find the need for a large-scale refactoring somewhere in the code base, and we have the courage to tackle these.

Basically the problem is that refactoring sounds bad to product managers. When it's done well, there is no visible difference in the code. When it isn't done perfectly, it injects defects. The obvious knee-jerk reaction is to resist any large-scale refactoring efforts.

As an aside: refactoring ought to be invisible. It should be part of every task, and not a task on its own. If a system is built ground-up using TDD then no "refactoring tasks" should appear in release notes and no "refactoring tickets" need be filed. Sometimes, however, there is legacy code with significant technical debt or significant code cruft in new code. That ugliness might be in key areas of the application. Sometimes it is worthwhile to dedicate time to bringing a piece of code under control of tests. Even so, if people outside of your development team are aware of refactoring it is because something is wrong somewhere. It is a process smell.

Of course the product manager is right about the risk of large-scale refactorings and also about the lack of end-user value from effective efforts. What is missing is an understanding of the value of improvements to code virtues, maintainability, and leverage. Product managers don't see code.

Refactoring done well speeds code changes. The reward is that we are able to sustainably produce more features faster, with better quality. The punishment for not refactoring is that the code becomes continually worse and changes become slower and more defective. We need continual refactoring and testing, and sometimes we need some an initial "boost" to areas that are hard to test. This is only obvious to people who are elbows-deep in the code, and product managers don't see code.

Since indeed cleaning up ugly code is somewhat risky, we technical people should have a solid means to judge whether any large-scale effort is truly worth doing. Otherwise we may waste many weeks on a crazy "ugly code" witch hunt without significantly improving the fluidity of development. The product managers don't want that, and neither do we.

Product managers see a bug here, a flaw there, a new bit of functionality, a slipped date, a funky side-effect here and there, all disconnected. They can't see the problems in the code because they can't see code. Some of them don't even believe that the technical problems really exist because it sounds like programmers are just making excuses.

I hacked together a simple similarity comparison of the text of our Jira tickets and compared them to code change records for those tickets. My efforts met with great disappointment. Two similarly-described bugs may not involve the same code at all. Conversely, if I show the tickets whose resolutions do involve the same file, non-programmers strain to see any commonality between them.

While product managers see only holes. programmers see only gophers. If product managers could see which set of bugs are connected to which source code files then they might demand remediation, but only for the code that really effects delivery and quality. At least in a rational world there would be such a level of data-based decision-making.

One answer may be to have the product managers work in the code, but I doubt that coaches will often be successful with this strategy. Instead, we may need a better way to illustrate the underlying connections.

This is where the heat map comes in, but it was written from a programmer's point of view. As a step in a new direction, I coded up a report to list the tickets for any given file. Maybe in the coming weeks I can convert the data to a form that product managers can see and digest without becoming programmers first.

If you have any interesting ideas for further research or credible presentation of this data, drop me a comment below. I'd love to walk in some day with a new way for my partners who are product managers to understand our work so that technical debt remediation can be properly assessed and prioritized. I'll settle for better criteria on which to base my choice of large-scale refactoring efforts.

It's a good dream. Waiting for your comments.

Heatmap: The new hotness

2010-10-08T20:08:00.000-07:00

I had some fun recently after agonizing over the problem of bug prevention. I put out the observation that bugs have a tendency to cluster, and that the more often code is edited the greater the need for the code to be frightfully virtuous, clean, and thoroughly tested. The problem was with determining which code should be cleaned up in order to reduce the injection of bugs.

I considered various metrics and measurements, including cyclomatic complexity, code duplication, and various design details, but ultimately dismissed them for fear that they would be unconvincing. I didn't want my audience to think the heat maps is just "coach Tim lecturing." In keeping with our description of effective information radiators we needed the information to be simple and stark.

Our SCM is based on git, and our tracking software is Jira. We have to include a recognizable, open, Jira ticket id in every code commit. Many of the tickets are enhancements, improvements, or investigations. Some are problems with legacy data or data import, and some are defects. Tickets are associated with releases, and the release dates are in the database as custom fields. I decided to count tickets, and not commits. We commit frequently, and some more frequently than others. Counting commits would be mostly noise, but counting tickets seemed like a pretty good idea.

I fired up python and grabbed a partner. By using the PyGit library, we were able to parse all the git commits, collect ticket numbers, and parse the diffs to find the names of all files touched in the commit. I tossed together a shelf (bdb) of file names to ticket numbers.

Next I pulled down SOAPpy and my Jira-smart partner helped me build a Jira query. We pulled down the tickets and created another handy shelf, including the ticket number as a key and key facts like the descriptions, summaries, a defect indicator for defect tickets, and release numbers with dates.

Finally we walked through all of the tickets and ordered them by release date. I guess that's pretty coarse-grained, but it makes sense to keep it pegged to recognizable events. Releases have more data available (BOMs, release notes, etc) in case we need to dive deeper.

So then we get the fudgy part. A file that doesn't get any activity is not very interesting. It may be good or bad, tested or untested, clean or filthy, DRY or very non-dry, but nobody is messing with it so we can ignore it for a while. On the other hand, the more a file is touched, the more important it is that the file is easy to work with.

We don't have any information about which file(s) contained a defect, only the set of files that were touched while resolving the defect. That rightfully includes any tests, flawed files, test utilities improved, and any other source files touched by renames or other refactorings. The more often a file is updated in the resolution of a defects, the closer it probably is to the problem file. I needed to weight activity related to defects much more highly than activity related to non-defect tickets.

As a rough heat map metric, I took the total tickets for a period and added back the total defects * 2, counting each defect three times effectively. That just feels about right to me and my partners. If I have two updates to one file with no defects, the code might not need much preventative maintenance. If I have two defects in one release then definitely needs some love. I came up with a ranking and graphed the top five files.

That left me with a jittery graph, so I decided to use a longer period, which I settled on being 3 releases. The January release "heat index" (heh) is based on November through January, and the February heat index is December through February. It gives us a smoother graph, but may not be the smartest way to smooth it. It is simple, though, and that counts for something.

The top five files were pretty interesting. When I looked over it with a production support (triage) person, the files were very familiar to them. A manager-type remembered the defects associated with them quite well. A features programmer told me that these files really were troublesome. Some files had been remedied by dedicated refactoring and testing time, and we could see how those files had lost 'heat' over the period of a year. Other files were trending upward in heat, because of a combination of discovered defects and being in a functional area that is seeing a lot of expansion.

We checked out the top two files which were trending hotter and found that they had low unit test coverage. We suspect a connection there.

The interesting parts of this experiment (to me) were:
1) We closed a feedback loop (request->code->release->defect report->code)
2) The metric is not based on my ideas of quality, just historic fact. so the answers are credible
3) There is so much more we can do with this data. More on that later.

This is the new hotness, and it is presented as an information radiator in the bullpen area. We are all "hot" on the idea of testing and refactoring these files, so hopefully we'll see some marked improvement over the next few releases.

Tests Are Code

2010-10-01T09:17:00.001-07:00

I write an automated acceptance test (AT) and I find that I would like to perform certain actions against the business objects. I create a method on the business objects and my test stays slim while my model builds up more functions.

So, there is potentially code in the production system that is only used in the tests. The debate today is whether that is "unnecessary bulk that solves no business need" or is instead "first-class code."

I am betting that the code you need in the AT is code you probably also needed in the UI and/or APIs to external clients. I am supposing that it is needed in the test because it is likely written into the UIs instead of the model and so the tests' logic is duplication. I also think that even a reasonably poorly-written test is written to support business rules. Therefore, the tests express business logic so methods required by the tests are methods required by business. While some worry that a method on a business object might be picked up and used by a programmer in the production code, I hope that this is true.

Your opinion matters, so feel free to leave a comment.

Pair Switching Degrades over Time

2010-09-10T12:09:00.000-07:00

We had a nice talk today about the natural foot-dragging that is common among pair programmers when it comes time to switch partners.

It's not really social, as in partners gravitating to each other as buddies. Instead it tends to be more work-related.
It does feel socially awkward to tell your partner you want to go work with someone else now.
It sometimes does happen that partners who are gung-ho agilists will prefer working together. They prefer partners who allow them to do their work well and will improve them over those who create drag by arguing against testing or refactoring.
People get comfortable in a particular task and want to see it through. This is a good feature usually, and certainly is favorable for people who do individual, non-paired work. In an agile team, it's limiting. Someone needs to move on so that there are more eyes/hands/minds in the code.
If there is no standup there is no pair switching. If the team relies on assignment from a manager (totally non-agile) then teams tend to complete tasks at different times. This means that no two pairs are finished at the same time, so any switching requires interrupting at least one pair.
Everyone wants to work in the "cool" stuff, but each person has their own definition of "cool." People will gravitate to tasks in the areas that excite them, and don't want to leave that work to do something else with a different partner.
People are nervous in work that they don't understand well. Rather than eagerly gaining experience in all areas of the app, they try to stay in an area where they have knowledge and leadership. Switching partners may take them into areas they don't understand.

I'd like to open this up to a larger conversation with agile and becoming-agile and surviving-as-non-agilist-on-agile-team people. Why is it that you don't want to switch three or four times a day?

Where is the Agile Otter?

2010-09-01T10:16:00.001-07:00

I've been developing new skills, and working with Jeff on the AgileInAFlash project.

What's new? Our latest article for Pragmatic Programmers.

Copy And Edit Revisited

2010-07-16T12:25:00.000-07:00

Vadim reminds me that I need to address root causes of Copy-Paste-Edit programming, rather than merely ranting about how bad a practice it is and how it ruins good code. Of course, he is right. That is part of being Vadim.

I've previously ranted about the ill-effects of copy-paste-edit programming, but it would be unfair to say that there is never a need for it, or that people who did it were simply stupid and lazy. The problem would not be so prevalent if it did not have some reasonable basis for practice. However well-intentioned and useful it is, its net effect on a code base is overwhelming negative.

Here are a few root causes I recognize, and I'm open to hear more.

Tedious construction semantics encourage copying. Many APIs are very thin access to bean-like objects, and yet using them correctly can be a trick. You have to know what to set, and in what order, and what to call next. It is far easier to copy a correctly-set-up object use than to make one from scratch.
Copied code is a working initial state from which to make progress. This is useful not only when dealing with complicated code in the current system, but is especially true and especially beneficial when copying code examples from docs, books, or online code repositories.
Complex multi-line operations have many ways to break. If the system shows poor cohesion or has multiple ways of doing the same job (and some ways work better than others) then copying a usage that works seems pretty safe. It is worse when the API has a "seed and harvest" interface, where one must set certain variables (seeding), then call a function, then collect the results from various variables (sometimes the same ones, sometimes not).
Copying minimizes the chance of breaking existing code, which is the primary fear in legacy systems. If some (or most) code is ill-tested, then any editing of existing code can fail in unexpected ways. Copying an algorithm and changing the variable names to match the local context preserves the original code.
It is easier to copy than to study. Copying code that pretty much works now, you can make minimal changes and hopefully it will work without you having to understand the underlying concerns. It allows you to get in and out quickly without doing research. Copy/paste creates a point in time at which it is basically sound, and can be refactored to purpose.
Moving code into functions requires thinking about design. Is it one method or several? To which class does it belong? The original owner of the code? The new code? A class currently used by both? A new class? An existing library?

Is copying always wrong? I think it is not. The act of copying itself should kick in your "spider sense," but it is not necessarily harmful. Copying examples from outside the system might be useful as a starting point. Copying code from inside the system (including copying an existing test to help create a new test) can be helpful to the programmer. However, having duplicated code in the system is always wrong, and having code that is placed badly is wrong as well.

It could be useful to put some rules around your use of copying.

Don't leave duplicated code in the system. If you copy, consider your copy to be merely a starting point, and also point of technical debt. Pay it off quickly by refactoring the duplication out of existance as soon as possible.
Even when you write unique code, extract methods and move them to their most appropriate class, so methods can be called instead of copied next time. If you leave manipulations in the user of a class, you are encouraging the next user of that functionality to copy it as well.
If the code is ugly enough (complex intialization, multi-step operations), extract the non-unique parts as new methods called from both copies. Interfaces do not have to be ugly and complex.
When you find duplication, or create duplication, finish your refactoring step by sweeping the code base for other copies, and correct them likewise. It doesn't help if two versions out of a dozen are refactored. You want the whole system to improve as you work.
Copying might not be so bad if you refactor the area you're copying from and move the extracted methods to appropriate new homes. Copying one or two function calls might not hurt you like copying blocks of code.

Everything I said about the evils of copying code still stand. If you copy a block of code, you are probably going to screw over your whole development organization a little (especially when the system changes and your original is no longer correct). Copy-Edit is still the way to make a bloated mess of your system.

Stop Playing Catch And Release In Quadrant 4.

2010-07-09T10:52:00.000-07:00

Basically, a bug is a combination of a design flaw and a testing gap.

When I say design, I mean "design-as-written", not some keen plan that some keen mind build in some expensive drawing too. I mean the logic of the system. Built code can be said to have a design, in that it is intended to work in a particular way and has been adjusted to work in real circumstances. A non-coding architect's idea for a system is not a design. It is merely a guess, or perhaps a dream.

If code has a perfect design for a given set of tradeoffs, then it will work perfectly for that given set of tradeoffs. If it must run on windows and use sql server, then it will work as well as possible under those conditions. It may fail because of supporting systems, or because IE/ISS ate all the cpu and ram, or because it is interrupted, or starved out by virus checkers, etc. For where it lives, and what it does, it will work great... provided the code is written to use the design.

Side note: I'm not saying that a design can be devised up front that will be perfect, or even that a design can be evolved to perfection (necessarily). I do not think that a perfect design is possible when working in a waterfall manner, and am firmly convinced that "perfect" is a concept that wiggles -- it changes meaning as a system and its environment evolve. If there are ever moments of perfection in design, they are brought about through incremental change, and are eventually spoiled by changing requirements and systems. But bear with me, and assume that there are possible moments of perfection.

Perfect test coverage would be an automated suite of tests that exercise and evaluate every possible behavior of a software system. That would be every logic branch of every component of the system under every set of circumstances. It doesn't happen in practice, but that's not because it's impossible but because it is costly.

If perfect test coverage and perfect design are not possible, it is mainly because we don't know how to do them in a cost-effective manner. As a result, users are comfortable with a certain amount of slop provided it does not prevent them from getting work done and living meaningful lives. Some users are used to more slop than others, since some will reboot their machines a few times a day and others scream if they have to reboot once a year. Some will retry a task in several different ways, others will throw up their hands. Bugs are tolerated if their frequency and consequence are slight.

So lets draw this an an extreme set of opposites, in a quadrant. Realize that most code is either mostly tested or mostly untested, and either good or not-so-good, but a discussion of extremes helps to clarfiy our thinking about software defects.

	Tested	NotTested
Perfect	1	2
Imperfect	3	4

Quadrant 1 (tested, perfect) code is as good as it gets. Q1 code is blameless. Though the system around it may misbehave and cause ill effects, Q1 code does the best possible job in its environment. All code wants to be Q1 code, and all users want to think they're purchasing an all-Q1 system. All programmers would prefer to work in a Q1 system, because it is easier and more rewarding to do so. This is the holy grail, but is rare due to perfectly legitimate organizational priorities that prevent the creation of such perfect systems. Sometimes customers and markets don't *really* want perfect systems, if it means not having some other feature that is attractive. Tradeoffs are made.

In Quadrant 2 (untested, perfect code) there are no currently-known defects and the system seems to operate perfectly. This is a mysterious place to be, because defects can arise at any time since the software system and its business and technical environments will change over time. When defects appear in quadrant 2 they will be discovered in the wild, not in the lab. Q2 is comprised of code that is at risk. The best we can say of supposed Q2 code is that it has not yet proven to be Q4 code.

Quadrant 3 is comprised of discovered defects. Some of these will be fixed before release, and those whose effect and frequency are slight may be deferred to future releases. Tests on known bugs-of-little-effect will tend to be ignored or disabled (effectively moving the defect to Q4) until the flaw becomes interesting enough to resolve.

Quadrant 4 primarily is the result of irresponsible development or intentionally ignored known defects (see Q3). The design flaws are not well-understood or demonstrated in automated tests. Running code that is imperfect and untested is rather a crapshoot. Users are essentially alpha testers, and should not expect consistently good experiences. Trying to fix defects in Q4 code is a nightmare and fraught with disappointment. The best way to fix Q4 code is to move it first to Q3, then try to move it to Q1. The worst way to fix it is to try to push it up into Q2.

Almost all software systems in existence have some Quadrant 4 code and some Quadrant 3 code. TDD systems are mostly Q1 and Q3, but legacy systems all have some Q4 code and might have some Q2 code (not that we could tell).

Software that doesn't work is in Q4. If you have hundreds of bug reports, then you have hundreds of lines of code in Q4, where it's not very good code and you don't have good testing. Your bugs tell you that your code base needs some unit testing goodness applied. If you simply fix the bugs without putting testing around the site of the defect, you are playing catch-and-release in Q4 and nothing is really going to get better for your product or your organization.

The goal for software developers should be to move code from Q2 and Q4 through Q3 to Q1. I can see hardly any reason why developers in 2010 would even consider working in Q2/Q4, and I particularly cannot see why organizations would believe that group of people with mixed experience and skill sets would consistently perform in Q2.

Q2 is essentially a myth. Your Q2 software is probably Q4 in reality. Maybe you should start investing in the move to Q3. Stop playing catch-and-release

Two Year In, Looking for the Goodies

2010-06-24T18:16:00.000-07:00

This week I wrote a useful utility and taught some Python to a peer, attended a really great work session and a rough estimating session. I did some WIP management activities with my team, I broke the application, I worked with some awesome partners, went on a bit of a refactoring binge, devised (with partner) a grand strategy, and got stuck on tiny little problems I couldn't see over. This has been an awesome week.

We have been doing some big refactorings, moving big and critical chunks from one module to another, and dealing with the fallout. I don't know how to tell you how important the tests in our code base have been. I would have spent all day lost without them. We would move a component, build, resolve build troubles, rinse and repeat. Finally, at end of day, I got all unit tests and fitnesse tests turning green, EXCEPT for a few that won't test because they do horrible things and need remediation. When our tests failed, it was not because the tests were bad (exception, one was pretty iffy) but because something was wrong. The compiler and tests made our work less scary and troubling. It was still scary and troubling, but would have been overwhelming otherwise.

I and some of my colleagues transitioned this team to Agile only 2 years ago. It is amazing how deeply some of the team members grok Agile now, and a little frustrating how some people and some circumstances have not really come up to the same level. Frustration is not failure, though. There is light bursting through here and there.

I've also been checking in as a coach, testing the prevailing winds, looking for the problems that keep us down, looking for the ways to improve our work system, looking for moods issues. We're in a pretty good place, actually, by numeric measures. Some parts of the code base are very well-tested and quite simple, and others are becoming so. There is still some amount of legacy code produced every day, though, and that is a bit disheartening to those who really want to see only improvement (I'll cop to being one of them).

Our biggest challenge is that there is some big work coming to some ticklish areas of the code, and we'll be under pressure to deliver. This is our first real chance to test our Agile mettle against a really formidable foe.

Jeff and I just released the "Why Agile" card at AgileInAFlash. Two years into the transition, I want to make some comparisons on how we rate today v the original situation.

Improve Customer Involvement has improved the least. We have a great guy playing the role of Customer, but largely the representatives for the customer don't join the team. Some of them have found more engaging ways to provide specs (screenshots, videos, etc), and have made themselves more available for discussion. It is still not what it could be. With one notable exception, our Customer players are all surrogates. All but one of the surrogates live on the other side of the building, across a hallway from the developers, and are not really involved in daily work. This is actually a problem that affects morale and development performance. Finding a way to bring us all together would bring profound changes to the product, I have no doubt.

Increase Quality has come a long, long way. Like any SAAS player we always want better performance, and like any SMB growing larger we have a few issues from time to time, but overall quality is way up and the testing practices are better all the time. When I ask product management or sales or support, they tell me that it is a whole different world from the product of 2008. We haven't reached the "everybody loves us" stage yet, but we have come a long way.

Simplify Releases is happening. They used to have nightmares about release nights, and now they're more like annoyances. We still have code freeze and pre-release ceremonies, but we're not 100% covered in tests yet, and we put a lot of features in each month. We will continue to need some regression testing and some exploratory testing for a while yet. Issues that made code hard to deploy keep getting eliminated. It's a new world compared to our starting position.

Increase Operational Awareness this one hasn't come so far. We don't have the information radiators I would like to see, but the card wall is being used, and people tend to have a pretty good sense of what is in progress, finished, or unstarted. The big priorities are posted on pillars and doors so we can see them. Stand-up meetings help us keep track of each other. It could be better, but it is a good start. Actually, the operations staff have herereally smoked us in this regard. We know more about servers and their problems than ever before. We have moving graphs and charts updating constantly on large-screen displays in the office. There are alerts in email, and people stopping by the developer pairing stations. They're doing a tremendous job.

Drive Down Risk could be better. We tend to fall back to producing whole big features, rather than staying incremental as we should. I know, breaking down stories into valuable verticals is tough business, but all-or-nothing leaves a strong chance of "nothing." Our demos do collect feedback, and often are valuable working sessions (ours was this week). Testing and pairing also help reduce developer myopia and its resulting code diseases. But still, we're not incremental as we should be, and that leaves us at risk more often than I'd like.

Reconnect With Geek Joy is there, but we still wrestle with this. Sometimes we don't feel better, even though we are better. A times wrestling with legacy code (even new legacy code) frustrates us. Sometimes we don't have the level of success we might like. Yet I am so encouraged when we can do big things under sufficient tests, and when we find people making far-ranging improvements, when we have consensus on big design changes, and when we demonstrate working code. There is energy around performance and quality. We enjoy solving problems, and we enjoy cleaning code, and we take pride in not leaving silly duplication behind. I enjoy this job, and am happy to be doing it. We are making a difference to each other and serving customers as better than we could before. This job improves me, and that's joyful.

I know, my readers may want to hear how I totally transformed the company and how all of our problems vanished in 6 weeks or less, but that's not always how it goes. Real change takes time, and not everyone "gets it" all at the same time. New hires, old cliques, old barriers, old policies, old politics, new features, new customers, and new technology keep things challenging. Pressure to release pushes people back into old bad habits. There is a swirling cloud of chaos, but it keeps moving in a desirable direction overall.

Maybe we're still struggling a bit, but that's what growth is like. Watch this space. Maybe next year I'll show you how much further we've come.

Do You Want Us To Think Or Not?

2010-06-22T19:29:00.000-07:00

To make software, you need people who are skilled, creative, quick-learning, thoughtful, and engaged. You might be able to skimp on 'skilled' if the rest of your team provides a social learning system (via pair programming, test-driven development, book and link sharing, impromptu teaching, design talks, etc). You cannot really skimp on the characteristics of being creative, thoughtful, and engaged.

If you tell someone that you don't care how they feel, they will work in an unfeeling way. If you tell them that you don't care what they think, they will work unthinkingly. If you tell them not to participate, they will disengage. This (IMHO) is why use of corporate software is so often without soul and without joy. If one self-important side tells the other to shut up, or to stop asking questions, or to leave the decision-making process, then he has switched off an important piece of capital equipment.

If you treat a knowledge worker as a drudge, she will turn off her brain and trudge. Unsurprisingly, she will lose energy, become uncaring toward the product, and start phoning in her minimal-thought hacks while polishing off her resume. It is hard to keep good people in a system that doesn't really value them.

In an Agile company, we expect customers (or a reliable surrogate) to team up with developers. We expect to have a two-way flow of communication. Each side asks questions, provides answers, researches, considers. Each side teaches and learns. In time the whole team (customers+developers) will take on creative problem-solving, will improve the user experience, will make the product data-center-friendly and user-friendly, and will produce truly valuable work.

All of the software development roles are creative. All of them have issues and difficulties that the other roles may not understand initially. But if we're going to do good work, we have to learn to listen to each other. All it takes to destroy the magic is for one to devalue the contributions of the other.

A few resources:
From Agile Software Development, an article on respect.
Esther Derby's Stop Demotivating Me from CIO magazine.
Daniel Pink's talk via my blog.

Meddling, Oversight, and Agile, Oh My!

2010-06-18T13:09:00.000-07:00

A friend of mine (Hi George D) suggested that this would make a good poster,
but all I have is a couple of blogs, so here is the message that inspired
my buddy.

My experience is that the less well a team has done in the past,
the more oversight is piled on, and that oversight reaches higher
and higher levels. There really is no legitimate reason for the
CEO to want to know which programmer 5 or more levels below was
assigned to a particular task and if he's behind schedule by a
week or so.

In healthier organizations, the groups and managers that interface
with the development group tend not to have the same meddlesome urges.

In our transitions, the biggest problem we face tends to be peeling
back the expensive and unnecessary oversight. If the team can be
rebooted and work with a single stream of smaller, simpler stories
(rest of agile practices included) then they can win over the
rest of the org in relatively short order. Sometimes in only a
year or two, sometimes in less than 6 months.

It's hard to overcome meddlesome urges, especially when they are in
reaction to difficult past history (and moreso if there is competition
among the meddlers to get their work done).

Tools play into that. People want tools partly so that they can
pile on too much work (more than fits in a head or on a board)
and partly so that they can meddle from the comfort of a remote
office.

Agile is, among other things, a very intense and orderly way to
get work done. It's just hard to get the focus of a conflicted
organization on getting work done in an intense and orderly way.

Only Quality Matters

2010-06-18T08:10:00.000-07:00

If your code doesn't really work, then it doesn't matter how quickly you wrote it.

Abandoning quality in pursuit of speed is a fool's errand. It has been discussed plenty of times in about any management book you want to look at, and especially by the brilliant minds like Deming.

If you write your code badly, you can release it without awareness of bugs, and that takes it off of your plate. You may be rewarded or recognized for your quick work. It feels good today. Your team is recognized for being heroes within the company because you are smart, and get things done.

But tomorrow a customer tries to use it and it fails. The customer is no longer happy that the feature was delivered, because it's junk. In fact, as far as the customer is concerned the whole product is now junk, your company is junk, and the developers are pure rubbish. Loss of good will. Think how you feel when you get the Fail Whale, and you are a friendly customer and unusually forgiving. How do you feel when your cable provider or cell phone service has a hiccup, or when your windows mobile phone has to be rebooted. Normal people are much less forgiving.

Now that failure is reported (if you're lucky) and someone in product support hears about it. They feel less proud of their affiliation. They push to get a change made, but the programmers 1) are busy on something else, and 2) take a long time to find the bug. The product support queue grows. People are employed now to track mistakes and to try to run interference with unhappy customers.

The failure isn't just reported to the vendor, but to all the customer's bosses, who begin to question their vendor relationships. A few bugs now and then, they might be able to tolerate. but constant performance and behavioral bugs will have them holding the contract in one hand and a lighter in the other.

People are employed to fix the bugs, and to test the code to be sure the bug is gone. A few tests written TDD-style would have saved a lot of work, money, and hard feelings. But you were in a hurry.

If the code doesn't really work, then it does not matter how quickly you wrote it.

Software Like Building A House

2010-06-15T14:46:00.001-07:00

After arguing for decades that it is not so, I find out that I'm wrong. This is from a 2007 article on construction.

1. If it takes six months to build a house, then 85 percent of the time is spent on two activities: waiting on the next trade to show up and fixing mistakes.

2. Clemson's Professor Roger Liska conducted an analysis of productivity on the construction industry and found that the average construction worker operates at only 40 percent efficiency.

3. Critical shortages exist in qualified, skilled workers and labor issue futurist Roger Herman predicts the situation is only going to get worse.

4. Business Week's 2007 Investment Outlook Report indicates the return on equity (ROE) for all U.S. industries is 17.9 percent, while the ROE for the construction industry is a mere 9.7 percent, despite the recent construction boom.

5. Industry customers are frustrated with poor quality, confrontation, excessive change orders in quantity and dollar value, scheduling delays and litigation.

Your Reward System Doesn't Work

2010-06-10T14:42:00.000-07:00

Presented in the most pleasant way possible, by Daniel Pink & friends:

The whole "purpose maximizers" thing gives me hope in ways that "enlightened self interest" never, ever has.

Mocking Done Badly

2010-05-11T09:57:00.000-07:00

using(Playback) {
sut.PerformAction(parameter);
}

This is the last part of a common style of mock test. We see the system-under-test (sut) being asked to perform some action, and some parameter is passed to it. We know it's a mock test because of the Playback bit.
What is being tested here? Well something about PerformAction is being tested. Not much there. No clear assert written at the bottom of the test to capture our attention.
Let me narrate as I work through the actual code before me, and maybe the readers can respond to tell me whether this really is mocking done badly, or I'm "just not used to good mocking."

I struggle not to look at the test name, so the code can speak to me more directly.

The parameter is not interesting, it is just a string.
There is another variable, which is a stub, but it's not used inside playback.
There is a 'record' section, set aside with 'using' and not (thankfully) a #region.
In the record section, we call one function with the parameter string, returning the stub. So there is some kind of look-up method called exactly once. The string is the key, the stub is the result. Looks like database avoidance.
Another function is called, taking the stub returned by the first. It is called exactly once, and returns the number '2'.

At this point I've read the whole test. Hmmm... what are we doing here again?

Check the test name: ProcessExactlyOneFooWhenGivenParameterBar. Oh. So maybe the "Repeat.Once()" part of the mock is meaningful. But what's really going on?
I read the neighboring test (there is only one). It calls the same method with the parameter "all", and expects to see a call to a different method underneath, one that collects a list of things to process. Okay, "all" is a magic name that means 'do them all' and it collects the list. That helps a tiny bit. The name of that test reflects that my understanding is right, but I can't really follow the original test much better with that knowledge in hand.
The second-to-last desperate measure is called upon*: I read the code. This is backward. I should never read the production code to explain the test. I should read the tests to explain the production code. My assumptions hold so far.
The method for actually doing the processing is the one that is expected to be called once, and is to use the stub returned by a look-up method. The return code seems arbitrary. I extract it and call it "arbitraryRecordCount"
Some method renaming is done to make tests more meaningful. I double-check the production code to make sure it reads better too. As is usually the case, the code reads better.
Realize that the logging was redundant and ill-placed, and moved it to a unique and more appropriate spot. This simplifies production code even more, and all tests still pass.
I bring a bit more detail up into to the test in hopes that it will make it more clear. It does, but now I have more setup. There is an urge to break the mock setup into paragraphs, a sure sign I'm gathering cruft.
I realize there is a test missing, one that would have made more sense of some of one existing test. I add it. It duplicates the first test a bit. I extract a little, but worry about making it abstract enough that you can't really follow it.
I set up the original test to be a bit more explanatory.
It is at this point that I realize that the setup for this test fully simulates the sensing and acting of one pass through the SUT's method, if all IF statements are ignored/assumed. It is right, and having read the code I understand why it is right. I see the values threaded from one return to the next call, etc. I fear I've just proven that "IF" works in this language.
Now I see that processing involves doing one look-up, calling a method that does a more detailed look-up, and then using the latter look-up result to perform an update. I can see that this is what the code does by looking at the tests. It's rather non-abstract, and not remotely in business language.

I do have to wonder if they have any real value other than cementing the code's current implementation into the test suite. If we extract a method or inline a method, I know that these tests will fail. The new method will not be "incorrect", only "different." It bothers me that the tests will fail if I improve the structure of the SUT.
This is doing test-last, which is a poor way to do testing. That means it's most likely a poor way to do mocking. The tests are fast and decoupled from database, etc.
It takes much longer to write about this than to do it, yet I took the time so that there is some basis for discussion. Is my code conscience overly-sensitive, or does this have several kinds of wrong in it?
Is this mocking done well, or done poorly? You tell me.

* the last desperate measure is to trace execution with the debugger.

Making Stuff is Making Stuff

2010-05-02T15:06:00.000-07:00

On the television as I type this is a show called "Amazing Wedding Cakes", which is unsurprisingly about cake making. In the current episode a bride has ordered 190 individual single-serving cakes. The team is struggling with a trade-off between doing the work on time and doing the work really well.

We all do that. Software is so very much the same. We simply don't have time to obsess on every detail, but we also can't skimp on essential details. We need to make both radial and linear improvement, but we can't abandon our charter to deliver quality.

This has been a running meme this week, whether one can afford quality and whether skimping quality will help a team go faster. I've gone on record enough times saying that I don' think you go faster writing poor code, and I echo Uncle Bob Martin in saying that our most significant impediment is the bad code we have to work in.

In the end, the boss was pretty angry about the care that was taken with each of the cakes but the work was done on time with pretty high quality. The customers were delighted.

Of course, while that is a common story, the difference between cakes and software is that cake makers don't have to build all their other cakes by modifying the cake they've just made. If there is an internal defect in one of the mini-cakes, it won't cause the others to fail and it will not cause failures in all of the cakes they make in the future. Wedding cakes are a one-time thing. Software lasts and accrues changes.

That is not to talk down the cake industry. My wife makes cakes, and I know how much work goes into the structure, flavor, and aesthetics. It's a really cool and really competitive artistic industry.

The point is just that some things are short-term and highly visible, while others are more long-term and mostly invisible. If we treated cakes like a multi-year investment it would be silly, and it is similarly stupid to treat software as a bunch of one-off, short-term projects.

Linear and Radial Progress means Taking The Next Step

2010-04-28T21:51:00.000-07:00

Today we didn't make a lot of linear progress

I think of quality in two ways. One is the product quality which users perceive, and the other is the habitability of the code itself. One says whether the function points and UX are well-selected, and the other says whether it is worth your time to try to work in the code. One can have crap code that seems great externally, and one can have beautiful code that doesn't do anything a user is interested in doing (the popularly-presented dichotomy). Likewise one could have poor functionality written poorly, or great functionality written well. Those who consider themselves professionals or craftsmen will desire great functionally written well.

I often get to work in code that started out as good functionality badly written. I get to work on the teams that clean up the mess and make the system more useful, scalable, and performant. As we work, the code gathers external quality. It becomes increasingly virtuous. Smaller, simpler, cleaner code starts to run faster. With less duplication, bugs are fixed once-for-all rather than as buggy duplicates are discovered. This month is better than last month, but next month should be better still.

Because there are two kinds of quality, and one can make progress on either front, we see two kinds of progress. There is linear progress toward completion of a specific feature, and then there is radial progress which improves the code base overall and makes work easier for many colleagues.

Developers who make linear progress without radial progress ultimately drive code into an increasingly unliveable state. Eventually bugs are hard to resolve, changes are hard to make, testing is costly, refactoring is painful, and the design is more a collection of warts and hacks than a system any sane beings would have intentionally conceived.

Radial progress does not contribute much to one's ability to close a particular development request. Instead it improves the ability of the team to complete features next month and the months after that. It tends to affect many source files, so it is uneconomical in projects that don't have a significant investment in automated testing.

We made a lot of radial progress today.

We started with a change we wanted to make, but instead of slapdash hacking we took The Next Step and looked at the tests that covered the area of change. We found the unit tests were poorly written. These tests had poor fault isolation and failed for the wrong reasons. This prompted us to take The Next Step and make them less fragile so that they would stay 'green'.

From reverse-engineering the unit tests, we saw that the code under test was nigh indecipherable. It was riddled with poor naming, inconsistency, huge argument lists, lying comments, and slapdash implementation. Support routines did little to clarify the code, and in come cases further obscured its intent. Tests were fragile and indirect.

We decided to take The Next Step by refactoring some tests for readability. We replaced some loops with LINQ, after which it was obvious that the code had unnecessary looping. Each readability improvement showed some error in linear thinking that almost certainly slowed initial development of this part of the code base.

Writing bad tests is hard work. It would have been easier to write them better, or to refactor them as they went, but they were almost certainly more focused on making linear progress than on making the code clean. I can't really blame them. People under pressure cut corners and sometimes "it works" is all they think they can afford. People do the things that make them successful, and sometimes they are rewarded or punished for the wrong things. As is, it suffices to say that they did hard work the hard way, and so we found it in a poor state of development.

The more we introduced explanatory variables, simplified expressions, and eliminated duplication, the more we could see the next set of flaws to address. We took The Next Step and started reworking the test harness. Soon we find that there are variables being created and passed from routine-to-routine only to be ignored completely at the lower levels. We cleaned up the Object Mother utility, obviating hundreds (if not thousands) of unnecessary lines of code, and I suppose we should take The Next Step and remove the unnecessary code from the ObjectMother users.

This sounds like weeks of work, but was only hours. We closed one ticket, opened another, attended a long planning meeting and a lunch-and-learn. We took breaks for all the usual reasons. We broke up our pairing session at 5:00 CDT. We understand the code much better, and the tests explain the code better.

Sure, the code cleaning could turn into a few man-days of effort, but it is effort that will benefit everyone who wanders into this area of the code in the future. This area of the code base is being actively developed and has outstanding bugs, so we will likely recoup all our investment in the course of completing very few change requests. We are aware that we can't afford to spend time gold-plating this module, but we can make it habitable before we move on.

On the XP mailing list someone asked what distinguishes a truly great agile development team. Let me offer that the difference is that a great team will take The Next Step to make the code habitable on the inside in addition to making is useful externally. Because of this tendency, each month gets better, each quarter more productive. Each year, the system requires less patience of all those associated with it, and provides more rewards.

That, my friends, is great.

Accept changes, not interruptions.

2010-04-28T11:03:00.000-07:00

We say "embrace change" and "accept changes to requirements, even late in the process." We also rant about focus and that developers should neither be interrupted nor allowed to multitask. To a lot of people, this sounds just like a contradiction. Are we hypocrites?

There is no conflict in these statements. The problem is with the organization.

Change In A Change-Resistant Culture

If, for example, I plan a release in 10 months, and assign each of my developers a ten-month task (or a couple of five-month tasks) then I am not only at capacity, I'm likely well over and don't know it. Now, in month two I have a change I would like to see. I can't get any of my developers to put aside their work and take my task. Those stupid developers!! What's wrong with them? Nothing is wrong with them. They are doing the work they are assigned, and since they have no slack or reserve capacity they know that the new task puts their release in jeopardy. They also know that they are being reviewed, graded, rated, and ordered by their ability to get those assigned changes into the next release. If they drop a task to do the new work, they will fail. If they don't, then they'll be deemed uncooperative which also will possibly cause career damage. They can work overtime to do all the work that they were assigned (which is probably an ambitious goal anyway) and try to absorb the new change by stealing time from their significant others, sleep periods, side projects, and other obligations but this will make them less likely to recognize shoddy work and less eager to correct it. Assigning work this way creates a reserve-free system in which any response to any change is costly both professionally and personally. No wonder developers become demotivated.

Embracing Change In Healthy Organization

Instead, what if we have a release in 10 months (or so). We break all the features into pieces, where each piece is valuable to the end user, but each one can be completed in a week or two. Maybe there's an admin screen, a data entry screen, and a small bit of processing for the first feature. Rather than assign these to an individual (tying up his next few months), we assign it to the team as a whole. Now each of the people working on this feature will come "free" (ie. have completed a task) in a week or two. They will be able to switch pair programming partners, take on new features, make revisions, etc.

Now I can introduce changes between tasks, or instead of planned tasks. These task boundaries are frequent, so change is much more welcome. In addition, a developer is only committing to one change or feature at a time, and so only an uncompleted feature is at risk instead of the programmer's career.

In addition, the code for a completed feature is available much sooner, so that it can be tested, demonstrated, and evaluated. A few months in, it can even enter an alpha-testing program to get end-user feedback and determine the effect of the change on performance and scalability.

Smaller Assignments Are The Secret

If you can't accept change, it is because the work assignments are too large. If you are going to want changes often, then you need to have "change injection opportunities" more often. If changes are daily, then every day there should be some programmer(s) coming available to make the changes. Furthermore, they must be at work in a system that does not punish them (career-wise or by depriving them of the things they hold dear personally) for accepting orders for change.

You don't have to have an Agile organization or an Agile team to harness the power of smaller work assignments. There have been many methodologies, including some from very large contracting companies, who have long touted "a series of small successes" as the way to best ensure success of a project.

Early feedback is also known pre-Agile to be important to a good user experience and to dissolving contract discomfort.

The trouble is that working this way erodes the strong central authority many managers have enjoyed, and which may have brought them respect as "strong leaders" in the eyes of their managers. That is a topic for a whole different conversation.

If your development organization can't accept change without interruption and multitasking, then:

Your work assignments are too large, too personal, and too well enforced.

Be Careful What You Fix

2010-04-16T05:53:00.000-07:00

I wake up with odd memories. I think my brain is just getting exercise, staving off senility maybe.

Yesterday I woke with a memory of a bug fix from long ago, probably 15 years or more. I was given a project which led me into the permissions-checking code of a billing system. When I got there, I saw the code was written in such a way as:


   permission* perm = GetPermission(thisPerm);
   if ( perm != null && perm.Allow == false) {
       return false;
   }
   return true;

I know that's silly, but I am recreating from an old memory, and I remember the code having some silly uses of null & the like.

I remember noticing right away that if a permission did not exist, it meant that the user can perform the activity. GetPermission() read from a database table, I think, so that all a user had to do to get unlimited access was to drop records from a table. Furthermore, if an installation tech didn't deny access to unpaid features, the customer got them for free.

I don't want to reflect on the validity of the business model here, whether restricting features and paying for use of them is a good idea or whatever. It was a simple code error and a simple code fix to me and I only needed to know if the behavior was intended or accidental.

I quickly consulted some people who told me that it was not the right behavior. They said that some users had paid extra for features and would be angry if other customers were getting them for free. A little research, and we find that most customers had most features for free. As requested I fixed the feature so that having no permission meant having no feature. They figured that they were safe since they didn't ship documentation for features that weren't covered in the contract (security by obscurity). I had approval for the fix, and completed the ticket quickly, and you'd think that was the end of the story.

To the sales and marketing, however, it was a fiasco. After the next release there were angry people asking why they couldn't do their normal reporting and administrative tasks, why they couldn't do various normal feats that they could do only the week before with no issue. We had taken back from our users the features that we'd granted.

People did not rely on the manuals to tell them what the software did. That would be silly. Interfaces are rightly made explorable to people can learn it for themselves. Omitting docs did not lock down features.

Not testing the permission systems wasn't all that smart either, because nobody realized that it was "in promiscuous mode" until one of us programmers stumbled onto it.

Maybe the most damning error, though, was taking back what we had given. Whether they were entitled to the extra features or not, they'd had them. The genie was out of the bottle, the toothpaste sans tube. A technical correction was a marketplace error.

It was a decent lesson to learn, though I soaked the blame for screwing up the customers by fixing the code. I had permission, had talked it over, and had an approved ticket to fix it, but ultimately it was my fingers typing the code and my hands testing the correction, so I had to wear it.

I got in more trouble for fixing things than I ever did for breaking them. There's a lesson in that, too.

Full Test Access With Data Hiding for Production

2010-03-19T10:34:00.001-07:00

I'm talking to users of statically-typed languages today. Functional and dynamic language people, cut them some slack and realize I'm not talking to you.

Breaking with Conventional Wisdom

There are certainly Object-Oriented design pundits who will argue that you should never, ever have public variables in a class. The reason is good enough, that the object should be responsible for its own state. You should tell it to do things, and it should do them. Likewise you should not manipulate its variables for it, since that requires a strong understanding of valid states for the objects, and this understanding is a strong coupling. Strong couplings between classes are bad things. All of that wisdom is correct and proven.

However, many programmers make bean-ish objects where every private variable has a getter and a setter. This helps to preserve uniformity of access (you can't tell if it's calculated or stored, method or variable), but is otherwise the same as exposing public variables. When uniform access is important, this is a good practice.

The Proposal

When writing tests, data-hiding and uniformity of access are unhelpful. While many say that a class should be tested through the interface it uses in production, we still recognize that testing is improved when there is unimpeded access to a class. How often do you hear of people foregoing tests or adding a "testable" work-around simply because a method is declared protected or private?

There is a way to harmonize both the desire for object self-management and the need for testing with full access.

Some (hopefully most) classes are not built to be used directly by other classes, but through interfaces. A method outside of the interface does not exist to the classes that use the interface. This invisibility is "data hiding" and is a good thing. Private methods approximate this invisibility too well, making details of representation invisible to tests as well as to users.

If we program through interfaces, then we find that adding public methods to classes (not their interfaces) is a non-issue. We are without fear of programmers pillaging our object's state. The non-interface methods do not pop up in the code hints or code completion windows. They do not exist, and an attempt to call our public non-interface methods are compiler errors. We have the data hiding we need.

Tests will usually be working against concrete implementations, and are not tied to the small set of methods presented by the interface. Tests automatically have "privileged access" to methods outside the interface of the class. Data hiding therefore can exist alongside full test access.

Some classes inherit implementation from others. It's a code sharing mechanism with a long and storied history. These derived classes will have access to the public methods of their base classes. So test them well.

Side Effects

There is an additional advantage to all classes implementing interfaces, in that interfaces make it easy to build test doubles. Some languages have facilities for partial-mocking of classes, but an interface only makes the work easier.

Moreover, most statically-typed languages have IDEs with refactoring support, so that "extract interface" is a relatively trivial thing to do. If it is easy to make an interface, easy to use an interface, easy to mock an interface, and the interface effectively hides the interface used by testing, it is hard to understand why people do not use them more.

UI components are a useful class of objects used through interfaces. They are called by some kind of a UI framework, through interfaces it provides. The UI framework doesn't know your class from any other class. So why do the UI classes keep private methods and private variables? The only callers of the class cannot call them even if they were made public. If some other classes in the UI need to use a UI component, let it be used through an interface which constrains the set of usable class features.

Another instance of classes not needing private variables are test harnesses and test fixtures. Against whom are they protecting their private state? Against the test runners? Against production programmers? Against other tests? Horse feathers! There is no real need for tests to preserve their internals.

Sound Bite

IFF we program to interfaces, THEN private implementation variables and methods are not only redundant but also impede testing. Let's consider a little shift in our thinking if it will make our work easier.

Even simplified, it can be daunting

2010-03-12T08:03:00.000-08:00

SOLID design
FIRST-rate tests
Virtuous code

I understand the "just get it done mindset" because there is a lot of learning, thinking, and doing behind those three simple links. It is daunting. Any developer who can sling code could become considerably better at coding and more desirable as a teammate if he would learn and apply these concepts in his daily work, but it won't happen overnight.

Jeff and I built these 3x5 cards and simple explanations on the web site, but we don't pretend that you can live on these sound bites alone. The cards tell you what the words mean, and that's a good starting point (better than winging it), but the part that matters most is the part that won't fit on a card, the part where one practices.

I like the word "practice." Wherever you are writing code today, it is practice. You are expected to apply principled development and get better, but even if you are slap-dash hacking things together, you are building your mental habits and your reputation. You could have a reputation for overdesign, poor quality, quick hacks, and spaghetti coding. You could choose a reputation for steady progress, high quality, and code that makes next week's programming easier than this week's programming.

However daunting, it's doable. If we put a little of SOLID, FIRST, or the Virtues into our work today, we begin practicing principled development. This practice will deepen our understanding of principles and retrain our mental reflexes. Eventually our reputations will improve. We'll have some iffy moments along the way, but becoming a great programmer takes time.

The exciting part is that it can be done, we can do it, and a bunch of people have spent the time to outline it for us. This is what excites me about agile in a flash, where we can build references to the works of other software developers to further build our skills. Feel free to print some of the cards, post them in your workspace, and use them to retrain your programming habits. Drop us a line to let us know how it's going.

Even simplifed, it's daunting... but even daunting, it is the way forward.

When The Test Goes Green

2010-03-10T05:47:00.000-08:00

My assertion today is: If we would read the code we're writing, we wouldn't write the code we're writing.

We know the red->green->refactor cycle, but I find repeatedly that programmers are "optimizing" out that last step. It tends to run more like red->green->next. Perhaps there is confusion over what is supposed to happen when the test turns green.

The first thing that is supposed to happen is that you read the code you've just written to see if it makes any sense at all. While this sounds perfectly sensible, it often does not happen. Programming is not just typing. It is easy for programmers to rush to complete their assignments and never really examine their work.

I saw an example recently where the old code said:


    DateTime date = DateTime.Parse(datestring);

. As a minimal-perturbation change to push to green, the developer changed the code to say


   DateTime date = DateTime.Parse(DateTime.Now.ToString());

. Had he or his partner actually read that code they would have realized that it was a little silly, and replaced it with


  DateTime date = DateTime.Now;

However, I suspect that they never examined it past the green bar. It worked, and that is a virtue, but it was doing too much and the team would be totally embarassed to see their blunder in print. I fixed it, and the programmers remain anonymous here. They're good programmers, but this time it seems they sailed past the green bar without a thought.

When the bar turns green, read your code. Read the test code, read the code it invokes. It is not at all unusual to find that you have done something short-sighted, complicated, or (God forbid) clever. That code needs to be cleaned up before your peers see it!

Once you read the code, you will know what is wrong with it, and then you can use the various refactorings provided by your development tool or outlined in the fine Refactoring book. You can take your code from one "green" (all tests passing)_ state to another until it is no longer apparent that you ever did anything silly to begin with.

Be particularly suspicious of any code you've written into your tests or test fixtures that ought to be in the classes you are testing. Tests are meant to be extremely lean and fast-running, whereas business objects are meant to be capable. If you start writing capable test fixtures that call upon lean business objects you know you've gone wrong. Refactor the code.

I wish that we could lengthen the sequence to red->green->read->refactor so people would understand the process and apply it. I suppose that we take too much of "refactor" for granted. Nevertheless, the secret to TDD is in that third step, and all refactoring begins with reading and evaluating the code we've written.

After all, a program unexamined is not worth writing.

Motivational Speech

2010-03-08T06:45:00.001-08:00

My biggest problem with American culture is the concept of "the locker room speech that wins the game". I don't doubt that people get down and can use encouragement. A little validation can go a long way, and mistreatment breeds dysfunction. If you treat a winner like a loser, expect to see some losing. I get all of that (sparing you the painful personal history).

My problem is with the absurdist version of the story: the mythical team that is filled with execution issues, poor teamwork, low degree of individual skill, and an enemy with both superior skill and a history of success. In this story, it is one stirring talk from the tough-but-beloved coach that turns the team around. They charge the field and play like a commando team, each overcoming all personal skill issues and all of them meshing into a perfect winning machine.

In the real world, it is unlikely that the problems a technical team faces are motivational in nature. Maybe a team is struggling with technical problems. Maybe they haven't learned to support each other with their efforts and need some training. Maybe they lack the individual skills necessary for them to do a good job. Maybe they are skilled, but bound up in organizational boundaries, official roles, rules, and red tape. Maybe there is a very poor system of rewards and compensation, so that they are punished for doing what is best for the company. Commonly (for programming teams) the years of heroic last-ditch efforts have left the code base a non-performant, convoluted, fragile mess of hacks and band-aids. Maybe they aren't getting access to the Customer that will help them make good decisions.

It is ever-so-possible that most people on most teams in most companies are really dealing with actual problems. It could be that they're not just slacking or slumping, but that they've hit some walls. I have never yet seen a slow build, a performance bug, an intermittent failure, or a sloppy code base that yielded to emotional pressure instead of a breakthrough discovery. I've never seen a team burst through organizational barriers by happy think instead of hammering out working relationships and building a good history of collaboration together one feature at a time.

The problems our teams face are not all in their heads. The least sympathetic, least effective, least meaningful thing we can do when people are facing real technical or organizational problems is to try to prop them up with positive motivational speeches or "motivate" them with threats and insults.

If we want to be effective we must try giving our people the resources, aid, and freedom to solve problems. We have to free up some space for the work they have to do, and understand that there is no meaningful way to estimate the time to discovering a problem you do not yet understand. We have to allow them to experiment, make mistakes, learn, discover. I will not be helpful to a struggling team until I drop the motivation and apply some problem-solving or bring in some useful talent to help with the problems.

If we give in to the desire to give a locker room speech and our team succeeds, we have to resist the urge to claim credit. It is their hard work and skills that made it happen. I've been in the technical side of the software business for 30 years, and offer assurance that technical teams succeed despite these speeches, not because of them.
Contrary stories are welcome.