Developer Factory

Gotta say, I'm enjoying Object Thinking. David West is a bit of an evangelist but it's difficult to argue against many of his points.

One such point is that eXtreme Programming isn't about creating high quality software, it's about creating high quality developers. The by-product of having high quality developers is that high quality software is produced. I'm worried that tight fisted IT Managers might get their hands on this thought and start charging training costs to employees for working in an XP environment, but it is a good thought none-the-less.

It's also something that each developer should bear in mind when working in that XP environment. Every piece of work that's done is an opportunity to become a better developer. You're in full time training. Sometimes you're the trainer, other times you're the student. Most the time you're both. By sitting back and explaining certain assumptions you find flaws in the those assumptions. By teaching people what you do and how you do it, you spot problems more easily. Plus, of course, there's someone sat next to you that will tell you when you're wrong.

It's a thought I've always had lingering in the back of mind, but it's probably always been 'Me Teacher, You Student'.
I'm wrong, and I need to learn to change that attitude. We're all learning and improving the way we work through our interactions with other.

When we forget that we've got a lot to learn then we start going backwards again.

Technorati Tags: extreme+programming, David+West, pair+programming

Good conversations...

There's one going on over here.

Code found wanting...

function _processMenuItem( &$oMenu
                         , $oMenuItemElement
                         , $sMenuData
                         , $bSelected = false ) {
  
  
 // TODO: Sort this out, it sucks!
 global $IMAGE_PATH;

No shit Sherlock.

Bobablog hits Google

It's finally happenned. The outside world (Google) has finally found me. Fair enough, a search for Robert Baillie still brings up some 17th century scottish 'divine' from Jarviswood... but search for Bobablog.

Just try to stop me now!

Google

Technorati Tags: bobablog

Testing a metaphor

In Object Thinking, David West reminds us of Christopher Alexander's (the father of patterns) example of "fitness":

Alexander points to the task of making a metal face smooth and level. A standard block, smooth and level to a precision greater than required by the target metal face, is inked and rubbed against the target. The presence or absence of ink on the target indicates high and low spots that need to be reground.


This is a great example of testing.

The standard block is the test code. The block defines the "shape" of the resulting code. The imperfections that exist in the block will be duplicated in the production code. The time spent perfecting the standard block is time spent perfecting both the test and the production.

The standard block can't be produced in the same way as the production plate as that would require another standard block. A test can only really be tested by inspection.

Pressing the standard block against the plate is performing a test, but the method of applying ink to the block is the realisation of a test report. The ink reports not only that there is a problem, but also pinpoints what the problem is and where it exists. It guides the tester to the place where work is needed. Every test has to give you an indication of overall success or failure, but a good test gives you a clear guide to the cause.

The rig that presses the standard block to the plate is the test setup and teardown. It allows the test to be repeated easily, ensuring that the standard block is level when it's pressed against the plate. This makes sure that all the ink that's on the block is on there because of a test failure rather than a difference in the way the test was performed.. There's no ambiguity in the results; patches of ink means failure.

Adding a process that takes every production plate and presses an inked standard block against it, detecting the ink on the production plate automatically would be the implementation of automated testing.

It's a repeatable test; it gives clear indication of success or failure; it guides you to the problem if a failure exists; it can be easily embedded within an automated process.

Updated:
Another good reason why it's a great test:
Whilst it tells you what the problem is and guides you towards a solution, it doesn't tell you what method you should use to implement that solution.