function _processMenuItem( &$oMenu
, $oMenuItemElement
, $sMenuData
, $bSelected = false ) {
// TODO: Sort this out, it sucks!
global $IMAGE_PATH;
No shit Sherlock.
Friday, May 27, 2005
Code found wanting...
No shit Sherlock.
Tuesday, May 24, 2005
Bobablog hits Google
Monday, May 23, 2005
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.
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.
Thursday, May 19, 2005
M*A*S*H
In Dinosaur Brains, Albert J. Bernstein described the M*A*S*H unit:
"You know the show: a bunch of intelligent, antiwar doctors are competent and loving. In a crazy situation, they keep themselves sane by going crazy. You see M*A*S*H units developing, especially with young, bright, creative people.
Notice the crazy hats, the rude parody of the corporate logo, the graffiti on all the posters, and the strange outfits in the software development department of your company or your own particular M*A*S*H unit. What you're seeing are the behaviours that intelligent, creative people come up with when they feel disenfranchised or under almost intolerable stress."
I think there's at least two things going on here. First there's the intelligent and creative worker's tendency to decorate their workspace in a creative way. Secondly there's the disenfranchised workers tendency to attack the organisation.
The first should be encouraged as a creative mind's way of expressing their individuality; The second should be used as a warning signal to management that there's a morale problem. The two shouldn't be confused.
Of course, there's a behavioural difference between having a giggle with the people you're working with and goofing off. There's a creative difference between having a photo of your child and a cuddly toy on your desk and having a piece of photography and some lego models.
We have a giggle, and we've got a lot of lego. We find the lego not only allows for people to express themselves in their space, but is also a great tool for focusing the mind. When someone is mulling over a particularly tricky problem or musing on the future implications of a problem they will often find that they'll pick up a some lego and just fiddle.
Thankfully we've got a management team that accept the fact that we're not just mucking about. Not all companies are quite so forgiving...
"You know the show: a bunch of intelligent, antiwar doctors are competent and loving. In a crazy situation, they keep themselves sane by going crazy. You see M*A*S*H units developing, especially with young, bright, creative people.
Notice the crazy hats, the rude parody of the corporate logo, the graffiti on all the posters, and the strange outfits in the software development department of your company or your own particular M*A*S*H unit. What you're seeing are the behaviours that intelligent, creative people come up with when they feel disenfranchised or under almost intolerable stress."
I think there's at least two things going on here. First there's the intelligent and creative worker's tendency to decorate their workspace in a creative way. Secondly there's the disenfranchised workers tendency to attack the organisation.
The first should be encouraged as a creative mind's way of expressing their individuality; The second should be used as a warning signal to management that there's a morale problem. The two shouldn't be confused.
Of course, there's a behavioural difference between having a giggle with the people you're working with and goofing off. There's a creative difference between having a photo of your child and a cuddly toy on your desk and having a piece of photography and some lego models.
We have a giggle, and we've got a lot of lego. We find the lego not only allows for people to express themselves in their space, but is also a great tool for focusing the mind. When someone is mulling over a particularly tricky problem or musing on the future implications of a problem they will often find that they'll pick up a some lego and just fiddle.
Thankfully we've got a management team that accept the fact that we're not just mucking about. Not all companies are quite so forgiving...
Wednesday, May 04, 2005
REALLY don't fancy yours much
Looks like it was a really lucky escape from the ravenous Bulldog.
The Register have spotted Bulldog-hell
The Register have spotted Bulldog-hell
Software development companies need not prevail
Jay Fields suggests in a blog entry that the idea of in-house development is flawed and needs to die here... (I'm paraphrasing)
Sorry Jay, but I really disagree. There's nothing inherently wrong with the idea. The problems you cite are problems that any short sighted organisation will find when they're attempting to build software. I've worked for a couple of software houses and those I've worked for suffer from exactly the same problems described. Short sighted recruitment processes, cost cutting exercises, low quality code.
True, when you're working in-house these problems may be more common. The terms 'cost-centre' and 'profit-centre' are two that really cut to the bone.
However, I'm now working as an in-house developer with a team where the staff turn over is extremely low (around 10%), the team is built of very high calibre developers, morale is high, uptake on new technology is measured in relation to reasoned benefit, code quality is higher than I've ever seen before and customer satisfaction is through the roof.
We don't have any external people / consultants / software houses involved and I don't see any reason to have any.
In-house development isn't necessarily doomed to failure. Short sighted, cost driven organisations are the problem, and software houses are by no means immune to it.
Sorry Jay, but I really disagree. There's nothing inherently wrong with the idea. The problems you cite are problems that any short sighted organisation will find when they're attempting to build software. I've worked for a couple of software houses and those I've worked for suffer from exactly the same problems described. Short sighted recruitment processes, cost cutting exercises, low quality code.
True, when you're working in-house these problems may be more common. The terms 'cost-centre' and 'profit-centre' are two that really cut to the bone.
However, I'm now working as an in-house developer with a team where the staff turn over is extremely low (around 10%), the team is built of very high calibre developers, morale is high, uptake on new technology is measured in relation to reasoned benefit, code quality is higher than I've ever seen before and customer satisfaction is through the roof.
We don't have any external people / consultants / software houses involved and I don't see any reason to have any.
In-house development isn't necessarily doomed to failure. Short sighted, cost driven organisations are the problem, and software houses are by no means immune to it.
Tuesday, May 03, 2005
Don't fancy yours much
I little while ago I was looking for a broadband connection. I almost went with Bulldog. Glad I didn't. Someone out there's really not happy with the service...
Bulldog Hell
Bulldog Hell
Subscribe to:
Posts (Atom)