|
When the build fails - the Business of Software Development |
|
|
|
|
Wednesday, 20 December 2006 |
Fixing a broken release management process is a very challenging task that can take significant resources in terms of human effort, cost expenditures and significant organizational change in order to implement the required development processes. However, ignoring release management problems can be a very costly mistake that can adversely impact the business in many ways. The business of software development requires smart choices, skilled process engineering and technical expertise. Mostly it requires a good business approach. Read on if you really want to be a success in improving your build and release processes.
There have been many times in my career, when I have been asked to tackle fixing a seriously broken release management process. The most common symptom is that the development team cannot reliably rebuild a particular release in production or they spin their wheels for days trying to get a release into QA. It is at these times that I realized that many of the senior software developers had technical skills, in many ways, far beyond my own. But the one thing that these very capable professionals could not accomplish was putting out repeatable builds. The net effect was disastrous for the company. I have seen projects fail and careers derailed, in part, because the team could not get a release out the door in a reliable and repeatable fashion.
Looking at both sides of the problem
In my work, I usually wear two separate hats at the very same time. I am the process guru (with a background in Industrial Psychology) and a technology guy, who is generally most happy when I get to build Unix machines. I crave diving deep into the technical details and one reason that I love being a buildmeister is that I get to understand how the whole system hangs together. Often I get to assemble all of the parts, personally see the new release come up and I usually even get to do a little "smoke testing" - what fun!. But the reason that I get called to be on the team is that something is going terribly wrong.
Process Engineering
I have spent a lot of time, in my career, learning the process models (e.g. CMM/ISO 9000 and more recently Agile). This is very important because people expect me to come up with processes to fix anything at all that goes wrong. The big challenge that I face is always being practical and business focused. Adding too many process steps can cripple a development team and adversely impact the business of software development. On the other hand being able to get error free releases out the door quickly is essential - that is if you want to stay in business. The solution is "Just in time process improvement." We need to have just enough process to get the job done in a reliable and repeatable way. Remember a process must specify the tasks to be completed, roles and responsibilities and a set of tests to confirm compliance (see some of my previous articles for more on this). Process Improvement gurus have an unfortunate, and well deserved, reputation for failing to be very practical and business oriented.
I remember one very senior Process expert who reacted to my views (about needing to be hands-on and technical) by saying that, "I may not have ever laid an egg, but I am a better judge of an omelet than any chicken." That's a cute visualization, but I really feel that process engineers should strive to have very strong technical hands-on experience. I can tell you from my own first hand experience, that your colleagues will respect you a lot more when you can really get into the trenches and help get the release out the door. One reason that this is so important is that hands-on technology professionals understand both sides of the coin and therefore recommend sensible process steps that meet a specific requirement. So if you don't have strong technical skills now - get them. You may not need to know them in as great a depth as your colleagues, but you definitely should work towards gaining hands-on expertise.
Document the workflow
Documenting workflows and writing scripts to automate and "idiot-proof" the entire build and release management process is also essential. Two many technology professionals think that there is some badge of honor in doing technical work that is very complicated. The problem is that if they skip one step the release is doomed. The skilled CM and Release Management professional creates a process that is as simple as possible and makes it completely impossible to make a mistake. In Aircraft, ergonomics experts look at how to design cockpit controls that are setup in such a way that the pilot is least likely to make a mistake. In my work, I look at the ergonomics of developing software and I try very hard to anticipate and prevent any possible mistakes. Developers often laugh at the checkpoints in my scripts that test for every possible build and release issue. I also regularly pause in my scripts and ask you to confirm that a particular message is on the screen. (After some time these pauses can be removed and sometimes the build can be automated in a nightly cron job.) Because of these steps, my releases work each and very time and I can always get the release out the door in a fraction of the time that it was taking before!
Where to begin...
Getting started is always a matter of reviewing existing procedures and documenting how the build is getting done right now. Many developers will be resistant to this and may even try to provide misinformation (in order to block you from taking control of their release management)! I usually observe them the first time and take snapshots of the console so that I examine all of the steps that were executed. Then I will ask them to teach me their process and I will insist on them staying with me the first few times that I build the app. (I always tell senior management, before I start, that I need this time with the developer in order to be successful.) I share all of my notes with the developers and I try to engineer my job into a service for the development team. (Usually, I call my group - Release Management Services).
It is essential to show that good CM and Release Management will help get the job done faster and error free. This is the all important bottom up approach that is a critical success factor. Demonstrating that we can help get the release out the door, without mistakes and faster than ever before, is an excellent way to show the added value of Release Management best practices. Most of all we need to be business focused and show our commitment to getting the job done. That means defining the process that keeps the business priority in focus. Communicating risk (usually to senior management) and making smart choices that are in the best interests of the firm is also key to a successful effort. I have had many times when I did things that were very unorthodox for a real process guy - but I have always consulted senior management and focused on making the right choices from a business perspective.
The business of software development needs good CM and Release Management process and best practices. CM practitioners, who are knowledgeable, practical and business focused play a vital role in helping the company achieve success and profitability.
Bob Aiello is a Senior Editor for CM Crossroads and an Associate Director at a major financial services firm in NYC, where he has company wide responsibility for Software Configuration and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra University.
Trackback(0)
 |
|
Last Updated ( Tuesday, 01 April 2008 )
|
TrackBack URI for this entry
Subscribe to this comment's feed
