James Simmonds

My hundreth post on this blog. Anyway.... My current project is coming to an end and its been interesting looking back at what has happened on it from a technical perspective. The most interesting thing for me is that I have had to invest some time in thinking how to scale the solution to grow with the demand the business expects to see. I've been following the High Scalability feed for a while but a post led to another blog which has really impressed me - Ricky Ho's "Pragmatic Programming Techniques" . In particular Ricky's recent post really chimed with me as I've struggled recently to try and capture, even formularise why I've make certain design decisions and found there wasn't really anything more than "instinct" that pushed agility into the design in certain areas and away from others. The post is a very good read and great summary of a Kent Beck talk he attended - well worth 10 minutes of your time. I'd have loved to been at tha...

Continuing my "Business Agility" series (I promise to explain what I mean by this!) I wanted to talk about another area of software that is often over looked and lacking information...application performance monitoring. To start with why is performance monitoring important and what has it got to do with "business agility"? As with my previous post on debugging it is the lack of information that directly impacts the ability of the business to improve its software. The lack of performance information is a blind spot as to what is actually happening operationally with your software. Ignorance of a problem doesn’t always equal bliss! In my experience much business software is written without regard for performance. However this is not the sin - the sin in my eyes is that the ability to measure performance is often not thought about at all and if performance does become an issue then it is often too late to put in place a good, consistent monitoring framework. Performan...

Update 10-Jan-2008: I have added a link to a full trace log to one of our service calls to demonstrate the type and quality of information you should be logging... One of the biggest areas for improvement in software development is debugging - or put another way, reducing the time to understand and fix bugs - lets call this Time To Fix (TTF). Reducing TTF has some benefits directly related to "Business Agility"- more bugs can be tackled and fixed in a given period or a set threshold (severity) of bugs can be fixed in a shorter time. Rather nicely the means to improve TTF actually reduces the number of bugs being produced over time - we'll cover how this works later on. Objective Drawing on my "Business Agility through Component Software" concept and from hands on development these past ~three years I have experienced first hand how inefficient bug fixing can be and how enormous time savings can be made with a better approach to designing and implementing your s...

As previously mentioned I want to write about my "Business Agility through Component Software" concept. This encompasses several aspects of software design and crucially includes operational considerations. I'll be writing a series of posts covering all of this...however in true "reuse" style I want to provide a common "set the scene" post to explain the work I have been doing and give context and background to the actual post that will reference it. I work for a Digital Media "supply chain" company. We ingest (take delivery) of media files (WMA,WMV, metadata & images) and perform a number of processing steps on them before eventual delivery to a consumer via a digital retail front end (website, WMP Online Store, gadget etc). This past twelve months I've been involved in re-developing the delivery services on our core retailer platform. These services are used to... Deliver a media file (WMA, WMV) to a PC/Client Generate Windows Media...