Category: Uncategorized

Posted on by

Short-term planning: A continuum of effective practice

There’s been an ongoing discussion in IT circles about estimation. The discussion dates back as far as I can remember in my career. As far as I know, it began much earlier than that; possibly around the time people began to apply software to serious matters, which would have been a few minutes after the first digital computer was powered up.

People have focused on estimation for such a long time that I sometimes wonder if they have lost sight of the purpose of software. The practical value of software is not realized through an estimate. An estimate is not a product. Customers don’t buy estimates. Even when a client pays a consultant to provide an estimate for a project, the estimate itself is not the thing that ultimately interests the client. It is only a step toward making a decision about whether and how to go about a proposed initiative. An estimate is a means to an end, not an end in itself. Continue reading Short-term planning: A continuum of effective practice

Posted on by

An old metric revisited: Comparing estimates with actuals

Back in the Old Days, project managers seemed to be obsessed with comparing time-based task estimates with the actual completion times of those tasks. When estimated and actual times didn’t align, we were advised to get better at estimating. The goal wasn’t really to learn to create perfect estimates. The goal was to achieve some level of predictability in an inherently unpredictable process for purposes of short-term planning.

Nowadays we know that the fine-grained estimates we might use to inform our short-term planning in the course of a project are not “the product” for which our customer is paying, and therefore are a form of “waste.” We’ve looked for (and found) alternatives to time-based estimation that can provide the information we need to plan our work without the overhead of preparing time-based estimates for individual tasks.

At two different clients this year, I’ve seen people comparing “estimates” (actually, relative story sizes) with the actual completion times of user stories, but not for the purpose of short-term planning. Continue reading An old metric revisited: Comparing estimates with actuals

Posted on by — 6 Comments

Testing as the core discipline of software delivery

Of the basic disciplines involved in software development and delivery – analysis, design, programming, testing, management, deployment, operations, architecture, etc. – programming is usually seen as the most technically demanding and complicated to learn. Many people look primarily to programming when they assess the effectiveness of their software delivery processes. Historically, the knee-jerk response to slow delivery has been to hire more programmers. After all, software is code, right? Therefore, if there’s a problem delivering software, it must have something to do with the way it’s coded.

After some 36 years in the IT industry, most of it in a hands-on software development role, I’ve come to the conclusion that the core discipline in software development is not programming, but rather testing. Even if programming is objectively more time-consuming to master than the other disciplines, it seems to me that testing is more critical to success. Continue reading Testing as the core discipline of software delivery

Posted on by — 7 Comments

I know how to tie my shoes

Recently there have been numerous discussions online about the difficulty of convincing people to try unfamiliar software development techniques that technical coaches and mentors consider useful. The same discussions have been taking place for many years, with no progress. Why is there no answer?

Continue reading I know how to tie my shoes

Posted on by — 4 Comments

The future casts its shadow across the past

I don’t know the origin of that saying. When I first heard it, it was presented as ancient Chinese wisdom. In the West we often attribute pearls of wisdom to some named or unnamed ancient Chinese philosopher. I suspect many of the attributions are not historically accurate. In any case, the saying suggests — correctly, I think — that by examining the past we can make some predictions about the future…within limits, of course.

One of the hot topics of discussion in software development circles these days is the question of how we can make useful predictions about the future for purposes of planning software delivery activities. The subject turns out to be trickier than I had, um, predicted.

Continue reading The future casts its shadow across the past

Posted on by — 6 Comments

Attitudes toward continuous improvement

Question: Is it a general pattern that organizations in need of improvement tend to be satisfied with the status quo, while organizations that pay attention to improvement tend to forget that they already do many things very well?

Here are sanitized descriptions of four client environments where I’ve worked in the past few years. Continue reading Attitudes toward continuous improvement

Posted on by — 11 Comments

TDD and software archaeology

Can you tell by looking at the unit test cases whether the code’s author wrote the tests first? During a TDD class I taught last week, one of the participants suggested that you can’t tell. Completed code and unit tests would look the same regardless of which had been written first. At the time I didn’t give the comment much thought.

I returned to the team I was working with at another client on Thursday, the last day of their iteration cycle. I picked up a small story so I could contribute something before the end of the day. It was a bug fix for JavaScript input validation logic in a webapp. Like many applications, this one uses date ranges to activate and deactivate certain data values that drive functionality. In this case, the input validation function neglected to ensure the expiration date was later than the effective date. Continue reading TDD and software archaeology

Posted on by — 16 Comments

Delivering provably-correct code

A while ago on this blog I mentioned the idea that a programmer’s job is not to deliver code, but to deliver provably correct code. Twitter responses ranged from strongly negative (wrong on so many levels I don’t know where to start) to mildly negative (not completely wrong, but incompletely right). There were no positive responses.

The converse of deliver provably correct code is deliver crap code, as I read it. Yet, it seems unlikely that is what those people meant to say. Unfortunately, no one followed up to explain their interpretation. I can only speculate that my choice of words has different implications for them than it does for me.

Since no one wants to explain their interpretation of the phrase, I’ll explain mine.

Continue reading Delivering provably-correct code

Posted on by

Lean Kanban France 2012 will take place 18-19 October

Lean Kanban France 2012 is coming up in a couple of weeks. The conference will be hosted on 18-19 October by Valtech at their offices in the heart of Paris.

I’m honored to be included on the program of an event that features so many luminaries in the field. My small contribution will be a session entitled Structural Impediments to Lean. The premise is that the conventional organizational structures and basic assumptions regarding roles and procedures tend to present obstacles to the effective use of Lean thinking in companies. It’s a subject I started to explore in earnest a couple of years ago at Lean Kanban Europe 2010 and have continued to explore in my work since then.

Here is the session description from the program.

Continue reading Lean Kanban France 2012 will take place 18-19 October