Hamstaa!

You will often hear the terms "People Independence" or "Institutional Memory" used as a management reason for the creation of the huge volumes of paperwork often created in a BDUF (Big Design Up Front) project. The idea of course is that the presence of the documentation allows the organisation to use developers interchangeably.

For developers, documentation is extremely useful for the those who come after, even if it's you in 12 months time. This documentation however is only useful if it's up-to-date. Unfortunately in most cases it's written, read and never looked at again.

When I was consulting, and prior to my introduction to Agile practices, I often worked with organisations that didn't particularly want to spend time on documentation. This wasn't because they believed it wasn't useful, it was more a cost saving method. Still wanting to provide future developers some form of documentation I became an advocate for heavy commenting of code. Hence, the code became the documentation. 

With my introduction to Agile practices a few years ago the idea of "documentation in the code" has moved on to incorporate and focus on atomic tests. The application of the concept of waste from Lean Software Development on formal documentation also supports the use of atomic tests as documentation (unless the documentation provides some other value than the fulfillment of the process).

So does code (test cases) as a replacement for formal documentation meet the requirements of managers who are looking for "People Independence"? It does if they are looking for a way to fulfill the need to pass on knowledge to future developers. In addition the added benefits of atomic test on quality and confidence for future developers to make changes and maintain current functionality is immeasurable.

Continuing the "Growing Team Leaders" course, last week Greg Stockwell of Public Speaking Australia presented "Public Speaking and Presentation Skills".

Unlike the previous sessions, this session was presented as a series of exercises where Greg introduced a few simple techniques for dealing with the obvious nerves of speaking. Interestingly when you hear people say they don't get nervous when speaking, this can sometimes mean they are overconfident. This overconfidence comes across to the audience as disingenuous.

Greg also presented a few simple rules when speaking publicly. For example

• never tell the audience you're nervous, they'll focus on looking for the signs of nerves instead of the substance of your presentation
• if showing a video, tell them how long it is so they know what to expect
• if possible, see the venue before you speak so you have a sense of the layout and reduce the unexpected
• finally, be yourself, don't try to be something you aren't.

I think the point I really liked, that Greg made, regarding public speaking is

It's not life or death, it's only public speaking.

How do you view and hence refer to the people who buy your software or services? As Customers or Clients?

While it sounds like a simple case of semantics, it is a significant change in how you look upon them and how you treat them.

To explain the difference, consider the following analogy.

We refer to the doctor, lawyer and accountant we use as "My Doctor", "My Lawyer" and "My Accountant" but we never refer to the shopping centre we go to as "My Shopping centre" . It's referred to as "The Shopping Centre".

A customer is someone who you don't build a relationship with. You don't necessarily gain repeat business with. They are someone who can easily switch to a different product (shopping centre)

With the subtle shift to considering them as Clients, you are focussed more on working with them, finding solutions to their problems and gaining their appreciation and repeat business.