This is an old one (rooted in the 40ies) Kelly’s 14 Rules

Well in a nutshell, there are The Agilists (and as they are very smart people they already noticed themselves)

Anyway, I came across these rules by some pointless surfing and was struck by the resemblance and the difference to what I know about Agile. So I began dissecting them in my mind and to help myself putting some order into it - and to share it with you - I am writing something down

Read the rest of this entry »

Before getting up this morning I reached out for an issue of Wired magazine from the pile under my bed.

I read an article on a training facility for US-soldiers going to Iraq; though totally unrelated to software one thing struck me: While praticing the soldiers uses laser-equipment to simulate bullets. As a drywall or any other non-transparent material block light, the soldiers train themselves to simply hide instead of going for cover.

Association chain: cover - coverage -tests, well here we are.

Back to the picture, as a seasoned CS-player I know the difference from first hand (unlike real soldiers I am still able to talk about it). Software is not far off from a game; if you introduce a bug, you can correct it later (errm not in all cases), well at least if your real-estate site crashes, no one get killed.

With test cases it is sometimes the same, they assure you that everything is OK, you might have 98% coverage and all tests pass. Then after release a bug comes from nowhere and takes the system down. Where do these killers from? While you have perhaps validated each single function in isolation, you will never have any reasonable coverage of all possible scenarios that execute them in sequence.

My favorite bug of this kind could be reproduced in the following minimal scenario:

• Insurance contract live for at minimum 15 years (this implied the 15*12*6 ~ 1000 batch tasks had been applied in the background)
• 3 uncommon alterations made to the contract where the 2nd got canceled and redone in this period

After I found out what went wrong I had the greatest respect for the tester who conceived this test-case, - until he confessed that it came from a standard scenerio where he made two(!) errors as he went through it.

In fact the bug came from design flaw, for the fix I had to rewrite large portions of the sequencer (>400 classes). Irony here: The sequencer had been one of the few components where we had unit test (It was abck in these C++ days where things like JUnit just came out). Design flaws are rarely found by test-cases as the tests follow the design (unit tests) or duplicate the design (scenarios).

As any design element comes down to some code to implement it, one might think that there could be a test for it. Unfortunatly most of these tests are just “drywall”, they assure you that “covered” your code, but they guard you only against “visible” bugs, the paradox is that the design-elements have to take care of themselves because thats what they had been design for in first place.

The paradox continues, the code that manages to hide itself completly seems to be impregnable, mostly because they are protected by a concrete wall of design-elements that protect it from getting unexpected data ( in my case the actual implementations of the commands in the sequencer where all fine).

Morale: Test-drive code where you can do it meaningfully, design carefully code that will be hard to test.

I looked over Martin Fowler’s note on the kinds of code ownership, well don’t expect much from it, but it is a nice definition of terms to be used in discussions.

This morning I read a followup that shed a different light on it.

In the original post social factors had been identified as the driving force, where the followup also mentions the focussing on competence is relevant.

That fits a bit more accuratly into my experiences, while I like to throw in a thrird factor: organizational structure. Collaborative ownership across departments with different goals/deadlines are almost guaranteed to make a mess, especially if there a located in different parts of a building - or even worse - in different countries.

A working social network is an enabler, the presence of know-kow differences and organizational borders are pure disablers.

So if we strive for agility, we have to strengthen the enablers and eliminate the disablers. Though it is possible to overcome most of the obstacles, sometimes it isn’t or it is simply out of your hands. In these situations that are probably the majority of the cases when it comes to large projects and/or big (or those who think they are) organisations, you have to adapt your project to suceed. Read the rest of this entry »

Just finished reading this book, all in all a great read. Especially the first six chapters (when it comes to things like debugging it gets a bit shallow)

Two practices, Feeding Agility - Learn when to Unlearn and Delivering User what they want - Justify Technology Use caught my attention in ther combination.

In short what they are talking about:

Learn when to Unlearn

Every technology has its time - some techniques are not useful anymore or got replaced by something that suits today environments better. This ranges from programming languages (indispensable techniques from C/C++ are questionable in a Java project and perhaps simply idiotic in the realm of a dynamic language) to the interface technology (3270 terminals, GUIs and webacces have different constraints and advantages which you cannot exploit in all the same way).

Justify Technology Use

Here they coined the nice term “résumé driven design”. It denotes the choice of technology that serves primarily the personal interest. In fact this goes even deeper down: Pathological use of patterns leads to same problem. Resources get wasted to attain a goal that has nothing to do with the goals of the project.

Each practice described in the book is rounded up with a section Keeping Your Balance: Real-life is not binary; you have to evaluate in your very situation to which degree it makes sense to apply a practice.

The two practices above with their balancing form a teeter-tatter. You can make it swing by leaning forward-backward on the opposite sides of it - thus destroying the balance. New technology and new techniques are sometimes antipodal to things you already know and use.

This means that you can stay globally in balance if you under- or overdo both practices - although that is not supposed to be 100% healthy. More important though: You always have to keep global balance. When dealing with stuff that’s right out of the oven, you have to question your habits thoroughly to apply them successfully.

The main problem here is that technologies seem to be easier to learn than habits can get changed - I do no claim to be an exception - I observed how hard I struggled with (G|Ruby on)rails; I had to throw some views over board to make progress (the annoying thing was that it eventually turned out to be a déjà vu and I#d to fall bach to techniques I unlearned several years ago).
As my first boss said: If it was easy we wouldn’t be here in first place.