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

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

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

5 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

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

OpAmp with FeedbackIt’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

1 Comment

Categories: Responding to Change

Tags: ,

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.