It has often occurred to me that ‘fear’ (in many, many different guises) is actually an ever-present and sometimes overriding–yet still subtle and often unacknowledged–term in the decision-making equation.

Fear manifests as inertia and paralysis, as a defence mechanism, as an incongruous response to a stimulus, as detachment and in many other ways.

It’s good to see a few comments that address this.

How to transition the workplace from one based on “Darwin selection based on resistance to fears” to ‘”fear free” places.’ There’s the question!

I’ve been known to say: “Don’t start a Java application without Spring. Ever.”

The primary reason for this is versatility. I can and have used Spring to:

• Develop various species of plain ‘ole web applications
• Develop webflow-based web applications
• Develop reporting applications incorporating eclipse BIRT
• Develop Swing-based desktop applications (using TeeChart)
• Develop batch processing systems
• Helped develop XML pipeline processing systems (alongside Stylus Studio‘s XML processing framework)
• Develop system integration processing flows
• …and probably a few more bits and pieces…

The Spring-oriented skills I have built up have let me work in a substantially standardized way regardless of the situation.

That’s pretty darned good, if you ask me!

Is this same story true of the obnoxious OSB? No.
Is it true for any implementation of the J(2)EE spec.? No. From any vendor? No.
Is it true for other frameworks like JBoss Seam. No.

Anyone know of any other framework out there offering similar flexibility, ‘cos I’m darned if I do.

The Spring framework isn’t standing still, either…it’s the foundation for both Grails and Griffon. As I have adopted these technologies, my productivity has increased greatly. I am “standing on the backs of Giants.” This is a Really Good Thing.

Let’s add a modicum of “Systems Thinking” here. Rather than wasting time training a multitude of staff in a multitude of (typically short-lived) siloed technologies…some of which are honestly horrid…it makes much more sense to build a solid core of experience with a solid core technology.

Whoops! Here I go advocating a standards-based ICT world…again.

‘Standards.’ “Systems Thinking.” How naive am I!

[...edit...]
Received an email from Manning the publishers a while back:

I know that this is not a scientific measure of ‘goodness’ (if one were even possible), but it speaks volumes to me…

Today was “first-look” day for the users of the system that I am currently working on.

After observing the users start in on the system and then watching them hack around the screens for a while, it occurred to me that I was seeing (at least, probably) three different types of behavior.

My background as a chemist came to the fore at this point and it occurred to me that I was actually seeing three states of matter at play.

The first state: solid. This type of user basically stayed where they were put. They logged in, typed what they were told to type and seemed happy to do nothing else.

Next were the liquids: these guys showed a bit more ability to ‘flow’ around the system than their colleagues. They found more ‘features’ and generally got more involved in things.

Then came the gases. These whizzed all over the place, escaping the confines of the system and generally finding leaks and holes all over the place. In the long run, these users were clearly going to be the most reactive and energetic. They were most likely to get the best return on their efforts.

Quite a nice analogy :-)

Now here’s the clincher.

As one develops and tests software one needs all three of these states at some point.

You can maximize your testing if you can arrange your user testing so that it…and your user communities…follows nature’s path: solid – liquid – gas.

You’ll find that the solid testers will pick up the easy, common, 80% of impactful bugs and –importantly–will be happy doing so. At the end of solid testing, you won’t have the perfect system, but you will have one that satisfies a good proportion of your user community’s needs.

Follow up with the liquids…they will help you trap some of those more grungy edge cases that always seems to be forgotten about. Again, the quality of the system will be increased and you will have another user community that is nicely ‘behind’ you.

Time to let the gasses roam free! They’ll get into the last remaining nooks and crannies and the result will be a good stable system. The gasses will be happy, knowing that they have contributed in a meaningful way without being waylaid by–to them–trivial and easy/’obvious’ issues.

Like all analogies, this one breaks down fairly quickly: in the chemical universe, there are so many more gasses than solids ‘out there.’ For testing, the reverse is true.

This reminds me of how systems like submarines are pressure tested with nitrogen, so there must be some truth in it, somewhere…

Sadly, today we didn’t follow nature’s “true path” to testing nirvana!

Still: epiphanies have to come some time…usually as a result of some quantity of pain.

For sure, I’ll be better able to express what I want from a testing process next time. We live and learn!

Testing philosophy, what next!

Eat your hearts out Kant, Heidegger, et. al…

