There is a division in the agile community about whether one should rely on people or focus on people supported by systemic thinking (no one I know of suggests systems alone are enough). This debate is often the people over process Vs. people and process (or as Don Reinertsen would say people times process). I've been in the agile community for some time and have seen some interesting things that I think shed some light on this debate. This long-time perspective has enabled me to see an interesting pattern.  read more »

I was recently surprised when someone said I had said software is not creative.  I was surprised because I can’t imagine myself ever saying that.  On reflection, I realized I had said software is not like art.  But I meant that it is not like art because art does not have a particular customer nor does it need to follow particular rules.  Art speaks to whoever it speaks to.  It comes from the artist and its message will hit various people differently.  Software has to satisfy the needs of the customer.  In other words, great artists write from their heart and soul and they provide  read more »

I recently had to install a driver for a network printer in my home. This is, I would say, a pretty commonplace thing to do in modern life.

I don't want to suggest that what happened was limited to a particular vendor, so we'll leave the company name out… however, it is one of the most prominent and successful printer companies in the world. Not some little podunk knock-off, in other words.

I put the CD that accompanied the printer into my drive and ran the SetUp program. Given that this is a device intended for home use, one would assume (as I did) that I would simply answer a few questions that the rest would be handled for me by the installer.

I'd installed this driver before, on other computers in my house. I knew it was large (much larger than I would think it would need to be) and that the installation took upwards of 20 minutes to complete, and that the "progress bar" would often just seem to be making no actual progress sometimes, but so long as the task manager said it was "running", I'd just have to be patient. So, I left it alone.

I came back a few hours later, and it was frozen at 24%. Task manger reported that it was still running (no "not responding" message or anything like that), so I left it. Two hours later, still nothing, so I finally cancelled the process and tried to determine the cause.

Recently at the Rails conference, Bob Martin served up a very provocative talk: "What killed Smalltalk could also kill Ruby." There has been a fair amount of controversy about this particular presentation, most notably from the Smalltalk community who consider themselves to be not-at-all-dead. They point out, for instance, that Smalltalk was not free "back in the day" and Ruby/Rails is, and that this makes more of a difference than many of the factors Bob was referring to.

For my part, I don't care all that much whether one language or another is in vogue as much as I care how the technology is being used and specifically how our profession is or is not maturing as a result. Bob said that we were not a profession in the past but are now. I tend to agree with him. He also equated the notion of a profession with the concept of disciplines which I also totally agree with (this should not be too terribly surprising to anyone familiar with the book I wrote recently - Emergent Design: The Evolutionary Nature of Professional Software Development - and if you note the particular engineering practices we choose to teach at Net Objectives).

So I'm with him on this, but I think there were a couple of things missing in his equation.

I have heard it said many times that patterns have to be discovered. Years ago, after reading Christopher Alexander's "Timeless Way of Building" I felt that this wasn't really true - since patterns are not really just "solutions to recurring problems in a context" but rather an exposition of the forces present in the context including the relationships between these forces.

Last year I was diagnosed with a "nodule" on the right side of my thyroid (this is the word they use when you have a tumor and they don't want to freak you out). My doctor told me that the nature of the thing (soft, large) meant that it was unlikely to be cancerous, but that we might want to remove it anyway because it might turn cancerous later.

I asked "would I have to stay overnight in the hospital, or could this be done on an outpatient basis?"

He nodded and said "well, it's superficial, so…"

I interrupted. "Ah, good, so it's no big deal."

He looked puzzled. "Um, no. What?"

"You said it was superficial, so that means it's no big deal, it's trivial."

"No," he said, "it is not trivial, it is superficial."

I had my head down this last week doing some code coaching and agile analysis work.  The thing that strikes me about many of our clients is that it is not sufficient to show people what they should be doing, one has to show people what they can do where they are now, as well as create a path to get to where they need to go.  It’s kind of like learning how to ride a horse properly while you are riding something else.

With the holidays coming on, many of us are heading up to the attic to retrieve the boxes of decorations that have been waiting all year to be called into service again. In my family we put up and decorate a Christmas tree each year, but I suspect Hanukah and Kwanza, etc… have their festive ornaments too, and probably electric lights are involved.

One thing I'll do this year, as I do every year, is to lay out the strings of lights on my coffee table and plug them all in, to see if any of them fails to illuminate.

Comparing Two Patterns: Adapter and Façade

(Note: if you are unfamiliar with these patterns, you can read about them at our pattern repository)

One reason people often struggle to understand how to get real value from patterns is that sometimes two or more of them can look, at first glance, extremely similar. When I'm teaching patterns, people will very often point out how similar the Strategy and Bridge patterns are, or the Decorator and Chain of Responsibility, or the Factory Method and Abstract Factory, etc…

Usually this is because people often confuse the example of the pattern that's being presented to them with the pattern itself. Patterns are neither UML diagrams nor code examples; they are a higher concept that captures best practices, domain and implementation forces, and the consequences (both benefits and costs) of certain decisions. Diagrams and code are simply representations of the patterns, and are always more specific and narrow than the patterns themselves are.

This misunderstanding is an opportunity, however, because when we compare two patterns that appear similar and determine how they are actually different, we can sometimes dramatically enrich our understanding of them.

 The Present and the Possible

There is a gap between what is possible and what is present - what is done - in the software industry. How much time and effort is wasted, how much re-inventing and re-discovery is done because we don't always understand the hard won insights from the past about what is required to create quality, sustainable product? How many companies have not realized the success of process improvements, like Agile, because they have not really understood its principles?

This gap, and the pain and waste it causes, is frustrating. Closing the gap involves a little re-orientation, becoming intentional to learn and try and adjust, to improve continually. To become more professional.

Professionals strive to build on the learnings of others. They avoid taking unnecessary shortcuts, especially when that could harm the product over the long term (imagine what would happen to the civil engineer who kludges together something for the last 2 feet of a bridge just to get it finished up or just to try some new, cool idea). They follow the best practices in how we develop and manage people, in the processes and methods we use, and in the proper way to use tools and technologies.