What is Design?

I see many discussions get heated or go in circles when the topic is “design.” In the field of software development, what is design? (Continued)

I feel better, now

Oops! The whole problem started when I wanted to install a new program on the “entertainment computer” that’s connected to the TV. The existing version of Ubuntu was no longer supported, so I started what I thought would be a simple upgrade. Oops, it deleted the entire /var directory, including the contents of the second drive mounted there. That drive contained all of our photos and music. Not a problem, I thought. It’s all backed up nightly onto a USB drive. It’s just a bit of bother to copy all of that over the USB interface.

Oops! There are no photos beyond last March. I felt sick to my stomach. That’s a lot of family memories to evaporated. Whew! The program we’ve been using to download the cameras also makes a backup copy local to the machine used to download. I’ve got all the pictures back on the photo server, and now just have to sort them into directories again.

But first, I need to fix the backup script. Why didn’t it warn me when it started to fail? (Continued)

Tips and Advice: Test Driven Development

Yesterday, Bob Payne published one of our informal Tips and Advice discussions on the Agile Toolkit. Check out our Test Driven Development podcast and let me know what you think.

The Code of Christmas Past

When we write code, we’re often thinking about the short term. We need this code to function correctly so we can deliver within our immediate deadlines. I’ve found it important to also think of the long term. Sooner or later, we might encounter our own code, again.

I spent a chunk of my career where I often worked solo on projects that might get enhanced every year or two. This taught me a lot about the importance of code readability and what sort of things helped me quickly understand and avoid overlooking important considerations. I’ve also worked on a lot of legacy code bases, so I’m well aware of the pain and problems created by code that’s not readable, or is not organized in a helpful manner. (Continued)

A Virtue of Imprecise Measurements

I’ve talked about The Importance of Precise Estimates. In that post, I said,

My advice is to

  • measure your progress
  • watch the trends
  • project the trends tentatively into the future

and relax.  It’ll work out the best it can.  False precision won’t make it any better.

Now I just read The Virtues of the Imprecisely Measured Self by Alex Knapp at Forbes. He tells the tale of a study in the journal Psychological Science April 2011 that indicates that precision, whether false or not, inhibits success.  Alex summarizes,

Precision can actually be the enemy of performance goals. To be sure, feedback is definitely a positive thing. But it appears that if you want to keep yourself motivated, it’s best to get a more generalized, imprecise feedback that lets you know you’re heading in the right direction, rather than the precise coordinates of where you are on the path.

It’s something to think about.

 

Podcast: Story Granularity

Bob Payne has released another of our conversations, this one on the granularity of stories (and a little tidbit on home remodeling–that was a surprise). We talk about what makes a good story, and how to get them smaller to make iterative-incremental software development easier and more sustainable.

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. (Continued)

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?” (Continued)

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. (Continued)

Simplicity and Perspective

Everything should be made as simple as possible, but no simpler. — Albert Einstein

Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup.  It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work.  From there it spawned a long discussion about various ways to estimate the work and commit to it.

To me, most of these approaches to estimation are more complicated than is necessary.  Some go into detailed calculations that are far more complicated than what most teams do.  I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. (Continued)