Category: Tools and Techniques

Accounting for Spikes

The term Spike Solution is associated in my mind with the early days of Extreme Programming.  I’m sure that it is built from prior ideas, as everything seems to be. If the term and the concept it describes predates the Chrysler C3 project (Ron Jeffries mentions using it there), I’ve not yet uncovered it. Ron credits Ward Cunningham for the term.  I’m sure there are predecessors, even if not expressed as distinctly.

The goal of a spike solution is to answer a question. For example, a spike may be used to test the feasibility of an algorithm or 3rd party library. It may be used to explore design alternatives for solving a sticky problem.  It’s called a spike because it drives all the way through the problem, but as narrowly focused as possible. It’s not a complete implementation. Associated complexity that is secondary to the question is likely stubbed out to reduce the clutter and increase the focus. Read More

3 Comments

Categories: Tools and Techniques

Tags: , ,

It’s a mystery; I just know.

The first words I learned to read were “off” and “on.” I noticed them on the light switch. By the sounds of the names of the letters, and the effects of moving the switch up and down, I made the connection to the words.

After that start, I was on my way to becoming an avid reader.  It’s not that I read great literature or learned essays. I read pretty much anything that was in front of me. Read More

5 Comments

Categories: Tools and Techniques

The Use of Documentation

Documentation! It’s what we do.

People approaching Agile software development for the first time often ask about what documents are required.  When I ask developers what annoys them most about other peoples’ code, I frequently get the answer that it’s not documented well.  And I can’t tell you how many times I’ve heard people express the opinion that Agile software development is undisciplined because you “don’t do any documentation.”

Why is documentation so important to us? Read More

2 Comments

Categories: Individuals and Interactions Tools and Techniques

Tags: ,

Je suis fatigué.

I’ve been on the go quite a bit the last couple months, and my posting here (or lack thereof) bears witness to that.  I’ve had lots of thoughts too share, but little time and energy to put them into words.

These hurried times included a trip to France, and one of the highlights was visiting the Paris Coding Dojo, the origin of the term.  What an enjoyable evening!  No trip to Paris would be complete without it.  (Well, maybe that’s not true for everyone.)

The short version of the story is that the coding dojo takes a little bit of time to thoughtfully examine our craft and the way we practice it.  The comments made during the dojo were a reflection of the importance that small nuances have in the pursuit of effective programming.  I advise everyone in the software development community to find ways to hone their craft outside of the daily grind of delivering work.

And many thanks to the participants of the Paris Coding Dojo for conducting the meeting principally in English for my benefit.

No Comments

Categories: Tools and Techniques

The Importance of Detailed Planning

I recently wrote on The Importance of Precise Estimates.  This is a related topic.

Mark Levison called my attention to an article by Michael Hugos subtitled ‘Agile projects require more planning and coordinating than waterfall projects‘ on CIO.com.  In this article he advocates answering the question, “Has the scope of any project task changed?” at every daily standup.  He uses this information to update a detailed Gantt chart to provide to senior management.  In Michael’s words,

It also gives senior managers who are not on the project (but who are still ultimately responsible for what happens) the information they need to feel comfortable. And that saves project team members from being distracted by endless management questions and misplaced advice (and nothing kills agility faster than endless management questions and misplaced advice”¦).

Michael, in LOLspeak, “Ur doin it wrong.” Read More

No Comments

Categories: Individuals and Interactions Tools and Techniques

Tags: , ,

Building sand castles on a rising tide

Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips.  I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand.  Too much water and the previous drip will be washed away.  Too little and the sand cracks and refuses to hold together.  I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.

My thoughts are not on the mechanics of building a drip castle with sand.  Instead, I’m thinking of the spire that I’m building.  Can I build these two spires toward each other and form an arch?  Can I make this slender spire taller?

Frequently I fail and a part of the castle slides down, becoming part of the landscape again.  Or becoming a foundation for a new part of the castle.  No matter.  It’s the building of the castle that brings me joy–not the owning of it.  For I will never own it.  The sea soon comes and takes it away.

Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines.  There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time.  Then, Corey would call time, and we would wash away all traces of what we’d built.

Does that sound like a waste of time?

Read More

3 Comments

Categories: Tools and Techniques

Tags: , , ,

Projecting into the Future

In my recent posting on estimation precision, I briefly mentioned how you can estimate when certain features will be done, or estimate what features will be done by a given date, using a burn-up chart.  Some people don’t find this an obvious and easy thing to do.  Let me explain in more detail.

I’ll start with the assumption that you have a list of features you want to add to an application.  Some of the things you want to add may not be properly called features–they might be bug fixes, for example.  And the application might be brand-new, with zero functionality so far.  That’s OK, we can handle cases like that.  Let’s walk through how I do this… Read More

5 Comments

Categories: Tools and Techniques

Tags: ,

The Importance of Precise Estimates

We’ve got a rather old bathroom scale.Borg-Ericson scale, circa 1950 I’ve found advertisements for this model ranging from 1949 to 1954.  My wife inherited it from her mother.  When we first got it, we set the “zero” weight to three pounds to give the “correct” weight.  Now it’s set closer to five pounds when nothing is on it.

The readings it gives are a little inconsistent.  When you bounce lightly up and down, you may get a different reading.  (I tend to take the smallest number I can get.) Read More

20 Comments

Categories: Tools and Techniques

Tags:

More on Automated Acceptance Testing

Jim Shore has posted a response to the reactions about his previous post on Acceptance Testing in which he defends the way he and the teams he coaches are working.  About the same time, Lisa Crispin posted her thoughts on the topic.

As Lisa says,

I can’t tell you the one right way to test and develop software”¦.  The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.

This is an incredibly important point!  There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.”  So I’m happy that Jim and his teams are able to achieve the results they want.  I’m not saying they’re doing it wrong. Read More

1 Comment

Categories: Individuals and Interactions Tools and Techniques Working Software

Tags: