CFA Incidents RSS Reader

As I've not been able to find any RSS reader suitable for reading the CFA Incidents RSS feed I've started writing my own. To get something going I have first created a simple reader that gives 'no touch updates' (incidents update without need of a manual action) and incident relevance highlighting. Quite pleased with the initial outcomes (see picture).

Now I'm wondering if I can hook it up with google maps .... hmm.

The'In My Experience' Falacy

How often have you heard 'in my experience' in a discussion of what is possible? I know I've said it. What I find surprising is how easily we discard, or block out, each others experience.

I have worked in an agile style (specifically XP) in a company that produces a "shrink wrapped" software product that goes out to a large, growing worldwide customer base and accounts for more than AU$40M of sales each year. So when I'm told "I can see how agile would work in a consulting company but not in a company producing a product going to many customers" and I point out that 'in my experience' I have worked successfully in an XP team in just such a company, my experience seem to be ignored. More to the point it seems like I never said anything. I'm not considered a liar but it is just like my experiences did not exist. In one company I had one person who came back with this same comment several times and seemed each time to have no knowledge of 'my experience'. It seems to me that if one person's experience so outside of our own, or threatens what we what to believe, then we may block it.

When we cannot respect each other experience we are limiting our own potential experiences. But perhaps that is the point of the protective blind spot? I'm think of next time dropping the 'in my experience' for some other less confrontation approach.

P.S. I'm not suggesting that an agile approach suites all, it just suites me and is used here as an example.

Ask Not What You Need To Code, But What The Code Needs Of You

A repeating theme at work recently has been developer's with rising skills having difficulty working out 'where to put the code'. What I've noticed is they are trying hard (perhaps too hard I think) to 'understand the design to know where to put the code'. Often this becomes an inhibitor, kinda like not being able to see the forest for the trees :-).

It seems to me that this is a case of believing that a developer's work is to know where to put the code. This is being really hard on yourself, it means you recon you need to be omnipotent, to add functionality you must know all. Kind of a god of the code approach.

Alternatively ask not what you need to code but what the code needs of you. Understand what functionality (not code) is required and then where this type of functionality is handled (belong) in the code. I like to put this as 'who cares?'. Then it no longer becomes a big problem of god like knowledge, but adding code to single identifiable point, hopefully a new class.

Life was supposed to be simple ... right?

CFA Incidents RSS Feed - Finding A Suitable Reader

In the last few days the CFA have fixed their incidents RSS feed so I've been retesting RSS readers and updated my results on my wiki here.

Zero Defect Software Development - A Positive Mind Model?

If you are in a team that practices zero defect development then I'm sure you are familiar with the discussions that zero defect development is not possible, idealistic, or 'we are special' so it does not suit us. While not proposing that it is for everyone or any situation I've been perplexed as to why it is still considered 'impossible' when I'm in a team doing just that, I've working in another company in a team that has done it, and I'm aware that there are many other teams doing it.

Today I was involved in such a discussion with a person from another team. It was a good discussion between intelligent experienced people who each could put a good case for their position. In reflection some time later it occurs to me that the issue is that we hold different mind models of processes, mostly based on experiences, that in particular give very different meaning to what is a 'defect'. The difference is not on severity or priority but on a fundamental definition that is consistent in each mind model (view) but completely different.

When I talk about zero defect development my 'defects' are just as real but are very different to defects in a non-zero defect team. Take for example my work today (which I have mangled for commercial confidence reasons) ...

This week our team's customer asked us to implement a feature to read and write some very basic configuration data to a network device. This was our first story to talk to such a device so it did require us to create the structure used to communicate to devices over a network. So as to reduce the scope (get the story size down to a nice small chunk of commercial value) we asked the customer if we could, in this story, assume that the device is powered and available before we connect to it and there is no communication fault during the transactions. This eliminates all the error handling like:

• Cannot connect
• Not responding
  
• Returned error codes like invalid command etc

The story still has useful commercial value as the software can be used if the user is careful. It helps the team deliver value in short increments as it can skip (for now) error handling including UI, logging, timeouts, etc. The product is 'usable' albiet if released would probably incur support costs and may lead to poor reputation.

So is the product defective at this point? From my 'zero defect development' point of view ... no. It is not defective as:

