30.4.09
Yesterday’s scrum
23.4.09
Dinner @ the inn
Yesterday was St. George's day and in celebration of the patron saint of England, I went to the local Inn where they had layed out the very best in English cuisine. This ranged from the curiously named toad in the hole to the delicious Shepherds Pie.
19.4.09
When Paradigms Collide- Sorting Spatial Data using the List Metaphor
Given a spatial dataset that comprises physical locations that must be traversed efficiently, what’s the simplest solution that would accomplish this task?
Trouble booting from CDROM on Sunblade 100.
Possible causes:
- Corrupted media
- Faulty CDROM drive
- Non-bootable media
- SunOS 5.9 limitations booting Ubuntu/Solaris 10
A lean view of scrum
The sources of waste are:
- Third-party delays in providing inputs required for the upcoming sprints
- Stories with insufficient detail to ensure that the team proceeds without interruption
- Scrum is yet to gain traction; the old way of doing things still haunts the project
- Delayed feedback
- Developer distractions – meetings; problems with machines; network connectivity; complex build process
NIH…
When a developer inherits a codebase, there is always a case of NIH(not invented here) syndrome. I am guilty of it, but with experience and professional maturity I have become more objective in my evaluation of third-party codebases. Recently, I had the chance to work on a codebase that ticked all the boxes of what a good software application should contain. The codebase exhibited the following characteristics:
- Unit testing and Mock objects
- Dependency Injection
- IoC Containers
- MVC
- N-tier architecture(and a slight hint of domain driven design)
- Fluent Interfaces
- NANT builds
- Code-generation
- Template meta-programming(generics)
These are fairly advanced concepts in software engineering and represent the software engineering zeitgeist. Unfortunately these practices will be lost on the majority of enterprise developers(unless you are working in a dedicated software shop that’s at the bleeding edge). For the typical enterprise developer, this translates into is software that is harder to maintain, extend and for which the sprint velocity is going to be dismal. The inheritors of the codebase have the additional task of understanding the domain and the engineering approach.
The question then becomes: how do you balance the need to create supple software systems whilst staying true to the software engineering discipline. Can you sacrifice the need for rigour in favour of comprehension and program understanding or vice-versa?
From XP Developer to ScrumMaster
As luck(or misfortune) would have it, I have been tasked with ensuring that the team delivers the right software on time and to the product owners’ satisfaction. My previous forays in extreme programming(XP) mean that there is zero cost of adoption of this new way of working. It could be argued that scrum and XP are polymorphic. They both inherit from the same agile shrub.
It is tempting to approach the scrum master role from a developers’ perspective given that I am a developer to the core. But this misses the essence of being a scrum master. I need to balance the demands of the product owner with those of the development team whilst being aware of the latent political interests that subtly influence the project. Some of these interests have a less than positive impact on the project and are impediments that need to be reported if the project is not to grind to a halt.
Agile is new to the organisation and the idea of product owners, sprint velocity, burn-down, sprints, product backlogs, sprint backlogs is alien in certain quarters. It is not uncommon to be asked to provide an estimate on the spot without consulting the team. My advice is don’t do it and don’t over commit the team.
18.4.09
24.3.09
HPC Windows Project back on track
The next few weeks will see me configure the head node and install the SUN GRID ENGINE tools. Then the slave nodes will be configured and the obligatory benchmarking LINPACK tools will be executed to determine the cluster performance.
We have a release candidate
9.3.09
7.3.09
MVVM a view gone too far?
After spending a week spiking this for a tablet PC application, it quickly dawned on me that the ViewModel, the data specialised for the view is really an adapter pattern. The model is adapted to suit the expectations of the WPF UI. Adapting the model for the view means that you can essentially ignore converters.
//TODO:Add code
“But it’s auto-generated, so why does it need to be unit tested?”
I recently overheard a conversation in which one developer was explaining the legacy code he had inherited to a new starter on the team. The developer described the code generators and the accompanying unit tests for the generated artifacts. Naturally the new developer asked why they needed unit tests if they were automagically making this stuff. This is a valid question and one which does beg a decent answer. I will try to answer the question based on my experience as a test-infected developer.
My response is as follows:
- Auto-generation of software artifacts does not guarantee correctness. This is a garbage-in-garbage-out view of code generation. Engineers need to be sure that the changes that will inevitably occur in the code generation templates do not introduce defects. By running unit tests against the generated code you are testing that the generators works as they should and that specified inputs produce predictable outputs. The unit tests enforce the implied contract which stipulates that my code generator should always produce artifacts that do X.
- Unit tests provide a reliable and repeatable way of regression testing the outputs of the generated artifacts. A change to the code templates might introduce subtle bugs. How else would you be able to detect these in the absence of automated unit testing. You are covering your own hide by having a battery of tests.
- Unit tests allow you to develop with courage. You get immediate feedback when defects are introduced into the codebase (this assumes you are continuously running your tests, which you should).
- The quality of the unit tests also dictates the testing experience. Several heuristics exist for developing good tests.

