Thursday, December 17, 2015

Reflection During Process Improvement

One of the most important activities when engaged in process improvement involves reflecting upon existing capabilities. True, the activities that sustained development may not improve development anymore. For example, when things have plateaued.

Not everything needs to change--if the business is producing value something is being done right. The trick is to tease out the existing goodness in what's right and identify small improvements to add.

Friday, December 11, 2015

Agile! The Good, the Hype and the Ugly (Test-Driven Development)

I’ve recently purchased Bertrand Meyer’s book “Agile! The Good, the Hype and the Ugly”. Meyer looks at Test Driven Development (TDD). Meyer’s discussion on TDD adds clarity to the murkiness surrounding it: no code without tests. Nuff said.

Is no code without tests enough?

Nope.

Testing shows the presence, not the absence of bugs. [Dijkstra]

Meyer's also points that its impractical to expect that you not start any development until all tests pass. You may justifiably document the existence of bugs during development and rightly spend your time working other parts of the functionality that are deemed important.

In "Why Most Unit Test is Waste (A Look at Test Driven Development)" I point out a vagueness surrounding when to begin TDD. This vagueness manifests itself in the form of bootstrapping your architecture. The answer isn't in that article because it goes against Agile principles (Working Software instead of comprehensive documentation). The answer is you create an architecture then move on to the development and testing (in which ever order you prefer).

Practically speaking there isn't a one-size fits all answer to these questions. Experience and knowledge play a big role in the decision on how much is enough. I do like Leslie Lamport's position in Thinking for Programmers: create a blueprint with enough detail to permit you to continue.