Part of the Process

Photo of Bellagio by me Bit of a parable about chasing silver bullets ... I have been a keen photographer since mid-2008 when I got my first SLR. Since then I have taken tens of thousands of photos, practising my technique and getting used to the tools available - for example natural light, flashes or particular lenses. Most of these photos never see the light of day and get written off as I don't like them for some reason or other, but I can't bring myself to delete them and every now and again go back and look to see what I can salvage. Each time I then fall into the trap of Gear Acquisition Syndrome ! I have been doing that recently and looking at what themes I can find in my photos and how they can be edited to fit in a series - at the same time as pricing up the latest Fuji X-T10. This time there are a couple of photos that have not only gone from the "nah" pile, but are now being shared on the Internet with other people! So, what has changed? ... The...

One hot topic that you often get when you have project teams delivering functionality for user acceptance testing while support are testing ad hoc fixes for production issues is "Who owns the environment and how do we stop support and project work from interfering with each other?". I feel that all code changes and deployments to customer facing sites should have some kind of change management paperwork raised. Because of this you are able to catch scheduling/work conflicts in the change advisory board. A good change control process should help you think about the risk to your project and also help flag to other stakeholders that they might have a risk to consider. A very basic rule of thumb for deploying anything to production in a manually controlled environment is don't expect that no other changes to have been made since you took your base to work on and always check before merging in . Here I think a "manually controlled environment" is somewhere that d...