Posts Categorized: Development Process

Rapid Prototyping with Henry Charge


Last week Henry Charge led a Lunch and Learn on Rapid Prototyping, the practice of creating HTML prototypes that can be changed on the fly instead of having to create new iterations of photoshop renders when aesthetic changes are requested by the client. Focusing specifically on some of our Government work, he introduced the concept… Read more »

7 principles to enable Agile Projects through Enterprise Architecture

Discovery From Above

Most enterprises will now have experimented with Agile projects. Many projects are a great success and some fail to live up to the limitless hyperbole of Agile. One of observations I have made when working in several enterprises is that the fit between Agile projects and more established Enterprise Architecture function is not fully defined and,… Read more »

EPiServer/Pugpig Connector Development

blog pugpig connector

by Sandeep Narayan Overview I have been working on a piece of software called a “connector” which is used to publish content managed by EPiServer CMS instances to tablet devices and smartphones that run PugPig reader apps. In order for a PugPig reader app to download and display digital content managed by an EPiServer CMS… Read more »

Project Estimates

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 [...]

Approach to Performance Tuning

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: [...]

Technical Debt re-visited

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 [...]

Dangers of executable examples over dry documentation

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.