Book Review: Software Release Methodology


Title: Software Release Methodology

Author: Michael E. Bays

Review originally posted on November 2004.


This book focuses on the release aspects of SCM (Software Configuration Management)  before SCM was a well-defined concept. When originally published in 1999, there were few resources available on the subject and therefore made this book a valuable resource. The author’s writing style tends to be wordy, but the persistent reader will be rewarded by discovering some of the key insights contained within.

Recommended for those who are new to the software development release process.


Chapter 1 presents an overview of the software development process including terms, definitions, and processes commonly used. This is where the role of Software Integration and Release Methodology are introduced.

Chapter 2 is a non-technical primer on files, tools, and source code. Very introductory and can be skipped by any developer.

Chapter 3 takes a closer look at source control and various issues surrounding it. It exposes the reader to checking in/out, locks, tags, branching, and merging. Various protocols are discussed as well as branch management, merging strategies, file versioning, and tagging strategies.

Chapter 4 focuses on builds and the build process. It discusses developer environments vs. official environments, build reproducibility, build tools, product building, and the source tree. Various build strategies are explored as well as controlling the developer’s build environment. Lastly, the chapter touches on build automation.

Chapter 5 covers defect tracking and introduces the reader to the various details and processes used. This is also where release documentation and defect metrics are presented.

Chapter 6 has a larger scope and focuses on the overall system integration effort as performed by release engineering. Modularization (SDKs, classes, etc) is introduced as a concept that enables this type of activity outside of the development environment. It is in this chapter that the System Integrator role is defined and presented. An interesting insight on this process is revealed in the section on scheduled integration efforts vs. event driven integration efforts. The system integration schedule is also covered as a process mechanism. For scalability, parallelism of the process is presented along with the system integration cycle. Process aspects covered include functional verification and build qualification. Finally, large scope issues such as centralized system integration, integration protocols, and change control systems are reviewed.

Chapter 7 reviews change control processes including product functionality specifications, programming and implementation style guides, and feature design. In this chapter are also discussions of code reviews, organizational wide requirements and processes, code control, and change scheduling.

Chapter 8 discusses product release classifications and numbering. Here is where alpha, beta, and final versions are defined along with coverage of patches and emergency fixes. Rounding out the topic is release packaging, customer support for the release, and actual release classifications and numbering. This last area introduces syntax used, methodologies, iteration aspects, and presentation. Of last concern are internal vs. external numbering and just in time numbering.

Chapter 9 presents release distribution, which is simply media types, installers, mastering, and release notes.

Chapter 10 discusses release engineering service strategies. This is particularly interesting for growing organizations that need to build such a team. It reviews the nature of these service groups, flexibility vs. inflexibility trade-offs, centralization vs. decentralization, and the various resource needs such a group has over the release cycle. There is also a discussion of the impact of multiple products on such a group.

Chapter 11 covers release management and planning. Various types are identified, such as reactive/chaotic, reactive/structured, informed consultant, and dictator. The author did start out on the right path here but ultimately disappoints by his rather shallow analysis of the models. The final sections of the chapter focus on process development, deployment, determination, maintenance, evaluation, improvement, and execution.

Free Your Code

Anyone who has written code over the years invariably has a collection of programs, libraries, and snippets that are strewn about a dozen different computers, hard drives, CDs and maybe even a handful of floppies. The origination of this code may have been school projects, experiments, or the ramblings of a coder mind. Whatever the genesis for this code, the reality is that much of it is lurking in the corners of your digital landscape, like dusty cobwebs hoping to catch a midday meal for a long forgotten creator.

This code can continue to rot and fade into nothingness. Alternatively, this code can be released from its current form and be free. This is my argument for sharing our old code with the world. Put it somewhere everyone can access it. Study it. Review it. Let anyone who has an interest learn from what you have created. I found any number of excuses for not doing it myself: “it’s not done”, “it’s ugly”, “it has bugs”, “it’s my solution”… the list goes on. Sure, we can all make those claims and many more but it still doesn’t change the fact that this code is contributing to the greater good. I’m not talking about code that we’ve written for hire (commercially or otherwise)—That code ultimately belongs to someone else and it is their decision to free it. Don’t underestimate the value of the code that you can free.

Another benefit to freeing your own code is that it will make you a better coder, a better designer, a better architect. The interactions you have with other with regards to your contributions will teach you. Your own expectations of what you write will also rise, knowing that it may receive a lot of attention. I wonder how many unfinished projects, how many ingenious algorithms, and other interesting artifacts lay about this world.

What contributions are you willing to free?

Celebrating Life Through Programming Languages

On the eve of my birthday, I realize that for those of us who program, we tend to get excited when we talk about the programming languages we’ve used over the course of our lives. These languages not only make us laugh at times, but they also give us cause to celebrate and make us nostalgic. We can even measure our own existence by the languages we’ve used—like the growth rings of a tree. I think it’s possible to approximate the age of the coder in question by asking them the first language they learned—and the answer can sometimes give clue to the age of the inquisitor.

My own personal journey started with Apple Basic, and then Apple Logo, followed by Atari Basic, Atari Logo, and then my first “real” language: Pascal. Soon to follow were Modula-2, 68000 Assembly, and DEC VAX-11 Assembly (thanks RIT). Next was C. C was a game changer for me. It was the first time I felt that I had the power of assembly but the convenience of a higher level language. Its terseness was seductive, although punishing at times. I still remember helping various classmates understand the concept of pointers. I guess C forever earned a place in my heart because soon after learning it, I had to write Cobol.

But life continues. C++ was breathing heavily on my neck and was a force to be reckoned with. OOP was not a concept taught formally at the time and the new powerful modes of expression took time to understand and then appreciate—much like wine, the air needs to let it breathe for a while for the full complexity and richness to develop. It was inevitable that Java would be along the path to maturity, but I fought it like an aging hippy fighting the establishment.

The Internet era brought a mixed bag for me, a bit of the new, a bit of the old. Languages such as Perl, JavaScript, PHP, Ruby and Python were also learned. In an sentimental bout I even wrote an Intel 4004 Assembler—not that it was useful, but it certainly was fun to learn the history of this pioneering microprocessor.

Even when I thought I had all the possible languages I would need, I learnt one more: Scala. I appreciated what Scala did for me—it removed the disdain I had for the JVM and made me feel oddly comfortable with a syntax that seems part Java and part C++.

I’ve probably forgotten a few languages—I know one or two are even languages per-se (some horrible report generation language from Cognos) and various scripting languages (Matlab, LUA, etc)—nowadays probably better known as DSLs. What will be in the next few years for me? C#? Objective-C? Go? R? Lisp?

I hope you, too, take a moment to think about the languages you’ve learned along the way. I hope you can laugh at some of them, too, just as I have.