Built to Last...

Why do we have "best practices"? Why do we have design patterns, unit testing, code reviews and documentation?[1] It is not just about making sure the product we are building actually works, it is about building something that can be maintained, expanded, reworked and reused. We want to know that when a consultant hands over their work and leaves, that someone else can pick it up and carry on. In short, we want things that are Built to Last.

The philosophy behind Built to Last is to create well-designed, well-implemented, well-tested and well-documented software that is able to stand the test of time.

Here I describe my various areas of expertise as well on my thoughts how to execute them successfully.

Software Engineering

I have always considered myself to be a Software Engineer rather than, say, a developer or programmer. Calling myself an engineer reminds me that I should always apply the principals of good engineering to what I do. Among the qualities people look for in a developer is the ability to write software that is well designed, maintainable (i.e. easy to understand), tested and documented.

Software Design and Architecture

The real trick to designing software is to create an archtiecture that meets the current needs of client, goes some way to anticipating the future needs of the client, and therefore is flexible. These needs depend very much on the nature of the client's business. I have met clients that have a fast-moving business model where it is difficult to predict what the future requirements might be and where the archtecture has to adapt to the fact it could easily be thrown away as the needs of the busines change. In other projects I have been delighted during the second iteration by rediscovering the extension points I added in the first iteration anticipating th next set of requirements.

Application Lifecycle Management

Improving the development / release process has been a passion of mine for many years. While it's rare to find a company not using some form of source control these days, often the processes for managing builds and releases are inadequate or simply not there. I describe ALM as a my work "hobby". It is rarely sometihng I am engaged specifically to do, but I take the opportunity to bring in process improvements when needed.

Agile / Scrum

Agile development has really tkaen off in the past couple of years and now almost every conslutant developer is expected to be familiar with at least of the variations of the Agile Method. Many of my recent projects have been Scrum-based and the interesting thing is seeing how different companies interpret this methodology and which parts are seen as the most important. In some organisations, sprint planning, poker decks and story points play a big roel, in others, it's been straight to hard estimates. At other clients, the role of the product owner has been diminished with the Scrum Master and developers choosing what goes into a sprint. This works best on smaller projects with a fix scope. I have found that the most succesful implementations of Agile / Scrum have been one the ones that allow for pragmatism and flexibility in their approach. Not every sprint will result in a showcase, for example.

Continuous Integration

I have worked with many CI servers, notably Team Foundation Server, Jenkins, Atlassian Bamboo and Cruise Control.NET.