No Substitute for User Input

Whenever I am going to deliver interactive software, I assume that there will be a significant amount of feedback and so I reserver a big chunk of time and energy to deal with that.

I was horrified recently to discover that some programmers feel that I am remiss in gathering requirements, slapdash in my implementation and lacking in my QA. I consider myself to be careful, thorough and to have a high user satisfaction rating.

When I worked through the other programmers' complaints, I discovered that their ideal software development model differed greatly from mine. (And my user satisfaction rating was much higher than theirs, from the same users no less.)

I think that it is instructive to compare and contrast the two models, so that is what I shall do.

I summarize their approach as the classic carpentry mantra, "think twice, cut once." I summarize my approach as "get feedback early and often."

Their model, which is fairly common:

1. Start with a long and thorough requirements gathering phase. The game is lost or won here.
   
2. Write up the requirements into a technical specification. Circulate that spec widely and solicit input.
   
3. Code up the spec as best you can. Write detailed user documentation.
   
4. Test the implementation. Run it through QA.
   
5. Deliver the software to the waiting users.
   
6. Handle the resulting bug reports ASAP.
   
7. Consider the job done and done well. Begin a schedule of releases and updates.

My model, which is certainly not unique to me:

1. Have a longish conversation with the users, mostly centered around them telling me what their ideal solution looks like.
   
2. Create a working prototype as quickly as possible with basic testing only and get feedback. Do a Quick Start Guide as user documentation.
   
3. Process the feedback into work to be done on the prototype. Accepting sweeping changes to the requirements or specs if those changes move you closer to the ideal solution.
   
4. As the prototype iterates through revision, it becomes the first version.
   
5. Over time, issues arise and so there is recoding through the same process.

My basic premises are these:

• Software development is a conversation between you and the users; long pauses will kill that conversation.
  
• No requirements gathering will ever get you more than 80% of the requirements, so plan for real revision at the outset.
  
• Users will happily engage with a dynamic process that produces tangible results

Upon reflection, I could see why my work looks sloppy to them: I put out many versions, I often change my design and implementation, I don't put effort into refining the coding of modules until I am sure that those modules are interested to someone. I don't tend to say "that wasn't in the spec" and I don't complain if things need to change which may seem like weakness or uncertainty to them.

On the other hand, I don't have users who complain that they wait forever for software that doesn't actually do what they need or what it to do.

As is so often the case, each side is not failing at the other's model, each side is succeeding at their own model. I am not impartial, however: I am highly confident that it is better to be one of my users.