Conscious Development

This post also got deleted in hacker attack. It was mainly about my talk in a Nice tuesday event.

Documentation is often considered a distinct phase of software development. Very few admits enjoying documentation. It’s become the dark side of development which is most often tried to be left undone. The excuses are many, misunderstood agile software development processes being one the most recent. “We use Extreme Programming – we don’t make any documents!”

If documentation is kept as a separate phase, performed after coding, we will face similar problems as we do if testing is postponed until coding is finished:

1. When we run out of time, the phase in question won’t get done
2. The phase will be an enormous effort and unpleasant as such, we are coders after all. Documents are easier to write in smaller parts. For example, writing down what you have accomplished this day isn’t such a big deal. It’s easier to write when you still remember what you were thinking.
3. The task is easily given to someone else. It’s most efficient when the same person wo wrote the code, also writes the documentation.
4. The outcome of the phase are of no use to the previous phase: if documents are written/tests done along with coding, it will be profitable immediately. You’ll think about your code from a different point of view and you may even find a major flaw in your design!

I hear often “I’ll document the code when it’s finished”. But as often the code will get taken to production before it’s ready. And at that point there’s no documentation.

So, always document your code as you make progress!

Christmas is wonderful time for reading. You don’t have anything more meaningful to do anyway

Mike Cohn‘s Agile Estimating and Planning happened to be on top of my reading stack. What a wonderful book it is! It stroke right into my thinking about conscious development. He provided excellent advice on estimating projects, prioritizing features, planning projects, planning iterations, calculating benefits, communicating progress, scheduling etc.

Most often these things are either done hastily or not at all. But you really have to do them, and do them consciously.

Most projects contain a tremendous amount of uncertainty. This uncertainty is often not fully reflected in the schedules and deadlines that project teams create. There are times when this uncertainty is so large or significant that extra steps should be taken when estimating the duration of a project.

The bottomline is this:

• You have to be able to justify any user story / project
• Do the planning, make the plans visible, and change them as needed
• Admit the uncertainty there is and plan for it
• Make wise estimates don’t just have a guess

Highly recommended to everyone! Really, I can’t say is this book for developers or managers. It gives excellent advice for project managers and project owners on prioritizing features, on the other hand, it says a lot about estimating the size of a user story – an activity best done by a developer.

It matches my thinking: there should be no project managers, developers and customer – there should be unified teams. And this book is excellent reading for a team!