Reasons why Windows 8 is here to stay and what that means for businesses

A few months ago an article was published in Computer Weekly where corporate IT Lawyer Alistair Maughan, argues the case that Agile will not work in Government projects.  I didn’t see this article when it was first published, but it was brought to my attention when a colleague noticed that one of the comments arguing [...]

In my previous post on High Level Project Estimates, I talked about 3 points estimates to help provide an up-front estime of effort for a project. Aside from the effort estimate you also need to consider other aspects that the team will spend time on. The following are some aspects I consider with the kind [...]

What is the best way to review a backlog? How do you ensure that it is “complete”? How do you ensure that the prioritisation reflects the business vision and goals? When first faced with a backlog, you are often overwhelmed by the long list of userstories. The most important step is to set a context [...]

Performance issues in a application manifest as bottlenecks in one or more of the following 4 layers: Application: Application is not designed, developed or configured properly. Platform: The platform that the application runs under (e.g. App Servers, Databases etc.) is not setup and configure. System: The hardware the platform runs on is not sufficient. Network: [...]

There has been some renewed discussion recently on the subject of technical debt, this has been played out on twitter as well as a variety of blog posts including this one.
The technical debt metaphor is one I use often and I believe that there is some clarification required around this subject.
At it’s broadest, technical debt [...]

My team is responsible for several web service APIs that are used by external parties. The standard pattern for educating users about these interfaces was to provide an API document which listed the calls possibly with the occasional example. I have always found this approach to be less than useful and not particularly accessible.

I prefer an approach where the API specification is very much example based. This is makes more sense for RESTful web services than a programmatic API as there is no accepted mechanism for declaring such an interface. The same is not true if you are declaring, for example, a Java interface.

We supplement the document with JMeter projects pointed at a reference system which allow these interfaces to be exercised by the consumer and provides a step by step demonstration.

This has been an excellent mechanism which has resulted in very quick uptake of our interfaces but yesterday I was provided with an example of a potential pitfall:

We provided an API which upgraded widgets. Version was supplied with the manifest of the software package being supplied and was used again in the query string to the upgrade service. The reference data supplied by the system put the current version into a title metadata field so that testers could easily see that the upgrade had been formed. The version in the title matched exactly the title in the manifest.

Weeks after delivery and demonstration it stopped working. Why? The client was using the title rather than the metadata it was supposed to. Since we had used the same value for both the end to end use case appeared to work. As soon as they started using real data where the title was no longer equal to the version everything broke.

A valuable lesson here for me to relearn (I have hit it before in similar contexts). Always make sure reference and test data attributes are not interchangable with each other without an error occurring (and being detected). I should have made the title attribute ‘The version of this widget is <x>’. That would have steered the client developer away from error and would have caused a validation error then first time he tried to submit it to our application.