5 things you may not know about me
Ok, maybe you already know these things. I’m a pretty open person so there’s not much unknowable about me that I know of. But Johanna tagged me to say 5 things, and these are the ones that came to mind:
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
Book Report: 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
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
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
Conferences and Conferring
Matt Heusser just posted a blog entry on conferences, where he makes excellent recommendations. During much of my career, I relied primarily on magazines and online communications (remember CompuServe?) to broaden my horizons. These were worthwhile, but are no match for face-to-face communications. Read More
Agility and context switching
A Steering manager uses the Law of Diminishing Response as a guide to successful control interventions. When you consider adding some pressure, the key variable to monitor is not people’s performance, but their responsiveness. How are they responding to the existing pressures? When they hear of a new “challenge,” do they drop their head a quarter of an inch and mumble an acceptance under their breath? Do they become annoyed and give a hundred reasons why it can’t be done? Do they show external signs of panic? These are all signs that they’ve reached the point where responsiveness has gone negative, yet they are unable to control their own response.
On the other hand, are people alert and genuinely enthusiastic, able to ask penetrating questions that need answering before accepting the extra work? Can they consciously trade off less important work for high-priority assignments? These are signs that their responsiveness is still above zero, so it’s okay to pile a little more fuel on the fire; but don’t make any assumptions about next time.
Jerry Weinberg, Quality Software Management: Systems Thinking
Last month, Dmitri Zimine posted a small rant against context switching. Read More
It’s all about feedback
It’s stabilizing feedback that keeps a simple amplifier working as an amplifier, rather than pegging the output at the maximum positive or negative voltage. The feedback mechanism observes the output and applies a small correction to the input to counteract overreactions. Because the feedback is swift, only a small correction is needed. In fact, if the feedback were delayed, the output would tend to swing back and forth, oscillating around the desired value.
In iterative software development, we use feedback to keep the project on task. Feedback from our unit tests lets us know if our code does what we intend. Feedback from our acceptance tests lets us know if our code does what the Customer wants. What could possibly go wrong? Read More
Thank you, Duc Tran
Writing my introductory post led me to think of some of the many people who have taught me important lessons. One of those people was Duc Tran, an engineer I knew when I was a technician at Rixon. He taught me a technique for using an index register to keep track of current state, instead of relying on a flock of boolean values and “if” statements. That revelation changed the path of my life, and led me to seeking simpler, yet more powerful, constructs. I was caught in a lay-off (my first of many) not many months later, and I’ve lost track of Duc Tran. I doubt that he’s aware of the influence he had.
It’s perhaps a characteristic of the human condition that we are often unaware of the good we do in the world. We must keep trying in spite of the lack of feedback.
Introduction
Hello. My name is George Dinwiddie and I’m a software consultant and coach. My job is helping software development teams to become more effective, while helping them accomplish their current project.
I started out in electronics. My first job was a TV-radio repairman when I was 14. After some detours such as being an English major in college, a theatre lighting and sound technician, and an organic vegetable farmer, I came back to electronics and ended up as an Engineering technician developing modems. As it happened, this was at the time that hardware was being replaced with software, and I wrote more firmware than I designed circuits.
I’ve since moved from embedded systems to primarily working on business systems–from assembly language, through procedural C and Pascal, to object-oriented Java and currently learning Ruby. And I’ve played with a lot of things in between. Throughout it all, I’ve tried to learn the best ways of doing things. And I’ve certainly learned a lot. I’m grateful to many people who, directly or through their writings, have taught me so much. And I’m very much aware that there’s an infinite amount more to learn.
The purpose of this blog is to share some of what I’ve learned in a more informal manner than the wiki that I’ve been using. Oh, I’ll continue to use that, too, but this vehicle will allow me to publish thoughts without organizing them into a structure. It will also allow for others to leave comments in reply. I’m looking forward to that! Please do let me know what you think.