Hamstaa!

We are getting our bathroom renovated at the moment, and the completion date has been extended by a couple of days.

I guess it should have been expected, but what was interesting was that it seems the delay is not due to unexpected issues in the fit-out (as in water damage, etc) but rather the delay in the supplier getting the taps to the company doing the work.

Talking to the plumber, the problem lies in the suppliers not having stock sitting in local warehouses. Now this wouldn't have been a problem, but the time from agreeing to do the project, and it starting was very quick. As such, the time for the delivery of taps was longer than the time until they were needed. So if we weren't able to kick off this project so quickly, then they could have ordered those items in advance enough to get them here in time.

This got me thinking about Lean development practices and the “Just in Time” approach. If we consider that the aim is develop something “just in time” for when it is required, then it is possible that an opportunity may arise that, to take advantage of, would reduce the available time to develop and subsequently cause delays.

Of course the trade-off of doing “Just in Time” is that you aren't building a stock-pile with all the inherit costs and problems. It does however mean that the critical path analysis for taking advantage of a sudden opportunity does require you to know the “Just in Time” periods that could affect you.

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.