The XP folks talk about the importance of making frequent small releases. This method has advantages over and above the obvious ones; not only do you get regular feedback from real users, you also get regular practice at doing a release…
Picture a project. You work like crazy for x months and then, right at the end, you take what you have and release it. But how do you release it.
I always used to think that there was probably a good reason behind things I didn’t understand. Now I’m far quicker at deciding that the reason is that the person who created the thing didn’t understand either.
I’m currently working with a client to aid in the handover of some source code from the original developer to the rest of the development team. An unusual project because the original developer is still around for a while.
In Asserts Redux Dan Dunham and Scott Shumaker are discussing how sometimes testers have to be able to work around assertion failures and how allowing them to do so dilutes the power of the assertions. The discussion moves on to how debug traces can get out of hand and eventually you drown in debug spew.
I find that in almost all cases debug tracing is overused. The problem is, as Dan succinctly puts it: “When you’re writing the code, you put in a bunch of debug statements to verify things as you go.
Kent Beck and the XP guys have a lot to say about the ’the system metaphor’. In XP the metaphor replaces what most other methodologies call ’the architecture’. It’s a single, coherent, view of the system. It gives you a single story from which to choose the names of things in the system. It helps you communicate about the system in a consistent language that even your users can understand.
In February 1995 I flew to Perm in eastern Russia as part of a two-man team installing a smartcard system for a local bank. I was responsible for designing and implementing the card production system that was being used.
For a marketing view of the system that we installed, visit Interlink’s Smart Bank pages. For a personal view, stay tuned…
The other member of the team, David Steed, worked on the overall design and the integration of the system into Interlink’s standard transaction processing system.
