Test-Driven Development (TDD) is a tool. To get value from a tool, it’s necessary to:
- choose the right tool for the job; and
- use the tool properly.
Circa 2019, there are numerous debates about whether TDD is useful. It seems to me many of the arguments against TDD boil down to one of the following:
- trying to use TDD in situations where it is not the right tool for the job; or
- using TDD improperly.
Choosing the wrong tool or using a tool improperly are certainly things that we fallible humans do from time to time. However, when people have experienced those things with respect to TDD, that isn’t what they say. Instead, they say TDD categorically does not help. It is inconceivable that they could have made a mistake. The tool they used must have been at fault. They are here to warn you against being harmed by that tool.
Continue reading Against TDD
No one can see their reflection in running water.
It is only in still water that we can see. (Lao Tzu)
A friend of mine was telling me about the new apartment he and his family have bought. The building is under construction, and is located in a prestigious part of a major city. We got into a discussion about choosing where to live. He prefers large cities, and I prefer living far from a city (although I work in cities).
Continue reading Take a walk in the desert
There’s a huge interest in failure these days. People are clamoring to be the first to fail, to be the one who fails most frequently, gleefully to fail and fail and fail. Question: Why do you want to adopt [popular method]? Answer: So that we can fail more!
Continue reading The Impostors
The question was posed in a discussion on LinkedIn. It received the following response:
Is the question "how does collaboration begin" or "how do specialists become generalists"? I assume the latter.
Um, well, that wasn’t the question. What’s the value in assuming a different question, because you’d prefer to answer the other question? After a number of comments extolling the virtues of the generalizing specialist, a person showed genuine interest in moving himself and his team in that direction. He want to get started. That’s a good thing.
Instead of helping him get started, however, people just reiterated the end state. Just do. Just be. Just blah blah blah. There’s a certain word in the question. It’s a little word; nothing ostentatious. But I think it’s kind of an important word. The word is begin. Continue reading How does collaboration begin?
It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.
Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading Don’t do anything stupid on purpose
In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.
Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading The Shimmering
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?
A post on this blog received a very interesting comment from a reader with the nom de pixel Malapine:
"…my problem isn’t boredom but fear: the codebase sucks, we have no idea whether the features are what customers want, and if the product doesn’t sell, some of us may get laid off. If that’s ever me, I am screwed: my resume will show two decades with the same employer, the vast majority of it on Waterfall or ScrumBut projects."
"Off the job, I read books on Agile, go to monthly dojos, etc.; but on the job I can’t even do TDD properly — builds take 20 minutes just to compile, and nobody else seems to care."
I felt this called for more than a response in the comment thread. It seems to me it illustrates that perception can be more important than reality, and that is of interest to me presently.
Continue reading Perception
This post could be subtitled, "A self-indulgent look at past writings."
In April of 2012, Paul Bowler (@spbowler) found some articles from my old site on the Wayback Machine and tweeted about it. I replied to him, "Thanks for finding that! Some of the articles make me smile; learned a thing or 2 since then. Others I’m glad to have recovered." That prompted him to ask, "Which articles should I avoid?" That’s not a question to be answered in 140 charcters.
The short answer is that people should read whatever they think will be interesting, and then use their own brains to arrive at independent conclusions. I’m not one of those people who insists that others provide published references to support everything they say or write. If anything, I’d rather people did their own thinking, and used published references as references rather than as a substitute for their own brains. I’m not so sure published references are all that special, anyway.
Now for the long answer.
Continue reading With the benefit (and bias) of hindsight