220 Downloads later…

A while ago I put together a little library that determines internal rate of return for a series of cash flows. This is a problem in the accounting domain and was prompted by the inadequacy of the features in excel. I did not want to haul the whole of excel into the application I was building. I tend to stay clear of Interop if I can help it.

Well the short of it is that the lib averages 1.5 downloads per day. Not much for 15 mins work, but this has led me into thinking that perhaps there is a larger market for reusable math/scientific libraries. How about a DNA sequencing lib?

Now clean it up…

In our attempt to clean up software engineering and make it a more rigorous profession, I assert that testing is one tool that will ensure that the discipline produces consistent results and repeatable quality. Testing should be at the forefront of a developers’ mind, but in most cases it is an after thought. I suppose this is a reflection on the human condition. We are forever optimists hoping that our artefacts will stand the test of time.

Well I don’t live on hope and for me life is a set of precise constructs. Gravity always wins and code breaks. So lets get test-infected.

Writing a good tests assumes:

• A knowledge of the domain or access to a subject matter expert – can be the product owner
• An adequate tests framework
• A testable architecture

As someone once said, “any one can write a programme, it takes a disciplined developer to write code with tests”.

Balancing the risks of tool switching – a heuristic

When/why should a team adopt/change its toolset?

• If the current toolset is inadequate and results in a loss of productivity
• If the new toolset is a ground-breaking innovation and not merely a derivation and solves the business problem better than the incumbent
• If there are compliance/regulatory constraints that mandate the change – for example Sarbannes-Oxley.
• If the new tools will give you significant competitive advantage in the market place, otherwise the costs of learning/deploying the tools will erode marginal benefits

When should a team not adopt/change its toolset

• Because it will look good or make the developers appear smarter when included on their CVs – remember the customer has to deal with mess once you have left the site

The day we overloaded the scrum with issues that were not part of the “triumvirate”

The context: A distributed team with very minimal inter-personal contact. Most conversations are by electronic means.

The scrum started out with each engineer being asked the usual trio of questions. The expected responses were given and then a tangential conversation about the best approach to take for a new project took root. Big mistake! Before long we had a virtual bun-fight that risked creating permanent schism within the team.

The lesson to learn from this saga is that face-to-face sessions are best when discussing issues bordering on religion. Once a jihad has taken root within the team then delivery of quality software will be impossible because the team is working against itself.  As a facilitator it is tempting to give additional bandwidth to groaners and the loudest shouters, but this has to be weighed against the greater needs of the team to work as a cohesive unit.

We have survived the death march…what’s next

After the intense and somewhat heroic efforts by the team, a retrospective is definitely apropos. The key lessons learnt are:

1. Scrum definitely works when used in a chaordic context. What might appear as the ritualized trio of questions, what did you do yesterday, what do you plan to do today, what are the impediments to progress, focuses the development team on what needs to get done.
2. Working software is the ultimate measure of progress on any software project. If it’s buggy you will have trouble gaining the trust and required acceptance and signoff.
3. Short feedback loops via daily stakeholder meetings help focus the development team on what needs to get done
4. Having a developer who also happens to be a subject matter expert will propel the team further.
5. Don’t change the domain model if it’s not broken. A distinction has to be made between purely technical changes and changing the semantics of the model.
6. Regression issues will undermine the team and erode user confidence
7. Make your tech choices before hand and adhere to them
8. Beware of feature envy - http://c2.com/cgi/wiki/Wiki?FeatureEnvy
9. Keep the testers close and the customers closer
10. Retrospective testing of code is much harder than TDD.