[...edit...]
“Time to let the gasses roam free!” is not a reference to bodily functions! Shame on you, gentle reader (you know who you are)!

With exercises, too!

Wish I’d been there…

One comment that that resonated with me stressed how important it is to characterize changes differently from actual bugs. Having the Product Owner tell you “We forgot about X” does not actually mean that a bug has crawled into the system.

A few take-aways (I’m paraphrasing, forgive me if this isn’t exact but you’ll get the gist):

• Agile doesn’t stop you making mistakes, but it does let you identify the mistakes earlier…then then (hopefully) you can take appropriate and effective action
• Your Product Owner needs to be able to make real decisions (otherwise you’ll suffer looong delays, which warps planning and results in low velocity)
• The relationship between Product Owner and ScrumMaster is very important
• Analysts should run only one sprint ahead or the developers, otherwise everyone’s heads are in different ’spaces’
• Work with your Product Owner (and stakeholders) early and often
• When interfacing with other (waterfall/non-Agile) groups, treat their needs as high priority
• Poor information radiation can lead to problems
• Planning Poker works. Nicely.
• Don’t focus on showcases…this is a sure way to build up technical debt!

The key takeway:

• Your “Definition of Done” has a far-reaching effect, so spend time on formulating and reviewing it

Thanks, James!

I just attended Brisbane CITCON 2009.

To my surprise, I greatly enjoyed the event. Thanks to all concerned!

I said ’surprise’: this is the first OpenSpace event I have ever been to. I expected (with a smidgin of dread) a Gen-Y look-at-me-aren’t-I-clever-don’t-tell-me-things-I-don’t-already-know ego-fest. I found a group of passionate (mostly non-Gen-Y, it has to be said) cluey developers getting together to show&tell and discuss real issues, problems and solutions.

A couple of piccys. The first is of the collaboratively-produced topic board/conference schedule:

Living proof that the agile concept of “no centralised control” can work…

The second piccy is of the illustrious Dr. Paul King of ASERT, in his presentation groove(y):

And no conference could possibly be complete without a T-shirt:

There’s a Flickr page.

For some reason, I had expected a Ruby love-in. I had expected to hear the fanboys raving about how Ruby was innovatively solving the problems of testing and CI. Half of me had been hoping to see/hear this. There was some nice stuff about Watir but nothing that changed my world-view (I’m actually a little disappointed…it’s A Good Thing to have one’s world-view shaken up a bit every now and then ;-)).

I confess to being a little surprised to not hearing a Hudson buzz; IMHO it’s an excellent CI server. I was unsurprised to be hearing a Git buzz…confirmed my opinion that this is the Next Big Thing in Version Control. I was quite surprised when a “hands up” survey asking “who knows about JMeter” failed to elicit more than a couple of hands in the air…wake up people!

In (sad) contrast to the Oracle Free Breakfast Session I had attended a few days previous, this free event was worth far more than I paid!

In summary: an excellent event. Recommended.

[edit]
Can you see me?

When Working Software Is Not Enough: A Story of Project Failure, presented by Mitch Lacey.

Sigh. So depressing.

Maybe having an Agile Maturity Model is actually A Good Idea.

“You’ll Never Be A Good Agile Developer!” came the immediate pronouncement.

Take that! Put me in my place!

Apparently, in the mind of this young guru, mastery of every keyboard shortcut of an editor (although which particular editor this person had in mind remained unspecified. He’s a Ruby fanboy I believe, so I’m guessing that it would be something Mac-ish) was a prerequisite for agile development.

After a while, the conversation changed tack and this intense young thing–bemoaning the overall state of the I.T.world–pronounced that it would probably be better if he went back to Uni. and completed his Arts Degree.

Stepping back through the mirror, I thought it would be fun to think about all the editors that I have failed to adequately exercise over the years.

Ignoring non developer-oriented things like Microsoft Word and Adobe FrameMaker, and oddities like runoff/[nt]roff/TeX and even odder things like Literate Programming’s tangle/weave I came up with this:

(there are others…I’m pretty sure that the Simula 67 system I used for a while had a weird development ‘environment’ that I didn’t really delve into; ditto for the eiffel system I used…)

Given all this, it is patently obvious that I’ll never be A Good Agile Developer, but let’s remember the Agile Manifesto, which states (in part):

…we have come to value:

Individuals and interactions over processes and tools…