Posted on by

The Curious Incident of the Magnetic Scotty Dogs in the Night-Time

Long, long ago, in February of 2020, Joshua Kerievsky of Industrial Logic fame published a blog post entitled, “A Tale of Two TDDers.” In it, he described a production issue which he said was based on real-world experiences in a real code base. He described two team mates, David and Sally, who took very different approaches to solving the problem.

Although based on a real incident, the story in this blog post is not the actual tale; it’s a contrived version in which David and Sally separately solve the same problem two different ways. David used a test-driven approach and took several hours to refactor a bunch of related code. Sally pushed a quick fix into production and the team immediately added the missing test case(s). Of course, in real life the team solved the problem just once. But Josh wanted to set up a question for readers: “Which programmer would you prefer on your team?”

The post generated quite a bit of enthusiastic discussion. So much, and so enthusiastic, that just 6 days later Josh posted a follow-up post, “One Defect, Two Fixes” to try and clarify. He mentioned the first post had “generated a lot of interesting discussion, some of which bordered on deep misunderstanding.”

Continue reading The Curious Incident of the Magnetic Scotty Dogs in the Night-Time

Posted on by

Against TDD

Test-Driven Development (TDD) is a tool. To get value from a tool, it’s necessary to:

  1. choose the right tool for the job; and
  2. 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

Posted on by

Reducing process overhead in Scrum

In a social media discussion in mid-2019, several people expressed surprise at the idea that Scrum might include “overhead.” The confusion seemed genuine. Some people asked for examples. It seemed they were unable to conceive of “overhead” in Scrum.

The popularity of Scrum has led to an interesting situation in the Agile community. Many people view Scrum as The Answer. It’s the only and best way. There is no possibility to improve beyond Scrum. Everything in Scrum is valuable by definition.

In reality, every process includes overhead. We do things for customers/users, and we also do things to position ourselves to do things for customers/users. When we don’t distinguish between the two, we can fall into the trap of trying to perfect our overhead activities, rather than minimize them.

Continue reading Reducing process overhead in Scrum

Posted on by

English for English speakers

In Howard Myers’ 1972 short story, “Out, Wit!” physicist Jonathan Willis discovers the secret of alchemy, and publishes a paper describing how to make gold. Unfortunately for him, he writes the paper in an ironic style that leads people not to take it seriously. Making things worse, his work contradicts the prevailing wisdom in the scientific community, and senior researchers shut him down.

No one takes Willis’ paper seriously…except the Russians. They understand English well enough to comprehend the content of the paper, but not well enough to understand the humor in it. They return to the USSR, where they apply the techniques described in the paper to produce large quantities of gold, which they use to collapse the capitalistic economies of their enemies.

The common language of work

In the global economy of the 21st century, English has become the de facto common language for international scientific and academic exchange, business, and technical work. It’s the official corporate language in many international companies. It’s the practical working language for software teams that include members from different countries.

The situation sounds like an automatic “win” for native English speakers. We already know the global language of business. We don’t have to overcome that barrier to be effective in international work – conferences, user group meetings, training classes, working in multinational companies – all doors are open for us.

But…Jonathan Willis.

Continue reading English for English speakers

Posted on by

What’s the cost of interrupting developers?

There’s been some online chatter recently about an old topic – the need for uninterrupted focused work time when doing software development. Some of the comments have surprised me, in part because I thought it was a settled topic. That was silly of me, because of course there are no settled topics.

But it surprised me, as well, because some of the comments suggested a fundamental misunderstanding of how creative work is done: Some people treat creative work the same as repetitive tasks, such as sweeping the floor or washing the dishes, in that they assume creative work can be interrupted over and over again without any cost.

Continue reading What’s the cost of interrupting developers?

Posted on by

Show Me a Study

My friends know me to be skeptical of “studies” about software development techniques. The main reason for my skepticism is that such studies are rarely undertaken by people who have any understanding of what they are studying. They combine data points from different sets of observations as a way to try and accumulate sufficient information to make charts and trend lines, but often the data points aren’t consistent enough for the aggregated data to be meaningful. I wonder whether many studies of programming techniques are based on enough observations to be meaningful, and whether the researchers’ analysis of the results is based on any direct knowledge of the subject at hand.

Continue reading Show Me a Study

Posted on by

Doing Scrum Perfectly

Sometimes I use the phrase, “novice Scrum team,” to describe a team that’s new to Scrum, still settling into the routine of sprints, and still getting a handle on the underlying values of Scrum. Often, these teams are in the process of adopting unfamiliar technical practices like test-driven development and unfamiliar processes like continuous integration, and learning to collaborate across roles that had been sequestered in functional silos before the cross-functional Scrum team was established. They’re learning a lot of new things at the same time.

Quite a few people appear puzzled or bemused by the phrase. It occurs to me they may think of Scrum as a fixed set of rules to follow, rather than as a starting point for ongoing improvement. You either follow the rules or you don’t. There’s no concept of “novice Scrum team” because there’s no concept of ongoing improvement: When you follow the rules of Scrum, you’re doing Scrum. You either do Scrum or you don’t. That’s all there is.

Continue reading Doing Scrum Perfectly

Posted on by

TDD: Let the Tests Drive

As long as we write tests, what’s the big deal about writing them “first” rather than “last?” Let’s explore that question.

The video looks a lot better on YouTube than it does here. Try https://youtu.be/Bf89rd0o5-0.

https://youtu.be/W1-IjCbzKAs

When we’re conscientious about writing examples before production code, and we drive all our production code from executable examples, we can enjoy several benefits:

  1. Helps us remember details and not overlook things
  2. Helps us avoid over-engineering or going too far with our design
  3. Helps us keep the design simple
  4. Provides a safety net for experimenting with different implementations
  5. Provides a safety net for refactoring
  6. Gives us frequent positive feedback so we don’t feel beaten down at the end of the day
  7. Provides executable low-level documentation of everything the application does
  8. Makes it easier to locate the source of bugs; keeps us out of the debugger for the most part
  9. Creates a regression test suite as a side-effect of writing the examples that drive the design
  10. Equally useful for emergent design and up-front design, and for greenfield development as well as enhancements and bug fixes
Posted on by — 2 Comments

Technical Debt: The Man, the Metaphor, the Message

Ward Cunningham, a fish of some note in our small pond, wanted to deliver software incrementally to a client in the financial sector. The client didn’t see the value in doing that as opposed to delivering in a “big bang” fashion. To help relate the idea to the client’s frame of reference, Ward came up with the “technical debt” metaphor. It’s explained pretty well in an Agile Alliance article.

Continue reading Technical Debt: The Man, the Metaphor, the Message