Why are your socks on the floor again?
I don’t know.
Don’t say “I don’t know!”
How many times have I told you to turn off the light when you leave a room?
I don’t know.
Don’t say “I don’t know!”
Tag: growth
Four canards that afflict us
Alert: 82% chance of pontification.
Continue reading Four canards that afflict us
Cats in the monasteries of IT
Paulo Coelho wrote a nice piece about how cats came to be regarded as necessary for meditation for a few generations in Japan. The story might resonate with just about anyone in just about any context.
In my case, it reminded me of longstanding assumptions about how things “must” be done in the IT field. The following quote sums up the state of corporate IT in a nutshell: “..society continues to create some systems which, in the fullness of time, lose their reason for existence, but continue to impose their rules.” Continue reading Cats in the monasteries of IT
Why should we do code katas?
I participated in a coding dojo recently in which some of the comments I heard caused me to think about the purpose of practicing code katas. It seems that many programmers, including some pretty advanced ones, don’t quite get the point.
We were reading about some code katas online so that we could choose one to do for the dojo. We came across a description of the Bowling Kata written by Robert C. “Uncle Bob” Martin. A couple of the guys quickly dismissed it when they saw Uncle Bob’s name. “He’s too prescriptive,” said one. “I don’t want to be told how to approach the problem,” said another. They looked for a write-up of the Bowling Kata that didn’t try to guide us in how to approach the problem.
They found one and we used it. All evening we kept running into silly little issues and speed bumps, such that we really didn’t get a lot of value from the whole exercise. We went down tool-related side paths, broke our development environment a couple of times, forgot what we were trying to accomplish, and started over multiple times. It never felt as if there was any goal or even a general direction. Despite the fact the group included some very fine professional programmers, I have to say it was not the best coding dojo I’ve ever been in.
Obviously, due to the sort of democratic and participatory event a coding dojo is, I have to accept a share of the blame for that. I actively chose not to make suggestions to bring the activity onto some sort of intentional course, because I wanted to see where it might go. In the end it went nowhere, but the experience led me to sit down and reconsider the reasons we do these things, and how we can get value from doing them.
The key point is that there are reasons for Uncle Bob’s approach to katas. Rather than getting to the point directly, I’m going to begin with a couple of rambling digressions, as per my usual style. Continue reading Why should we do code katas?
Fish gotta fly
There are these two young 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?"
None of this is about morality, or religion, or dogma, or big fancy questions of life after death. The capital-T Truth is about life before death. It is about making it to 30, or maybe 50, without wanting to shoot yourself in the head. It is about simple awareness—awareness of what is so real and essential, so hidden in plain sight all around us, that we have to keep reminding ourselves, over and over: "This is water, this is water."
(David Foster Wallace, commencement speech at Kenyon College, Ohio).
Yeah, so if you care to Google it, you’ll find lots of articles pondering the reasons why the majority of Lean, Six Sigma, Agile, Kaizen, TQM, and name-your-poison adoptions "fail." People you and I know from conferences and books and such tell the same stories over and over again of the one big success they had with organizational transformation. Everyone was stoked about their branded re-packaging of old ideas made new again through the magic of buzzwords. They achieved improvements of 4x, 10x, 50x, or more X’s than you’d care to count. One or two years after the consultants left the building, those organizations were back where they started. I’ve seen it happen myself. The organizations snapped back to their old equilibrium state. Maybe they always do. The buzzwords haunt the place like fading poltergeists, and the stories live on, but the substance is long gone.
If you’ve done much Value Stream Mapping in information-shuffling organizations (as opposed to thing-making organizations), then you’ve probably done a double-take a few times, unable to believe process cycle efficiency could really be as low as that, and the company doesn’t sink through the earth’s crust like the superdense slug it is. It seems they’re happy as can be to spend 3 or 4 million dollars and burn up a year of 75 people’s precious time to build a routine, web-based CRUD app, fundamentally no different from a million others, that could have been delivered by a team of 4 in 6 weeks for the price of a few pizzas. Nor do they seem terribly worried about the opportunity cost of having all those people duct-taped to their desks for all those months, busily waiting for each other to "review" or "approve" things.
I’ve been wondering, lately, why none of those people wants to shoot himself in the head.