Me-too brochureware banking.

The sad thing is that the more business which use such “me too” approaches, the more others also copy. This may be through laziness, cheapness, or a sense that this is somehow the best way. In fact, I feel a compulsion to go and re-layout some of my own websites into this pattern …

It’s taken so long that I’m not quite sure what to do now. Perhaps some completely different study; perhaps look into the possibilities for a PhD; perhaps no study at all (!).

A recent article from Mark Needham presents an interesting view on how to construct code within tests, and the impact that might have on how tests drive design of code.

In the 14th comment to the original article, JJ calls for a real-world example – this is a good idea which should help ground the discussion and diffuse the temptation to communicate in abstract principles. In the spirit of this request, I will describe an example based on problems I faced in a previous job.

The first version of the system we were working on consisted of a server component, coded in Java, which provided remote services to several client systems. Each of the client systems was a Java web application, responsible for providing customer-specific web pages and navigation using the services and content provided by the central server. For some customers there would be just one instance of the web client, for others with greater load there would be several.

The server system was responsible for managing products for sale, including descriptions in multiple languages, format and compatibility meta-data, thumbnail images in several sizes, prices in multiple currencies. As well as access to individual items and collections, a search facility provided a way to discover or look up products. The server also managed customer details and purchase histories, and handled both delivery of content and general messaging (by email and SMS) during the purchase process. The client systems were responsible for display and navigation of a product catalogue, customer branding, “shopping cart”, login/logout, and everything else a user experiences.

The API between client and server included ways to list products by category, fetch details of specific products, search using a variety of criteria, make and cancel purchases, fetch and update user data and so on.

I suggest this should be a reasonable system on which to base a discussion – it embodies similar concepts to many other systems, and is neither trivial nor impossible to build. Interestingly, both SOAP and REST versions of the interface between the clients and the server were implemented at different points in the life of the product.

So, on to versioning. It seems to me that there are several kinds of changes which might require versioning. I will list a few here, but I welcome suggestions for others I might have missed.

• The first deployment of the system worked with only a single currency. The move to multiple currencies was a potentially major change in the interaction between client and server, even though each client works only in a single currency.
• The customer for one client implementation required the provision of extra services, specific to their market, which were not required by (and should not be available to) other clients.
• The initial version of the search facility returned data for all matches, with paging through the results implemented entirely on the client. When there was a lot of data in the catalogue this became an unacceptable performance bottleneck, especially as results beyond the first few pages were hardly ever viewed. An alternative approach was suggested where a client would request a specified page (of a specified page size) from the search results. This required changes in both the search request and search results.
• A new source of products introduced the idea of collections. Items in a collection could be purchased individually or as a bundle. Viewing a collection while browsing, searching, or in a user’s purchase history, should allow a user to “drill in” to the collection to view the items within it. Items located while searching should indicate how to purchase the collection, as well as how to purchase the individual item.

Is this a useful amount of detail for a scenario? I have my own experiences of working with this system and the choices we made, but I’d love to read any suggestions for how you might handle any of the transitions above in a live system with multiple client systems deployed, many of which can not be changed easily or often, and a server full of historical purchase data. Procedural remoting approaches (SOAP, XML-RPC and Java RMI etc.) and resource-based approaches (REST) are all welcome.

First I watched an inspiring session from TechCrunch Nordic which likens achieving an “exit” for a startup company to dating. Fun, and with a strand of truth.

TechCrunch Nordic – Tommy Ahlers from Mike Butcher on Vimeo.

Anyone running a startup, or thinking about it, should watch this one.

Second I watched a presentation ostensibly about Kanban and “single piece flow”, but really about much wider issues in planning and managing software development. I found the approach presented particularly interesting as it correlates very well with where my thoughts are at right now.

This video is best watched at infoq, to see both the presenters and the slides

Anyone working in software development, or managing a software project really needs to watch this one.

I read with interest that James Carr sought out someone to pair with and found it a useful and enjoyable experience. ( James Carr » Blog Archive » Feels GREAT to Pair Again. ) It occurred to me that perhaps this is what I need, and by implication, perhaps this is what you might benefit from, too.

So I have an open offer. If you like the idea of spending some evening or weekend time pairing with me, please get in touch. Obviously I’d like to make some progress on some of my own projects, but I’m also very happy to spend time on your projects, too.

There’s a fighting chance that the commitment of an appointment with someone else might get both of us motivated and productive, and that we both might learn some good stuff along the way.

What can we work out together?

Freja – CSScripting.

My personal preference would probably be for models in JSON rather than XML and a view template language a bit more developer friendly than XSLT, but this seems a good implementation nonetheless.

What Every Developer Should Know About URLs.

Using DropBox to backup instead of sync

The recent launch of Ubuntu One has added another cloud data service with a generous free storage limit. Although the client software only runs on Linux at the moment I’m fully expecting Windows and MaxOSX clients to appear soon. The same tricks described in the Dropbox article could just as likely be used with Ubuntu One.