Tag: behavior

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

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

Is collaboration really so difficult?

In episode 79 of Dave Saboe’s excellent podcast series, “Mastering Business Analysis,” Dave interviews Paula Bell about effective collaboration. Here’s the link: http://masteringbusinessanalysis.com/mba079-effective-collaboration/

One point in particular stood out for me in this episode: “It can be challenging to collaborate under the pressure of deadlines. It’s worth taking the time to get to know one another and to some team building.”

It reminded me of situations that were common in the 1980s in corporate IT work: The “sweatshop” environment, in which working life comprised an unending series of death marches punctuated by physical/mental/emotional crashes.

Continue reading Is collaboration really so difficult?

Posted on by

My individual coaching assessment guide

As an agile/lean coach and “change agent,” I often find myself working with dozens of individuals at the same time at any given client. I’m not a great fan of “assessments,” but I do need some practical way to keep track of where everyone stands and how they tend to think and collaborate. To do that, I consider the following factors.

Continue reading My individual coaching assessment guide

Posted on by

Beyond resistance

Do people resist change? The consensus appears to be that they do.

Well, with all that consensus floating around, I guess resistance to change must be a Thing. It’s hard to argue with a million articles that all say the same things.

On the other hand…not everyone sees it that way.

Continue reading Beyond resistance

Posted on by — 6 Comments

The what, the how, professionalism, and pragmatism

Warning: Rant
Warning: tl;dr

So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.

Yet, they do.

Continue reading The what, the how, professionalism, and pragmatism

Posted on by

The Agile Katamari: Sticking things together and pulling things apart

Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.

Continue reading The Agile Katamari: Sticking things together and pulling things apart

Posted on by — 8 Comments

The mother of all management anti-patterns

My book on software development metrics is in the final stages of editing. The editor made a kind comment about one section of the book. She wrote: “This section is marvelous. I wish all management everywhere would read this and pay attention.” Me, too. This is the section:

(begin excerpt)

This may be the mother of all management anti-patterns. Management science has treated human beings as interchangeable machine parts at least since the time of Frederick Taylor’s “scientific management” in the early 20th century, and possibly much longer than that. Even today, many managers loosely refer to workers as “resources” without realizing the implications of the word.
Continue reading The mother of all management anti-patterns

Posted on by — 1 Comment

Don’t do anything stupid on purpose

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