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.

Losing Customer Focus

Southwest Airlines has long been known for two things: low prices and attention to customer service. Since they instituted the “reserved place in line” so I wouldn’t have to stand for a long period of time, I have come to check their website first, and only rarely look for alternative flights. Sadly, they’ve taken their eye off the ball. I suspect that the focus on customer service has been replaced by a focus on growth (given their in-progress takeover of Airtran).

Some months back, I noticed that their website had become bandwidth greedy with javascript doodads. This made it painfully slow on many hotel internet connections. They seem to have backed off from that a bit, but have now broken it in a way that prevents me from buying the ticket I want. (In addition, when I call the “Southwest Airlines Customer Representative for assistance” as prompted on the website, I find they no longer have enough to handle the call volume. I wonder if they’ve reduced the support, or if the call volume has increased, or both.)  There’s a lesson here about considering all of the important user stories when implementing new functionality, so it bears describing. Read More

No Comments

Categories: Customer Collaboration Working Software

Do Not Drive Beyond Your Headlights

I’ve heard stories where organizations have “tried Agile” and the results were so bad that they’ll never make that mistake again. In some of these stories the blame is laid at the feet of bad coaches. In some it’s blamed on lack of coaching. In some, the blame is placed on clients who aren’t ready for Agile . If blame is to be lodged, then any of these will do.

The more interesting question, to my mind, is how can we achieve a better result. Read More

1 Comment

Categories: Responding to Change

Tags: ,

Seeing the Wind

I’ve just spent the past week at Junior Sailing Camp, helping kids circa age 10 become better sailors. At this age, they’ve learned many of the basic concepts: that pushing the tiller to starboard turns the boat to port, that they need to pull the sail in when going upwind, and let it out when going down.  Yet they often struggle to get the boat going in varied conditions.  They steer too vigorously  in light air or choppy waters, killing the delicate momentum they’ve achieved.  They position the sail inefficiently–sufficient for a moderate breeze, but insufficient for zephyrs. And in heavier air, the wrong sail trim may result in an impromptu capsize drill.

Much of my coaching depends on helping them observe these varied conditions and how the results of their actions are affected by them. Their current skills work fine when the conditions match the way they practice them. When conditions change, the same actions fail. Without keen observation, the cause of that failure is a puzzle.

I’m teaching them to see the wind. Read More

3 Comments

Categories: Responding to Change

Tags: ,

Don’t You Have to LOGIN first?

In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere. I was also in that list discussion.

Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.

There are some very good reasons for this. Read More

4 Comments

Categories: Tools and Techniques

Tags: , , ,

Avoiding Iteration Zero

Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with

  • A list of features to be built
  • A release plan or timeline for those features
  • Setting up development infrastructure such as version control or continuous integration servers
  • Studying or practicing skills in new technologies they expect to use
  • … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.

The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?” Read More

23 Comments

Categories: Tools and Techniques Working Software

Tags: , , , ,

On Models

Brian Marick has written a tantilizing post The Stance of Reaction. In it he says

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me. Read More

2 Comments

Categories: Individuals and Interactions Tools and Techniques

Tags:

The Carrying Cost of Code

Michael Feathers has just written a post on The Carrying-Cost of Code: Taking Lean Seriously.  He says,

No, to me, code is inventory.  It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.

I’m not sure I can see the analogy of code that’s in production to inventory.  Code that hasn’t shipped, yes.

But all code is a liability, I think.  When code is in production, then it’s offset by the asset that is the functionality.  Whether or not the net is positive is another question.

There’s no doubt to me that code, whether in production or not, has carrying costs that are larger than generally realized.  Perhaps it’s a depreciating capital expense?

Carrying costs are larger than we think. There’s competitive advantage for companies that recognize this.

It’s something that takes up space.  It takes maintenance.  It takes attention.  It does have a substantial cost of ownership–larger than we think.

The analogies may be failing me, but I think Michael’s sentiment is correct.

2 Comments

Categories: Working Software

Tags: