« July 2009 »
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
You are not logged in. Log in
Entries by Topic
All topics  «
Blog Tools
Edit your Blog
Build a Blog
RSS Feed
View Profile
tao and software development
  道可编程非常道
Monday, 1 June 2009
Perfection

A goal is not always meant to be reached; it often serves simply as something to aim at.
- Bruce Lee

In lean manufacturing there is the concept of perfection. It means delivering exactly the value required by a customer at exactly the right time with absolutely no waste. It's something to aim at.

Perfection does not mean perfect adherence to a defined model. I wonder if those who worry about doing True Scrum or True Kanban or True XP are focused on the model instead of on the goal.

Many arrows may strike the same target without colliding in flight. Is there not more than one path?

Just wondering.


Posted by Dave Nicolette at 6:00 AM EDT
Tuesday, 12 May 2009
Undergrowth

I was very pleased to see the small tree in front our our house in bloom this weekend. Three years ago, a gardening expert told us the tree didn't have long to live. It was dying, and he didn't believe it was salvageable. He recommended that we remove it, but we didn't have the budget for it at the time. Instead, we removed the old, well-established bushes that were growing in a circle around the tree.

These were evergreen bushes; the kind that grow slowly and are very hardy. Removing them proved to be quite a challenge. The roots were deep, extensive, and thick. The bushes always did well, no matter the weather. I guess it's because those massive roots were able to suck all the moisture and nutrients out of the soil, enabling the bushes to compete successfully against any nearby plants.

I'm glad we didn't remove the tree at that time. The first winter, it rested comfortably under a blanket of snow, with no bushes or other plantings near it. That spring, it bloomed and appeared healthy. We had expected to find a dead thing there when the snow melted, but the tree surprised us. As time went on, the tree grew stronger and healthier.

As I stood admiring the tree this weekend, I was reminded of companies that have attempted to adopt significant changes in the way they work, only to have the new ideas choked out by the dense undergrowth of old thinking, old assumptions, and old habits. It's funny that some people who have experienced that sort of thing come away believing "trees don't work."


Posted by Dave Nicolette at 10:10 AM EDT
Monday, 20 April 2009
No retreat

A team I'm coaching just now is making an effort to embrace sound software engineering practices as part of implementing agile and lean thinking in their work. It happens that the story of Xiang Yu came up on the Scrum Development mailing list today, and it resonated with me. Team members were struggling with the tension between delivering their customary number of story points versus taking the time to remediate missing unit tests and adding customer acceptance tests, which would reduce their velocity temporarily. I would not take Xiang Yu as a role model generally, but one of his exploits suggests a practical approach to embracing new practices:

[During the Chu-Han civil war, in] 208 BC while Xiang Yu and Liu Bang were planning the capture of the Qin capital Xian Yang, an urgent message came from the city of Julu, which had been under siege for nearly a month by Qin troops. A large army was sent to relieve Julu with Xiang Yu as second in command under the veteran political leader Song Yi.

When the troops got to Anyang, Song Yi ordered them to stop. He wanted to wait while the Qin army would exhaust themselves. They camped in the cold wet weather for forty-six days and the troops were short of food. Xiang Yu was furious because Song Yi ignored the suffering of the soldiers. The next morning during a conference with Song Yi, Xiang Yu jumped up and killed him. The generals were in awe and elected him their leader.

The vanguard of Xiang Yu’s army [was] unable to raise the siege, so Xiang Yu sent his entire force into battle. After crossing the river Zhang, Xiang Yu ordered all boats sunk, and after three-day supply was prepared, all cooking pots were smashed, giving the troops no choice but to go forward.

After Xiang Yu’s troops raised the siege and the Qin generals had surrendered to him, he went on to conquer a vast territory covering five former states.

