I had a successful couple of years blogging on delphi.co.za, a domain that I have proudly owned for about fifteen years - but the legacy and branding of 'Delphi' does not fit with what I do and how I think.  Scott Hanselman points out that using a consistent url for your blog is important and somewhere I picked up the tips of avoiding excessive cross-posting and making sure that you don't move your blog around too much.  So I tried to think of a url and blog title that would reflect my views and also be somewhat ageless - a url that contains that latest fad is either going to become stale or the blog will move around a bit.

As with many things, the first idea that comes to mind is often the best - try as I might I could not conceive of something more appropriate than DeliveryFocus.net.  I subscribe to many feeds and consume interesting technical information from people that are very clever and experts in their field - as much as I would like to consider myself a technical expert in some things, most of the professional work that I do revolves around delivery of software.  It is strange that with all the noise that is out on the Internet, very little emphasis is placed on what most people pay us for, namely delivering the required system on time, on budget, at a high enough level of quality - and a few other quality attributes.

Many tools and processes are about delivery - in a roundabout way. Agile and TDD are about delivery, but the message sometimes gets lost in all the fanatical rhetoric.  Some developer cultural wars are less clear - the ORM vs Dataset never-ending argument is a good example - regardless of the technical merits (or Object Oriented bigotry) one way or another there seem to be few considerations as to which approach provides optimum delivery capability given a particular set of circumstances.  Statements that contain "<some technology> is evil" fail to contain references to successful projects where <some technology> was used to get a system out the door quickly, cheaply and easily where the company may have gained a significant timing advantage over their competitors in the market.

My intention is not to write posts that are only statements only focusing on what it takes to deliver, but hopefully the essence of the need for delivery will come through as a common thread.  Why?  Because the work that that I am contracted to do relates to delivering software - I am not an academic who has the mandate to figure out the most efficient algorithm, I am not a rocket guidance developer where defects mean that people die and I am not, unlike many blogs out there, working for a large multinational vendor telling everyone how everyone except you is using the latest technology that I am talking about.  Instead I work in an enviroment surrounded by developers, project managers, users, facilities people, finance, vendors and a whole host of other people and organizations and I am responsible for getting systems into production that are architectural sound, of a good enough level of quality and meet the requirements of whoever is paying.  It sounds a bit far-fetched, but that is actually what most of us are doing.

So, in order to deliver software you broadly need

• A good idea of the needs of your customer/users
• An architecturally sound platform, tools, patterns and approaches
• A team of people that are going to help you to deliver
• An interface for all other hangers-on, project managers, facilities and competitors

... and the above list encompasses a huge chunk of software development - leaving me a lot to write about.

Simon Munro

simon - at - deliveryfocus - dot - net