Software Configuration Management is typically considered a supporting activity of the Software Development Life Cycle; and this is by all means true.

But what would you think if I suggested that Software Configuration Management is a Software Development Life Cycle? Suppose for a moment that SCM is an SDLC.

Every software development professional knows a little something about the SDLC. The acronym brings out visions of incessantly long, drawn-out waterfall processes for some. Others simply think of this as “what we do” when developing software products. Of course, many of the new age developers use modern SDLC processes called lean or agile or SCRUM or some variant of these. Our personal views of software development processes are shaped by our education and experiences. The variety of opinions is inherently clear in the on-going discussions we have regarding the best and worst ways of doing common ordinary things like version control or bug tracking.

The SDLC not only impacts the speed with which we develop our products; it also impacts the functionality and all of the other characteristics of the products themselves. And since the main purpose for many of our products is to solve business problems, I think it’s fair to say that a variety of SDLCs are needed to satisfy the vast array of challenges ahead of us. This line of thinking might be just another way of reaching the same “no silver bullet” conclusion that Fred Brooks describes in the Mythical Man Month, but perhaps more from a customer needs perspective as opposed to reaching this conclusion from a study of development organizational structures.

The appropriate SDLC process depends on the business problem being solved by the products we are developing. Software in games is developed differently from the software in an airport control tower because the business problem is different for the two projects. All of the various SDLCs are good when implemented on the right project; and bad when used on the wrong project. It’s not the processes that are good or bad, it’s the fit that is good or bad.

So if we put two and two together, we can say that an SDLCs job is to solve a business problem by creating and implementing the right product, and since SCM problems are business problems, it stands to reason SDLCs can be used to define the SCM processes [which are nothing more than the set of SDLC processes]. You might be thinking this presents a bit of a chicken-and-egg problem because you can’t use an SDLC to create an SDLC until you first have an SDLC; but fortunately for us, that problem is gone now.

SCM IS SDLC

I’ve been working as a dedicated continuous integration engineer for over 15 years, and this is how I frame my work; as an SDLC process. Inspired early on by Martin Fowlers flagship integration book, http://martinfowler.com/articles/continuousIntegration.html, I am one of the few software engineers who stayed working in the SCM arena instead of moving off to become a software developer or QA engineer because I like it here.

This purpose of this new website is to facilitate academic style discussions regarding the use of the SDLC processes to solve the internal business problems of SCM and other SDLC processes used inside software development organizations; the utilization of SDLC to select and create SDLC.