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

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 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 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

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