I came across this site which has a lot of great information: 97 Things Every Software Architect should know.  I particularly like this quote from Michael Nygard’s advice in Skyscrapers aren’t scalable:

We often hear software engineering compared to building skyscrapers, dams, or roads. It’s true in some important aspects.  The hardest part of civil engineering isn’t designing a building that will stand up once it is finished, but figuring out the construction process.

Lots of great stuff for software engineers in general.

Whether it’s known as off piste testing or explorative testing, there seems to be some value in tests that weren’t originally planned but suddenly come to mind. My question is: Should they have been planned in the first place?

I can understand straying off the path slightly when a defect is found and you go on the hunt for bug clusters. I can also appreciate that a person’s understanding of the system under test can grow as they use the code and so might discover additional areas that warrant testing. However, in this case I believe you should resort back to some formal test planning to ensure that an appropriate job is done of testing that area.

So what does that leave for off piste testing?

Obviously this assumes that you’ve done some formal test planning up front. I know this isn’t the case for everybody so I guess I can ask an alternative question int that case: If all your testing is done off piste (i.e. unplanned) then are you comfortable that all risk areas are being covered?

I think my preference would be to have a mixture of both, however I still can’t shake the feeling that off piste testing is simply areas that we’d forgotten to test!

Our blog has now been running for just over a year and I thought it was about time for a bit of reflection.
The chart above, brought to you by the power of Google analytics show our first year stats (visits per month). After a good start in the year our enthusiasm waned and you can clearly see our readership dropping off between april and September.

Fortunately our change of strategy later in the year seems to have built up the interest again.

I am now mere moments away from finally switching off my windows box and making the iMac our primary home machine.

The last hurdle was cleared this week when I found a replacement accounting package for the family treasurer to use and replace the copy of Quicken 2002 we have been running for many years on the PC.

The reason I took so long in finding a proper replacement was that I’d failed to listen to my stakeholder (my wife, Liz) on what her actually requirements were for the new package. I had investigated all sorts of shinny new software, from the free GNUCASH (that took me half a day to build) through to some fancy stuff from Igg Software called iBank. Everything I looked at seemed to do the the job (at least the trial versions allowed me to import the data) and looked good.

However, each time I ran the stakeholder demo I got the response ‘its too complicated’, or ‘I don’t want to learn a new package’, ‘I just want it to look and work like the old Quicken’.

Now Quicken isn’t the most fantastic piece of software, but it does a job, Liz knows how to use it and we’ve got several years worth of transactions in it. Its satisfied my stakeholder’s needs. So here I was trying to find something wizzy and new, when all Liz actually wanted was to have Quicken run on the iMac.

Unfortunately there isn’t a Mac version of Quicken (there was one, but they stopped it in the UK a while back and they’re promising one later this year), but in my searches I stumbled across an offering from Codeweaver called CrossOver Mac that claims it allows Windows programs (albeit a specially selected list) to run on a Mac. So last weekend I downloaded the trial version, installed Quicken 2002 and rebuilt all my transactions using a backup file and hey presto! we were in business.

After running the Mac and PC in parallel for a few days my stakeholder made the call to make the switch permanently. So we are now fully Mac’ed’ and I have a delighted treasurer.

Lesson learned, listen to what your stakeholder really wants, don’t assume you know better. Sometimes the simplest solutions are the best.

Now the only thing I have to crack is convincing my eldest that the Mac’s parental control really is a good thing!

It’s not every day that someone takes something that you’ve worked on, gives it a bit of a polish, hands it back to you, and then you go “Wow look at that cool technology!”

Today that happened to me. I was pointed towards a YouTube channel called CICSFluff (interesting name there!). There’s three flashy videos that some professional media company must have created:

CICS Events and WebSphere Business Events providing Insight in to Action

New Face CICS – The CICS Explorer

CICS and WAS Working in Harmony

I promise you this isn’t me marketing a product! I’m just amazed at the magic that can be created with a bit of paint and a voice over

Where I was at: I quickly needed to expose some information. So using my laptop I created some Project Zero services written in Groovy that exposed the information via JSON and some pretty charts. My laptop is constantly in and out of its docking station. So in order to make the information available I cloned the Project Zero setup on a server and scp’d the changes across whenever I made local updates. All was fine.

Where I got to: A colleague then needed to create some additional services based on some of the work I had already done. So they cloned the Project Zero setup to their laptop and scp’d across any changes they made to the server. So as you can imagine, at this point we got into the position where we were occassionally overwriting each others updates on the server image. We needed change management.

