Writers Can Teach Us Something About Writing Software

pensIn this post, I’m sharing a technique for writing a software module with you. I’m assuming that we are implementing a user story and that the acceptance criteria are clear. The story has been divided into a set of tasks and the task durations are known.

It’s an approach that works well for me though your mileage may vary. I strongly urge you to refine and tune the approach to your needs and most importantly, to your work style.

If you’ve ever had to write a report, proposal or even a specification, you may have heard advice like the following:

  1. Establish a time interval, say 10-15 minutes and set a timer.
  2. Work on the outline.
  3. Get your major thoughts written down.
  4. Don’t think too much, don’t analyze, just write.
  5. If you get stuck on an item, skip it.
  6. When the timer expires, go back and organize what you wrote into sections or chapters.
  7. Reset your timer for another 10-15 minutes.
  8. Write a section until the timer expires.
  9. Forget about grammar and spelling, just write.
  10. Go back to step 7 and repeat for each section.
  11. Now go back and do some editing for grammar and spelling.
  12. Make additional passes as needed until the document is complete.

What does this have to do with writing software?

Of course, writing software, in any computer language, is more complex than writing a report, proposal or specification. It’s not necessarily more difficult. It’s more disciplined. There are many more rules to follow and external dependencies to worry about.

Despite the added complexity, you can follow a structured approach like the one above. Let’s say you’re implementing a user story. You’ve likely broken it down into a set of tasks. You should have a rough idea of how long each task will take. Many developers will approach the story implementation serially. That is, they’ll work through the task list sequentially.

I do it differently. I iterate over the list of tasks. Here’s a basic approach that you should customize for your situation.

  1. Establish a time interval, say 25% of the total estimated story implementation time, and set a timer.
  2. Create a skeleton of the code (there may be 2 skeletons — one for test code and one for the story).
  3. Get the major sections of the code defined.
  4. Don’t think too much, don’t analyze, just create the structure.
  5. If you get stuck on a section, skip it.
  6. When the timer expires, go back and review what you wrote. Note any areas that need more thought.
  7. Reset your timer for 25% of the story time divided by the number of code sections you have.
  8. Write a section of code until the timer expires.
  9. Forget about covering every detail (e.g. error conditions), just write.
  10. Go back to step 7 and repeat for each section.
  11. Now go back and do some editing, testing and debugging.
  12. Make additional passes as needed until the code is complete.

The approach will vary depending on the situation. For example, if I’m unsure about how something might work or if it can even be done in the manner I’m thinking, I’ll make a first pass targeting the area I have questions about. Once I get that ironed out, I’ll build out the rest of the code as described above.

There you have it — a simple iterative technique for writing software modules. Give it a try.

photo credit: MaryLouiseEklund via photopin cc

Updated: February 26, 2013 — 10:52 pm