Author: George Dinwiddie

George Dinwiddie is a Software Development Consultant and Coach with over twenty years of experience creating software ranging from small embedded systems to corporate enterprise systems. With a strong interest in lifelong learning, he has pursued more effective ways of creating software at the technical, interpersonal and organizational levels. As principal of iDIA Computing, LLC, he helps teams learn more effective software development techniques while accomplishing their current projects.

Studying patterns for Fearless Change

Fearless Change: Patterns for Introducing New IdeasDon Gray got me started, with his posting of 3×5 notecards for studying the patterns in the book, Fearless Change: Patterns for Introducing New Ideas, by Mary Lynn Manns and Linda Rising. I agree with him that it’s a wonderfully helpful book, and I thought the idea of creating cards to carry and study at odd moments was a good one. I’m just too cheap to buy the Avery cardstock–not when I’ve found that I can print ordinary 3×5 cards in my wife’s inkjet printer (an Epson C60).

So, at Don’s suggestion, I re-formatted his format and created both OpenOffice and PDF versions of the cards. I hope you find them useful, but be sure to read the book! Not only is that fair to the authors, but the cards will make a lot more sense to you.

[2020.07.07 Fixed broken link to Don’s version of the cards.]

1 Comment

Categories: Individuals and Interactions

Tags:

Testing that no errors remain

On the Test Driven Development YahooGroup, Alan Baljeu asked, “It is my impression that whenever a feature is added, there may be many things which are affected by adding that feature…. And by not considering those things, you introduce bugs into the software.” In response, he got two types of advice. One was specific suggestions of software construction techniques that can reduce the occurrence of errors by reducing the number of places that need to change when adding a new feature.

The second type was general testing advice. Alan admitted, “I don’t see a way to properly identify what new behaviour will need to be covered. I want to be sure I’m not forgetting cases, but currently I’m overlooking too many of these effects.” In other words, the current test coverage is not catching all the errors. Read More

4 Comments

Categories: Working Software

Tags:

Make it work before you make it standard

Matt Heusser has just published a post about standards. In it, he says

So, when people rush to standards, I hold back a bit. Having a standard means saying “We believe the value of doing things the same, every time, is more valuable than the value of the lessons we will learn by experimenting with new things.”

I, too, have been puzzled by the rush to standardize. Read More

6 Comments

Categories: Working Software

Tags:

When do we get to the stage where we can tell the client what the answer is?

I saw this question in a blog post by Mark Schenk:

About two-thirds of the way through the workshop one of the students asked “when do we get to the stage where we can tell the client what the answer is?” This literally stopped us in our tracks ““ we were so accustomed to working on the basis that complex problems have no single correct answer that we hadn’t explicitly explained this and we had bumped headlong into a prevailing management mindset.

That question struck a chord. I thought back to the days when I first learned XP. Most of the ideas and practices resonated strongly with me. The one that seemed most foreign, Test Driven Development, became a personal fixture after trying it for three days. Yep, this was the way software development should be done! It was so obvious and right, and I told everyone I knew.

They all immediately agreed and thanked me for the information. Well, not exactly. Read More

No Comments

Categories: Individuals and Interactions

Tags: , ,

Book Report: Communication Gaps and How to Close Them

Communication Gaps and How to Close Them I attended a session with Naomi Karten at the AYE Conference last Fall, so I knew she had a lot of good things to teach me. In spite of those high expectations, I was blown away by this book. In fact, the only negative thing I can say is that there’s material for two or three books in here. Having read through it once, I know I’m going to have to re-read it in sections. Read More

3 Comments

Categories: Individuals and Interactions

Tags:

The construction analogy — estimation

What got me thinking about the construction analogy with software development was a recent conversation I had with a design/build contracting company. We’re in the market for a new house. We sketched our design (which we’ve worked on for quite some time) and wrote up a list of general assumptions about level of quality and some details that we wanted. We sent this out as a letter to a bunch of builders.

That sounds somewhat like your typical business requirements document, doesn’t it? It’s too detailed (specifying implementation details) while simultaneously failing to mention important points. But it’s a starting point for conversations. Read More

6 Comments

Categories: Customer Collaboration

Tags:

The construction analogy

I’ve always been of the opinion that software construction is not like physical construction. Or, rather, that the construction part, analogous to hammering two-by-fours together when building a house, is running the compiler. And, of course, you rarely tear a house down and rebuild it over and over, until you get it right. Therefore, software development is nothing like mechanical construction.

Except, of course, when it’s very much like mechanical construction.
Read More

5 Comments

Categories: Customer Collaboration Responding to Change

Tags: