The cost of bug fixing
The following graph is why I think the cost of additional design reviews and additional testing during implementation (e.g, unit testing and code reviews) is justified, because it is still far cheaper than fixing the issues later during testing or after product release (maintenance).
Source data from IBM Research.
Red herrings in Uni-Code
Something that bit me recently at work, beware visual red herrings!
I just spent a fair while trying to figure out why Unicode character Í (0x00CD, upper case i with acute) wasn’t loading and appearing correctly in an application, only to discover two days later after pulling all the associated systems apart trying to find the bug, that it wasn’t a bug: we’d identified the wrong character! The character we’d actually been getting was ĺ (0x013A, lower case L with acute) which looks very close to what we thought the character we were getting Í, note the font used in this blog makes the differences allot more obvious.
We’d identified the problem character from the source document which was an excel spreadsheet so we had no way (that we knew of) to check the actual Unicode value of the character. This meant the programmer initially investigating the bug manually identified the character in question by going through the Windows Character Map application (Start->My Programs->Accessories->System Tools->Character Map, iirc) until he found a character that looked like the one he thought he was seeing in excel and as 0x00CD is lower than 0x13A the first character he encountered that looked the same was 0x00CD not the correct 0x013A. So the unicode value was never verified in the debugger…
The moral of the story? Verify the identity & specifics of the problem in your application before you start pulling stable libraries to pieces looking for a problem that isn’t there. Be especially weary if suddenly just one block of data out of tens of thousands start exhibiting incorrect behavior, as that suggests an error with that block rather than the library, as I’d expect more than one occurrence in an library that is handling tens of thousands of strings.
Instead it took me too long to get round to the tedious chore of syncing up to the application code base, building it and deploying it so I could test in the application before I discovered this error. Although it has to be said I was avoiding debugging the application itself as it takes at least a day of watching text scroll by in syncs and builds before you can start debugging, which is tedious at best.
We have resolved the issue now but its a good example I think of a red herring.
The circle of (development) life
The phases of software development: with the traditional waterfall model of development you would go round once per product release, Agile changes this model so that instead of going round once per release, a full rotation is performed every sprint in that project with (ideally) a working product being delivered every rotation.
Project Inertia
The beginning of a project or piece of work has always been one of the hardest times, I’ve found. The actual act of going from nothing to something is deceptively difficult and it doesn’t seem to matter if the project in question is an essay for university, a program to write, a DIY project or some art/craft piece. I always seem to hit a point early on where I’ve researched the topic, gathered the initial materials and am effectively ready to start but I don’t.
I remember noticing this at university when I always wanted to start work on a project early, however I found I would only actually start work once the time pressure of a deadline became large enough to spur me into action.
I think there are several reasons why actually starting work on something is hard:
- Degradation: Prior to starting work on something, the gathered materials are organised and pristine, it can be hard then to actually start working with these materials, especially if you are a beginner or novice in this type of project as you are aware that there is a high likelihood that the finished product will not be to the same quality as the materials that went into it e.g. it is possible to draw a stick man with the finest oil paints on a high quality canvas.
- Commitment: Starting work on something can be seen as a semi public statement that you are about to attempt to actually do something instead of just talking about doing it e.g. once you’ve got paint on the canvas your going to be asked what/how/who you’re painting.
- Measurment: Actually working on something opens up you and your work to potential observation and criticism by peers which can be intimidating e.g. how well you can actually perform can now actually be measured based on the evidence from your project instead of just how well you claim to be able to do it.
In fact, the reasoning behind the content of my first post on this blog was an attempt to start this blog with both a high quality and relevant post on project inertia, as I have been meaning to start writing for over three months now but had not gotten started. However as Newton observed once something is going it is easier for it to continue rather than stop (and vice versa).
I just hope I can build and maintain sufficient momentum to keep this going.
