IF A TREE FALLS IN A FOREST AND NO ONE HEARS IT, DOES IT MAKE A SOUND?
I was wondering if 19th century philosopher George Berkeley would mind if I applied this riddle to software development. What if we change the riddle to:
IF A SOFTWARE DEVELOPER DEVELOPS SOFTWARE AND NO ONE INSTALLS IT, DOES IT DO ANYTHING?
I say it doesn’t do anything. Software that no one uses is not really software. Most of the developers that I have worked with are great developers. Working their magic, solving complex business functions with elegant code. Ok, most developers are terrible at planning, and worse at estimating. They moan and groan about the size of their cubicle, writing comments and documentation, how stupid their manager is, and the fact that occasionally they have to go out in the sunlight.
Most developers don’t claim to know anything about software delivery or configuration management. They want to write code, and have the executables just magically find their way to the right server by reading the mind of the developer. I have yet to see this approach work. I don’t know of any clients that find this approach acceptable.
So how should we solve this dilemma? Following four steps:
- Build – use an automated build process that pulls the code from a source code management system. While this seems straight foward, you’d be surprised how often this is not done. Most of the time, the justification is time, but more time ends up being spent in the long run. Pulling directly from the source code management system ensures all source code gets checked into the library. Build your release notes and implementation instructions ahead of time, and take great care in writing them. This is the first impression of the quality of your work. If the installation doesn’t go well, you will use up some of your good will.
- Install – run an automated installation process in an environment used for staging or integration. Test the installation instructions, acting as though you are installing your software for the first time. At the start of the process, develop two installation processes. The first should be a full install, usually into a clean environment. This is used early in the development life cycle and allows for structural and foundational changes to be applied. The other process that should be utilized is an upgrade process which will be utilized to deploy patches and small functional enhancements. An upgrade process will be used once the software is migrated to production.
- Test – Why test in a staging or an integration evironment? As I re-read that last sentence, my first thought was “Duh!” Most developers believe that since the installation process ran, we are good to go. Just because it ran doesn’t mean it installed the right components, or that the system is configured correctly. This is an open book test. Test your stuff to make sure it works.
- Install – If your software passed through the last previous three steps, then you are ready to take the software to the client. Don’t just let them download the installation instructions and processes. Go on site and observe the installation process. You will learn more in one day than you will in a week back in the office.
Ok, so this is a long blog entry, but this topic has been bugging me for years. It seems like a fairly straight foward concept, but it seems to get forgotten quite a bit.