Rob Smyth
Friday, 18 January 2008
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.
Wednesday, 16 January 2008
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:
So is the product defective at this point? From my 'zero defect development' point of view ... no. It is not defective as:
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.
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
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.
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.
Tuesday, 15 January 2008
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?
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?
Saturday, 5 January 2008
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:
I'm still looking. My notes on readers I'm testing are kept here.
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.
I'm still looking. My notes on readers I'm testing are kept here.
Thursday, 27 December 2007
Bushfire Back Decking Sprays

The photo shows one of the 90deg sprays.
Open Design And Collaboration 'Win Win' $$
Just recently I purchased a Topfield PVR (Personal Video Recorder). One reason I went for a Topfield was the TAPs. TAPs are C++ applications that run on the PVR to do ... well, whatever you like. The thing that makes the TAPs exciting is that Topfield has made the PVR's operating system kinda 'open' so that anybody can write TAPs, and yep the community jumped in a many free innovative TAPs are now available. I can now download TAPs to change PVR skins, display EPGs (Electronic Program Guides), change how the PVR responds to the remote keys, and even change how the box 7 segment display works!
The thing is that the community comes up with more ideas than the original manufacturer could ever do and provides them for free. The manufacturer ends up with a more valuable product due to community support and the community ends up with more choice and functionality due to collaboration.
What a great example of the 'win win' of collaboration and open system design. Hey, it sold me the product.
The thing is that the community comes up with more ideas than the original manufacturer could ever do and provides them for free. The manufacturer ends up with a more valuable product due to community support and the community ends up with more choice and functionality due to collaboration.
What a great example of the 'win win' of collaboration and open system design. Hey, it sold me the product.
Sunday, 23 December 2007
iTunes Could Do With A Bit Of Tuning
Having recently got a new IPod Nano (3rd gen) I've been using iTunes 7.5 software for the first time. The iPod is great, and while the iTunes software is 'adequate' I'm surprised with then number of rough edges it has. I'm disappointed that it does not have the quality I did expect from Apple. Mind you, I still like it and will continue using it.
I'm running Windows XP Pro.
The rough edges I've hit are:
Still, I really like my iPod and find iTunes 'OK', but I no longer think of Apple software as being high quality. A shame.
I'm running Windows XP Pro.
The rough edges I've hit are:
- Register iPod feature does not work
- Rating settings made while ripping are lost
- Column widths are not persisted
- iTunes crashes
- iPod detection can get 'confused'
- Contacts sync from Windows Address Book does not work
- Ratings column changes dodgy
When you first install iTunes it auto starts when the iPod is connected and presents a register iPod page. It just does not work. It seems that everybody is having this problem. The software locks up for a minute or two and then continues without any error message. Next time you will see the same register page. The only solution seems to be to click the 'Never Register' button. Such an obvious fault that hits users on first use and first screen it is hard to understand how Apple let it though.
While transferring a CD to iTunes (Ripping) iTunes plays the tracks automatically. So I figured this would be a good time to listen to them and rate them. I right mouse clicked on the column header area and selected the 'Rating' column. I then set the rating of each track as it was ripped. But when all were done and I went to the 'Music' page I found that my rating settings were lost. Darn.
The default columns widths are less than ideal. If I manually adjust column widths these widths are lost when I return to that page. Rather ordinary for a Windows app.
I cannot explain why but it has locked-up on me a few times now. I guess about every several times I use it. Each time I've had to use task manager to shut it down.
Once when I had iTunes up and then connected my iPod, two iPods appeared in iTunes. iTunes started an auto-sync and after some time reported that my iPod was possibly corrupted. When I pulled the USB cable out both iPod icons disappeared and when I reconnected all was well.
Not a confidence builder.
I have contacts held in Windows Address Book using a local WAB file (not using Outlook). iTunes only imports the first one or two contacts correctly and then misses most others and those others it does import are missing the name, the email address is used in place of the name. I've tried clearing the WAB file and importing all again from a CSV file, which I checked, but the results are the same. Looks fine in the address book but not on the iPod.
The work around is to export each contact separately as a vCard file directly to the iPod's Contacts folder. That works fine but the Windows Address Book software cannot export all contacts at once.
Setting a rating, in the music view, by clicking on the rating column often requires you to move the mouse over another control before it works.
Click on 'Music' in the left pane, then right mouse click on the column headers and select 'Ratings'. The Ratings column is now shown. If you have not set a rating you will see five dots. You can click on one of these five dots to set the rating from one to five. But ... double click the track and then immediately move your mouse over a rating dot (as if you are listening to rate it). Typically I find I can click all I like but the rating is not set until I move my mouse from one dot to another and then back to the one I want. After this move it works immediately.
Still, I really like my iPod and find iTunes 'OK', but I no longer think of Apple software as being high quality. A shame.
Tuesday, 18 December 2007
Importing gmail contacts to my iPod Nano
I've been trying to import my gmail contacts to my iPod Nano and have found that this is not exactly straight forward. It seems that if you are not using Outlook or windows contacts then you need to create a vCard (vcf) file of contacts and copy this manually to the iPod's Contacts folder.
First up I tried exporting the contact to CSV (gmail's only option) and then convert to vCard (vcf) using a CSV to vCard on-line converter here. Worked, but the results were a bit disappointing with a few '&' characters appearing on the iPod. Usable but not as convenient as I would like. I would like to be able to view the edited data is a grid before saving to the iPod.
I found GreySquare Blog which shows how to use the Windows Address Book as an intermediate contacts store. Works well.
In summary:
Other iPod related tools I found while doing this:
First up I tried exporting the contact to CSV (gmail's only option) and then convert to vCard (vcf) using a CSV to vCard on-line converter here. Worked, but the results were a bit disappointing with a few '&' characters appearing on the iPod. Usable but not as convenient as I would like. I would like to be able to view the edited data is a grid before saving to the iPod.
I found GreySquare Blog which shows how to use the Windows Address Book as an intermediate contacts store. Works well.
In summary:
- Export outlook CSV file from gmail.
- Import the CSV file into Windows Address Book.
- Configure ITunes to auto sync contacts from the Windows Address Book.
Other iPod related tools I found while doing this:
Sunday, 2 December 2007
The 'Best' Revison Control Software
One of the teams at work is currently evaluating which revision control software (RCS) product to use as we are moving away for their preferred choice of ClearCase. I've never understood ClearCase and have, in a couple of companies, been perplexed by the strong passion for ClearCase that some teams have had. But, after observing the guys at work evaluating different products the penny has dropped for me on how ClearCase can, truly, be the best RCS software.
There are many revision control tools like subversion (SVN), ClearCase, Perforce, etc, and their functionality varies greatly. No one product that I know of does everything. Interestingly when I worked at a GE company one team used SourceSafe, another used ClearCase, and the other used (I think) Perforce. I've tried to use ClearCase and found that it greatly reduced my productivity. But yet, others insist it is an enabler. How can this be so, we are all software developers, right?
Taking ClearCase as the example here, at my current work we have a team that sees ClearCase as important to their success while others see it as a blocker. I think I can explain this from why I find it a blocker and from what I've learnt as to why this other team sees it as an enabler.
I like to work in an agile fashion and in particular in a eXtreme Programming (XP) style. It suites me, I perform my best this way. So the style that works for me includes the attributes of:
This translates to a process of:
ClearCase is very feature rich. Trouble is that these features make the process above impossible. The features are actually detrimental to this way of working. The fundamental problem is that ClearCase, one way or the other, enforces a level of isolation so that each commit requires multiple steps. The end result is that it takes minutes to do a simple merge and commit with ClearCase. If CI is being used the superior merging capabilities offered by ClearCase's process have no benefit as the merges are always small.
So I find that for an XPish way of working ClearCase's features do not translate to benefits.
The other team, I mentioned at the start, however considers ClearCase's features to be important enablers to their work. I admit that at first I did think that were a 'crazy' but I've come around and recon they are right. After all, they are a successful team so how can they be wrong!
I see them as agile as they are collaborative but their work style is nothing like XP. The style that works for them includes the attributes of:
This translates to a process of:
So, interestingly, SubVersion's (my favourite) features do not translate to benefits for them just like ClearCase didn't for me. For example, SubVersion is fast but they do not really need speed. The big blocker for them is that SubVersion does not currently (scheduled for ver 1.5) record merge history. That is, when a branch is merged to trunk. This is their basic work practice!
So, for them, ClearCase is the best as it matches a work style that works for them.
I really should have known better, people always trump process. People and environments are different so there is no one right way of working.
My spin on this: Now that agile software development is proven and wide spread, Agilists are at risk of now becoming the ones that say 'one size fits all'.
There are many revision control tools like subversion (SVN), ClearCase, Perforce, etc, and their functionality varies greatly. No one product that I know of does everything. Interestingly when I worked at a GE company one team used SourceSafe, another used ClearCase, and the other used (I think) Perforce. I've tried to use ClearCase and found that it greatly reduced my productivity. But yet, others insist it is an enabler. How can this be so, we are all software developers, right?
Taking ClearCase as the example here, at my current work we have a team that sees ClearCase as important to their success while others see it as a blocker. I think I can explain this from why I find it a blocker and from what I've learnt as to why this other team sees it as an enabler.
ClearCase as an blocker
I like to work in an agile fashion and in particular in a eXtreme Programming (XP) style. It suites me, I perform my best this way. So the style that works for me includes the attributes of:
- Continuous Integration (CI)
- Ruthless refactoring
- Teamwork
This translates to a process of:
- Commit code to the repository about every 30 minutes (average on a good day).
- Merge from the repository every 15 minutes (keep up to date with the rest of team's commits).
- Do not work on branches.
ClearCase is very feature rich. Trouble is that these features make the process above impossible. The features are actually detrimental to this way of working. The fundamental problem is that ClearCase, one way or the other, enforces a level of isolation so that each commit requires multiple steps. The end result is that it takes minutes to do a simple merge and commit with ClearCase. If CI is being used the superior merging capabilities offered by ClearCase's process have no benefit as the merges are always small.
So I find that for an XPish way of working ClearCase's features do not translate to benefits.
ClearCase as an enabler
The other team, I mentioned at the start, however considers ClearCase's features to be important enablers to their work. I admit that at first I did think that were a 'crazy' but I've come around and recon they are right. After all, they are a successful team so how can they be wrong!
I see them as agile as they are collaborative but their work style is nothing like XP. The style that works for them includes the attributes of:
- Non-CI. Each developer works in a branch with, what I consider infrequent (but that is qualitative) merging.
- Up front design approach (I think).
- Teamwork.
- Little or no refactoring. (Refactoring is seen as a result of failure as opposed to my style of it being an enabler.)
- Low requirement churn.
This translates to a process of:
- Infrequent commits. I'm guessing an average of once every 2 days.
- Careful merging (essential with infrequent commits).
- Detailed history records of merges to trunk as this is the 'delivery' and work is usually on a branch.
So, interestingly, SubVersion's (my favourite) features do not translate to benefits for them just like ClearCase didn't for me. For example, SubVersion is fast but they do not really need speed. The big blocker for them is that SubVersion does not currently (scheduled for ver 1.5) record merge history. That is, when a branch is merged to trunk. This is their basic work practice!
So, for them, ClearCase is the best as it matches a work style that works for them.
Conclusion
I really should have known better, people always trump process. People and environments are different so there is no one right way of working.
My spin on this: Now that agile software development is proven and wide spread, Agilists are at risk of now becoming the ones that say 'one size fits all'.
Saturday, 1 December 2007
Outdoor Web Cam
I got my first camera installed on the house today but the results are somewhat ordinary. I've posted sample images on my wiki here. The image quality is not good enough for us to view conditions at home. We want to use to see if there is smoke or embers in the area.
I will probably end up getting another camera, but in the meantime it gives me something to use to get the rest of the bushfire fighting system going. Something is better than nothing :-).
I will probably end up getting another camera, but in the meantime it gives me something to use to get the rest of the bushfire fighting system going. Something is better than nothing :-).
Subscribe to:
Posts (Atom)