• It has given the customer what he asked
• It has, due to collaboration, given the customer what he expected.
• It can be used, that is, we have added commercial value.

Yes it does not do what I would like it to do but it is complete useful functionality within an agreed story. The error handling is a future feature that will add commercial value by making the product more usable. So the 'traditional' defect definition of something that does not do what I would like is not valid here. We could release it this way (e.g. for concept demo, or to a partner customer) but we would rather not.

The import issue to me is that I feel good. I get a positive feedback working this way as my customer is happy, the work added is visible and the missing functionality is also visible and manageable as another story. Nothing is hidden, the process is positive.

If on the other hand we discovered that a previously implemented feature is now broken then we can still easily maintain zero defect by removing the feature. This may mean a zero or negative velocity but it is keeping true working functionality visible, developers are not accepting low quality, and the project visibility (and hence predictability) is high.

What I perceive as the 'traditional' approach is less collaborative. It asks developers to just do everything in one hit and anything missed is logged as a defect. This gives negative feedback. It is setting up developers for failure and by maintaining a defect list is communicating that 'defects are normal, managed, and acceptable'. It is very hard to get predictable development as defects are wild cards. It is hard to realise the benefits of higher quality development (avoid the defects in the first place) as the process is giving negative feedback.

So in zero defect development development is possible by agreeing to reduced scope in advance and making what is missing more visible. Less surprises, smaller positive steps. In other words zero defect development is possible by avoiding the risk of failure in the first place. It is collaborating to win.

When Designing, Patterns Are Music To Our Ears

One member in our software team at work is a musician in a local band, and there was a discussion on 'how do you learn songs'. He explained that he only has to listen to a song a few time to get 'the groove'. When asked what 'the groove' was he explained that each song has a structure, at the highest level song and chorus. In the details there are segment with guitar patterns. He explained that he recognises guitar techniques so it all makes sense and he can perform the song, on guitar, as he knows the pattern of these recognisable sub-patterns (my words).

The discussion went on with other team members, with me listening, on how this was similar to software patterns both those we know as 'patterns' and general lower level patterns. We reflected on how when we come to code some functionality we do not need to thing of all the lines, the details, as we can thing of 'yea we iterate through the collection and do XYZ on 'em'. We recognise this pattern and when we need to type we do a 'foreach' etc.. The end result is we can discuss design at a higher level without then need of the 'then we do a foreach, and then ....'.

It made me think of (many years ago) when I was practising Morse Code for my Amateur radio licence (ham radio). We had two levels of licenses, a 'Novice License' and a 'Full Call'. The Novice license exam included morse at a rather slow rate (from memory: 6 words per minute), and the Full Call exam includes morse at (from memory) 16 words per minutes. The interesting thing is that the faster test was easier because with the slow machine generated morse you needed to actually hear the number of dots and dashes while with the faster morse you could hear the 'song'. For example 'dot dot dot dot' sounds like 'diddledee'. You do not listen for dots and dashes but listen for sound patterns.

So learning a song is helped by the expertise of learned patterns. Same for morse and software design. As another team member said today 'Not surprising given the brain's pattern recognition ability'.

So is a corner stone of training patterns small and great?

CFA Incidents RSS Feed - Is There A Suitable Reader?

During summer I like to keep track of CFA incidents, especially on high fire danger days. This is part of our bushfire plan and a couple of years ago I wrote a simple a web scraper to notify me at work of any brushfires in our area. In the last week I've noticed that the Current Incidents page has an RSS feed. Great!

But then I started the search for a suitable RSS reader. This application is a little different from most RSS applications in that it is real time, we need notification within minutes, and only a portion of the incidents are of interest. The feed, and the web page, list incidents for all of Victoria. So for it to be of any real use I need a feed filtered at least by out local region. Incidents hundreds of kilometres away will flood any alarm system I may use.

So what I think I need is a reader that will:

• Check for updates every 1 or 2 minutes.
• Filter incidents by region, town, and type.
• Email filtered incidents.

Thing is I have not been able to find any service or software that can do this. Most readers can filter but only do this as a manual keyword search and often are unable to handle text like "Region: 13". The colon is a killer. The filtering services seem to only check for changes every 10 minutes or slower.

I'm still looking. My notes on readers I'm testing are kept here.