Where I’m at today: I brought in Rational Team Concert (RTC) to act as a source code repository and change management environment for the Project Zero code. Into RTC I installed the codehaus Groovy plugin for Eclipse to provide me with Groovy syntax highlighting. A quick ant script later and I was able to deploy all the changes to the server on demand. Not stopping there, I decided that I was also fed up of breaking existing services when I was hacking away at the code. So with RTC being built on Eclipse I knew that JUnit came bundled by default. So, with a quick implementation of HTTP requests using the HttpURLConnection class (which is also bundled with Java) I then had a nice JUnit test suite to (literally) give me the green light before I check any changes in. Not only this, but my colleague then synchronized the changes into their RTC client where it picked up the JUnit tests and was able to run them on their laptop.

Project Zero, Groovy, Rational Team Concert & JUnit – what a combination. (and it puts me in a great position for TDD also!)

Where I’m at tonight: At a bar in Edinburgh, warming up for the big game on Sunday. Come on the reds!!!

Pickled onions and snow – not something you would usually put together (maybe for a snowman’s eyes?)
But all week, following the ‘worst snow storms for 20 years in the south of England’, I’ve been thinking about Rich’s post about Christmas (Did you remember the pickled onions?).

Every time I turn on the radio I hear someone complaining at the how unprepared we are for the few inches of snow that started falling Sunday night. Apparently in the olden days buses never stopped, schools never closed and snow was cleared within minutes of it falling, and in Canada and Scotland they have 27 words for snow and no one has ever slipped up or missed a train.

Now I know its a pain not being able to travel and so on, but what are the alternatives? Should we have disused warehouses along the south coast converted into networks of snow plough storage areas? Should we turn the Isle of Wight into a massive salt mountain? If it snows like this in another 20 years then we will be well prepared, but is it worth having fleets of snow ploughs sat idle in the interim? and how will the islanders feel?

I think it all comes back to risk and how poor people are about understanding what it means. People say they understand what it means to take a risk, but they mostly don’t like the consequences when a risk goes the wrong way.

For the last 20 years councils across the south have taken a risk that we won’t get a prolonged period of snow. For 19 of those years the risk has paid off and we, as tax payers, have saved a fortune. This year the gamble didn’t pay off and we are very quick to point blame at those dastardly politicians who made the wrong risk call.

Testers are all too familiar with this situation. Risk is great until it all goes wrong. Maybe the real problem is that the councils who are taking the risk aren’t publicizing it well enough? Its certainly something we don’t do well in test.

Anyway, I look forward to pictures in the local papers 15 years hence of unused snow ploughs gently rusting in the salty breeze coming in over the solent…..

I’ve been writing a hand-on lab for the upcoming Share.org conference and need to supply a source code repository for use in the lab. After a little pondering, the following neat solution came to me:

1. Boot ubuntu on a laptop using a live-distro CD
2. Insert a memory stick containing an install script, a cvspserver file and the source to be added to the repository
3. Run the install script to dynamically install and configure CVS and check-in the source code
4. Run ifconfig to get the IP address of the laptop and supply this to the lab attendees along with the CVS connection details

The install script (install.sh) contains commands extracted from this page and executes them in turn.

It looks like this:

sudo apt-get install cvs
sudo apt-get install xinetd
sudo cvs -d /var/lib/cvs init
sudo cp cvspserver /etc/xinetd.d/cvspserver
sudo /etc/init.d/xinetd restart
sudo chmod -R a+rw /var/lib/cvs
cd project
cvs -d :pserver:ubuntu@localhost:/var/lib/cvs import -m “Importing my project to CVS repository” . new_project start

I now have a fully configured CVS server that can be disposed of at the end of the lab.

Every time we add a new configuration option, switch or dial to our software, I get a little edgy.  I work on a very small and outwardly simple software component, which has grown over the years, as more and more people have come to use it.  Without fail, every time someone new tries to use the software, or someone tries to use it for a different project than before, they ask for a new option to be added – “it would be great if it could just do XYZ”.  Every single one of these requests is completely reasonable, and would ostensibly make the software better.  Combine all of them, and you have a usability and (perhaps more importantly) a testability problem – every dial and switch that we add means a new combination of things to test.  What you can end up with is a slightly larger, and outwardly quite complicated piece of software.

This is a problem that plagues software, and there’s no good answer – when you get a customer who says “I need feature X before I buy”, then of course you want to add that feature – it’s just that eventually, you can end up with a mess.  Apple is a company that I think does well to resist this temptation, but probably reduces its potential market share as a result – that’s a tough one to call.

Interesting reading (see the section entitled “The Question of Preferences”): http://ometer.com/free-software-ui.html