First page Back Continue Last page Graphics

Fading ripples


Notes:

One of the things that aided the adoption of new methods was the awareness that “something has to change”. People were ready to follow anyone with a new ideas. Once the ideas were no longer new enthusiasm wained. (This is the same phenomenon reported as the “Hawthorne Effect” by Mayo.)

Review meetings became less effective as people failed to examine documents beforehand. This led directly back to developers inventing their way through the gaps and ambiguities in the requirements and design documents.

As more and more people were introduced to unit tests the rationale for using them got lost. Some very vocal developers promoted the view that they could work faster if “someone else” wrote the unit tests – and that this would help ensure that the tests were meaningful. (Independent verification like this is all well and good, but is even more costly in terms of development time.)

With increased size of the system (more dependencies between components) issues arose with the setting up of suitable test data that were not managed. Hence, instead of finding ways to address these issues, unit tests were abandoned by some projects.

Issues also arose with the version control system – partly because we had not put in place an effective way of managing database changes, and also because there was a failure to introduce developers and delivery staff to the principles adopted.

Having thihgs documented doesn't ensure that people actually read the documentation:
http://www.octopull.co.uk/java/Introducing_JUnit.html
http://www.octopull.co.uk/VCS/

There was an interesting pattern of behaviour: developers that had worked throughout the pilot project were committed to it. Other developers had strong reactions either for or against the changes.