Posted on

Template-Based Development Then and Now

There’s an old saying: There’s nothing new under the sun. Maybe there’s something to it. Details change, but the general patterns of things remain consistent. The wheel keeps turning, and if you live long enough you see the same spokes come around again and again.

James Shore, a well-respected figure in the software development field and the author of the highly-regarded book, The Art of Agile Development, has developed an approach to software development he has called a pattern language for testing without mocks.

I struggled to get started using James’ pattern language. Initially, I was trying to write code in two different ways in parallel – one using mocks and the other using the pattern language. I thought it would be interesting to apply the patterns to different types of languages and different programming problems. It was extremely frustrating. It seemed no matter what I did, I was breaking one of more of the “rules.”

Fortunately, James was willing to help me quite a lot, pointing out where I had gone astray and suggesting reference material to help me learn. He mentioned that people who have internalized testing with mocks often have similar difficulties picking up this approach, and that it requires a mindset shift.

That’s exactly what I was doing. I was approaching it from the perspective of testing with mocks and then seeing what would have to change to build the same solution using the pattern language. It proved to be a fool’s errand.

I paused and took a couple of days off from it. Then I read through all the material describing the various patterns and so forth. It struck me that what he was describing was very similar to the way we used to apply common application patterns in the 1970s-80s. By focusing on the comparison between “using mocks” and “not using mocks” I was missing the point.

Continue reading Template-Based Development Then and Now
Posted on

A conversation with my rubber duck concerning the linearity of time and other impossible things, plus a little about test-driven development and refactoring

Sometimes talking through a problem with a rubber duck can yield surprising insights.

With increasing frequency, I’ve been hearing comments to the effect that when people refactor code, they break existing test cases that were passing before they refactored.

When I ask whether the test cases “know” about underlying implementation details in the code under test, they look puzzled. Well, of course. How else would you know the code was working?

Hmm.

So, when I ask them whether they test-drive the refactorings, they look puzzled. Well, of course. We always test drive code changes.

Hmm.

So, when I ask them whether the tests break due to refactoring, even when the refactorings are test-driven, they look puzzled. Well, of course. That’s what we said, isn’t it?

Hmm.

I didn’t see how the last two statements could be true at the same time. I needed advice from my rubber duck.

Continue reading A conversation with my rubber duck concerning the linearity of time and other impossible things, plus a little about test-driven development and refactoring

Posted on

Random musings on the Agile Manifesto

As of February, 2001 the authors of the Agile Manifesto were all advanced in their careers and were already well known as top-tier software professionals. The individuals are quite different from each other; different experiences, different perspectives, different political views, different levels of formal education, different ways of approaching problems, very different personalities.

Notwithstanding their differences, they have one thing in common, and I think it may have a bearing on the tone of the Manifesto, as well as on a peculiar incongruity that I’ll mention later. The common factor: They are middle-class white males raised in a West European or North American cultural context.

Continue reading Random musings on the Agile Manifesto
Posted on

Induced Work

People say there are certain things that are hard to unsee once you’ve seen them. When you start to see software development and delivery processes through the lens of lean thinking, it seems you can never unsee it again. You can’t fail to notice opportunities for improvement. Sometimes it’s puzzling that others don’t see the same things, but it may be they’re looking at the situation through a different lens.

Continue reading Induced Work
Posted on

A sidelong view of organizational transformation failure

Looking at the corporate landscape of the 2020s, I’m compelled to wonder why large organizations today seem no different from those of 150 years ago, despite the work of people like W. Edwards Deming, Peter Senge, Taiichi Ohno, and others; and well-thought-out improvement programs/frameworks/methods like Kaizen, Business Process Reengineering, Operational Excellence, Total Quality Management, Agile- and Lean-derived frameworks, and others, all diligently applied year after year.

There’s been speculation about why all this time, money, and effort has yielded no fruit.

Continue reading A sidelong view of organizational transformation failure
Posted on

Mastering the keyboard

You’ve probably heard advice from certain quarters that a software developer doesn’t need a pointing device. Everything they need to do can be done with the keyboard, and the work is much faster that way.

The advice seems succinct until you unpack some of the underlying assumptions. Besides that, I think we should think about the effect on novice developers when highly-experienced trainers and coaches tell them to throw away their mouse. They often end up spouting off on their blogs about how anyone who ever reaches for a mouse for any reason is unprofessional.

They have been told by mentors they respect that they don’t need a mouse. All they need is a keyboard. And they’ve practiced working that way through code katas and other exercises. They can navigate their favorite text editor flawlessly using the keyboard alone.

Continue reading Mastering the keyboard
Posted on

Focus on Delivery

Year by year, the general quality of software worldwide, in every industry, declines. Software testing specialists lament the low quality of applications they use in their regular lives as well as those they are engaged to test.

It has become a sort of game to take photos of crashed billboards, kiosks, train and bus signage, and other software failures and post them online. The examples are called Kevlin Henneys, after a software engineer who started posting such photos several years ago. They’re amusing, but also lead one to wonder why software failures are so common, and how we came to accept bad software as normal.

I don’t claim to know all the causes of the phenomenon. One cause may be the sheer number of people involved with developing software. It’s been said that the number of programmers in the world has doubled every five years since about 1970. That may or may not be absolutely accurate, but in any case the key observation is that half the people writing the software products we depend on in our lives have less than five years experience.

Many of them never learn software development as an engineering discipline. They are graduates of rapid learning programs such as “bootcamps,” aimed at enabling a person to generate a mostly-boilerplate mobile app or web app quickly. Intuitively, this looks like it could be one cause of poor software quality.

But I’m exploring another possible cause in this post: The obsessive, almost manic preoccupation with delivery.

Continue reading Focus on Delivery
Posted on

Institutionalized Workarounds

I’ve heard it said that sometimes we learn a different way of looking at things, and it influences the way we see the world from that point forward.

For me, one such way of looking at things is Lean Thinking. I became aware of that school of thought about fifteen years ago, and it had a profound effect on the way I approached my work in software consulting and team coaching.

As I learned more about Lean, it became the default lens through which I viewed software development and support processes. It changed the way I think about two concepts that people talk about a lot: value and waste.

My observation is there are two kinds of value and most people don’t distinguish them. Similarly, there are two kinds of waste and most people don’t distinguish them. One of the kinds of value overlaps with one of the kinds of waste. As a result, in many organizations people emphasize the wrong kind of value, while simultaneously treating some forms of waste as “value.”

Continue reading Institutionalized Workarounds
Posted on

My personal quest for a UML diagramming tool

Guest post by A. Cranky, Old Man

tl;dr – I’m using Visual Paradigm.

When I needed a way to create a reasonably good-looking sequence diagram for a recent engagement, I was suprised to discover more than 80 diagramming tools on the market. Given such a large pool of candidates, I expected to find several good ones, and I embarked on my quest in hight spirits.

You’d think at my age I would know better.

Continue reading My personal quest for a UML diagramming tool