(Source: http://kongming.net/novel/han/xiangyu.php)

If you're serious about improving your software engineering practices, then kill your inner Song Yi and burn your boats. Take only enough with you for the battle at hand (commit to what you will deliver next and focus on that). Let there be no retreat to hacking, no retreat to crystal-balling. The only way forward is forward.


Posted by Dave Nicolette at 12:39 PM EDT
Saturday, 18 April 2009
Identity without stasis

The first value listed in the Agile Manifesto states that we value individuals and their interactions more than we value formal processes and tools (or words to that effect). Yet, it seems as if most people who are trying to get a handle on all this "agile" stuff approach it from the standpoint of Process. Maybe this is to be expected, since everyone has experienced the adoption of the New Process of the Day many times over the years.

Along comes "agile" and here we go again: Another new Process. So, then, under this new rubric what steps must be followed? What phases must be passed through? What ceremonies must be practiced? What documents must be written? What catch phrases must be recited? Show us these things, that we may redecorate our working lives with the approved accoutrements while avoiding honest introspection and fundamental change.

Granted, much is asked of us when we must apply values and principles with sensitivity to context, rather than just following a Process by rote. Isn't it better that way? Oddly, to hold such power in hand causes many people to feel off-balance rather than liberated. It seems an alien idea to many that there can be structure without rigidity, identity without stasis. Julio Cortázar's character, Lucas, struggled with the same issue, in his own way:

En los juegos eróticos tempranamente encontró Lucas uno de los primeros refractantes, obliterantes o polarizadores del supuesto principio de identidad. Allí de pronto A no es A, o A es no A. Regiones de extrema delicia a las nueve y cuarenta virarán al desagrado a las diez y media, sabores que exaltan el delirio incitarían al vómito si fueran propuestos por encima de un mantel. Esto (ya) no est esto, porque yo (ya) no soy yo (el otro yo).

¿Quién cambia allí, en una cama o en el cosmos: el perfume o el que lo huele? [...]

(excerpt from "Lucas, sus críticas de la realidad" in Un Tal Lucas, Julio Cortázar, 1979.)


Posted by Dave Nicolette at 11:13 AM EDT
Tuesday, 17 February 2009
Chop wood, carry water

There's an old zen saying: Before enlightenment, chop wood, carry water; after enlightenment, chop wood, carry water.

When reading/hearing debates about software development techniques, I often get the impression that people mix up ends and means. Even after all these years, there are still debates about the merits of test-driven development (TDD). Some proponents of TDD seem to be saying that our goal should be to use TDD; TDD is the desired end. I think the desired end is defect-free code and control of technical debt, and TDD is a means to that end.

One way or another, we have to achieve defect-free code and control of technical debt. For us, that's what it means to chop wood, carry water.

Is TDD the only means to do so? Of course not! To name a few: The Cleanroom approach; peer code reviews; extensive after-the-fact quality assurance testing; requirements tracking tools; defect tracking tools; and more.

TDD is certainly not the only means to that end.

It's just the best means anyone has come up with so far.

After enlightenment, one still chops wood and carries water. The desired end doesn't change. What does change is the means: One uses the most effective methods known. When something better than TDD comes along, it will simply be the next step on the path of enlightenment in software development technique. Until then: Chop wood, carry water. And after: Chop wood, carry water. The means isn't the end.

And if you, personally, don't "believe in" TDD: Chop wood, carry water, however you can.


Posted by Dave Nicolette at 8:03 PM EST
Monday, 16 February 2009
Bruce Lee on software development

How did Bruce Lee know so much about software development?

"Accept what is useful; reject what is useless; add what is specifically your own."

"Before you reject anything make sure you understand why it doesn't work for you."

Quotes found by way of Adam Sroka on the Extreme Programming list.


Posted by Dave Nicolette at 1:12 PM EST
Sunday, 25 January 2009
The tree that wouldn't bend

We live in a part of the world that's known for its winter weather. Even so, the winters here aren't really as harsh as people say. At least, not usually. This year, temperatures have been lower than normal and we've had some strong winds from time to time, not to mention some especially lovely snow. On one occasion in December of 2008, linear winds did the following to one of the large trees in our back yard:

Other trees came through the storm unscathed. We watched them wave back and forth, flexing in the changing wind patterns. Just enough yin and just enough yang. This tree was a bit stubborn, I guess. It decided to stand firm against the wind. This proved to be a poor choice on the part of the tree.

Too much yang, not enough yin. Bye-bye.

The incident reminded me of another large, stable entity located more-or-less in our back yard. Like a tree, this entity was long-lived. It had a 160+ year history in business. During most of that time it operated in the black, even when competitors were struggling and dropping out of the race. By the turn of the century, though, the entity had become bloated and set in its ways. Management consistently made choices that seemed to be designed to bring the company down. I don't care to mention the name of the company in this venue, but I'll tell you stories sometime over coffee or beer. I predict you'll accuse me of making them up, but I needn't exaggerate.

The chickens came home to roost last year: Early in 2008, the company had to beg investors for a $7 billion-with-a-B cash infusion to stay afloat, despite enjoying the dominant market position across its business footprint. When the financial crisis struck in late 2008, it was the death-blow for the old tree...er, institution. The company has been bought out. It still exists in name; the new owners kept the local branding to go along with the customer base and loan portfolio. You can still see the same signs on the branch offices as before, just as you can still see what's left of the old tree in the back yard. I'm not sure whether any other parts of the carcass were salvageable.

Several years ago, some of the staff in the company's IT department recognized that the lines of business weren't getting much value out of IT services. They set out to find out why, and then to correct whatever problems were identified. Eventually this led to a bottom-up agile software development initiative. Lacking support from IT management, the agile group turned directly to the lines of business. They undertook a number of projects and delivered them successfully. Before long, line of business managers were demanding that their IT requests be carried out using the new approach. IT management didn't like that. No one had consulted them. It wasn't their idea. Not invented here. I'm the boss and I give the orders. Etc. A skunkworks group had gone around them directly to the internal customers, and had out-performed them by a factor of nine, on average. Ouch. After three years of success, the agile group was brought back into the fold of the IT department and dismantled. Who's the boss around here, wise guys? Hah! Just one of a host of poor management decisions both inside and outside the IT area.

Tao is about learning how the universe works by observing nature, and then going with the flow so you won't have your head handed to you on a platter every time you take a step, never comprehending why it keeps happening to you. Maybe it was a taoist who wrote that old advertising slogan, "You can't fool Mother Nature!" The same rule of thumb works for business, software development, and all that jazz, too. It's all part of the same universe.

Too much yang, not enough yin. Bye-bye.


Posted by Dave Nicolette at 12:47 PM EST
Tuesday, 30 December 2008
A rose by any other name

People worry a lot about whether they qualify for the label, "agile." They compare what they are doing with published descriptions of what they "should" be doing. People worry about whether they are following a particular "agile process" correctly, although the Agile Manifesto explicitly elevates people above process, meaning that people are free to assess, choose, and adapt any process that helps them achieve their goals.

The name that can be named is not the true name.
The nameless is the origin of heaven and earth
While naming is the origin of the myriad things.
Therefore, always desireless, you see the mystery
Ever desiring, you see the manifestations.
    —Tao Te Ching

If you fixate on the names of things (agile, lean, iteration, sprint, stand-up, burn-down, run-around, la-dee-dah) then all you will end up with is a collection of labels. Value by any name is value, and waste by any name is waste.


Posted by Dave Nicolette at 11:39 AM EST
Tuesday, 21 October 2008
Beginner's Mind, Duct Tape, and WD-40

There's an old saying that a shadetree handyman has only one tool in his toolbox: Duct tape.

Some in the agile community seem to be turning into shadetree handymen. They've got a single model for agile work that they apply to every situation. When all you've got is duct tape, everything looks like a duct. Often duct tape is just the right thing. But sometimes, chopping a duct into a bunch of little iterative ducts restricts air flow. In his enthusiasm for duct tape, the handyman may forget the goal is to promote air flow, and not (necessarily) just to iterate the ductworks.

There's been a lot of interest in the past couple of years in applying lean principles to software development. Lean and agile thinking are compatible and complementary. There's an approach based on customer pull and single-piece flow that is becoming popular under the name "kanban," although kanban as such isn't the whole process. James Shore recently published a very clear and concise description of a kanban process for software development. He also offers some suggestions about when to choose an iterative process and when to choose a kanban process based on key characteristics of the situation at hand.

It's good for the shadetree handyman to add a second tool to his toolbox: WD-40. When duct tape makes things stop, a bit of WD-40 might make them go again. The trick is to know when to apply each tool.

In the beginner's mind there are many possibilities; in the expert's there are few.
Sunryu Suzuki


Posted by Dave Nicolette at 10:06 AM EDT
Wednesday, 8 October 2008
Water

Some people ask why an agile software development team needs a coach. After all, the basics of agile techniques are very simple. How hard could it possibly be to remember them? People wonder whether the present trend toward using team coaches is just a fad or a tricky way for consultants to relieve customers of their excess cash.

Like any truly useful tools, agile development techniques are indeed simple. That's not the problem. The problem is that teams don't remain at the same level of effectiveness forever if left on autopilot. Teams are made up of humans, and humans get careless when they repeat similar work again and again. Besides that, things change. If the team doesn't pay attention and change as well, they will become very proficient at solving yesterday's problems.

It's neither bad nor good. It's just one of those things, you know.

There are these two fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, "Morning, boys, how's the water?" And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, "What the hell is water?"
— David Foster Wallace, "The Capital T Truth"


Posted by Dave Nicolette at 1:51 PM EDT

Newer | Latest | Older