Wednesday, February 23, 2011

Easy flowchart for communicators


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.

Monday, February 21, 2011

Grandpa Tim Tells A Scary Story

"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."

Thursday, February 17, 2011

Agile Otter Receives Love

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.

Wednesday, February 16, 2011

Self-Promotion and Resume-writing

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.

Monday, February 14, 2011

The Wicks

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.

Update: See how Zander describes his life and leadership:

Thursday, February 10, 2011

4 Questions Film Project

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?

Thursday, February 3, 2011

World's Shortest Agile Summary

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.

Wednesday, February 2, 2011

The Great Giveaway Begins

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.