Why I love Software Configuration Management

Before I will start to dive into nuts and bolts of Software Configuration Management, I would like to explain why I love it. Actually, that’s the question I’m being asked very often: “Why do you love Configuration Management? What’s so special about it?”. My answer is very simple in most cases: Because it’s missing part of the puzzle!

But, in fact, that’s not an answer at all. Real answer probably requires clear statements and supporting examples. And that’s what current post is about – I explain why I love Software Configuration Management without avoiding the real matter.

  1. SCM is the essence of mature development practices. Target goal of software development is the software product. Sometimes it is enough to have development phase in order to supply this product. But high quality product cannot be built without supporting activities beyond software development. Personally I think that SCM can be considered an essence of mature development practices and solid framework for software quality because of the several reasons. One of the main reasons is that SCM lies at the intersection of major software engineering practices: project management, software development, quality assurance, quality control, deployment and support. 
  2. SCM discipline is underestimated and worth to be promoted. How many configuration managers do you know? A few? You’re lucky then. Because, in fact, few people call themselves configuration managers. Not many know what SCM is. Moreover, there’s no demand in SCM specialists (at least in my country) and, therefore, no supply. If SCM is underestimated as long as mature software development practices are underestimated as well. SCM is especially underestimated in the aspect of cohesion with principles of software quality. Personally I would like to prove that it’s very important to have best SCM practices applied in your projects to reach highest level of quality of your software products.
  3. SCM tracks and measures evolutionary processes in order to support desired level of quality. Evolution is the miracle of life. Aren’t you fascinated with the way things evolve as deeply as I am? I love to observe how fast living things grow (flowers, trees, pets and children), watch how things change and transform being influenced by unknown force. And not only living things evolve, but ideas as well – there might be different versions of the same book (editions), song (arrangement) or painting (in different techniques, for example). These processes usually are not tracked or controlled – they just go on. Attempt of controlling such things might be undesirable because of the intangible nature of creativity. But there are different kinds of evolution that probably should be controlled. Let’s take, for example, education – evolution of the person’s knowledge. There definitely should be measurement of educational effectiveness. Otherwise there will be no way of defining whether person can be considered professional enough. You won’t expect surgery to be made by amateur, will you? Therefore, educational progress should be tracked and measured in order to get desired level of quality. The same principle can be applied to the process of software evolution. Software should be tracked and measured throughout its whole lifecycle in order to get desired level of quality. And the way software evolution is tracked and measured is defined by Software Configuration Management. SCM plays a huge role in defining metrics and measurements for quantitative control over the processes of software development and, as a result, over software quality as well.
  4. SCM facilitates teamwork and collaboration. The most important subarea of SCM is version control. It appears on the stage when more than one developer works on the project. Therefore, collaboration of the team should be managed somehow. Even though version control is put in charge of many issues related to collaboration, it turns to be not sufficient enough for effective collaboration. Especially when there is a team consisting of more than 10 developers. There should be rules and conventions beyond version control which would be able to establish solid ground for collaboration. Development, support and promotion of such conventions are at the mercy of SCM. Thus, SCM practices and approaches define limits and potential of how effective could be the team. There’s always something special and mystical about how the team works, how it reaches project goals and the way it collaborates. Great team has its synergy as a weapon– it’s not the sum of its parts, but something much more. This synergy and the possibility of making synergy appear namely from nowhere fascinates me as deeply as the miracle of evolution.
  5. SCM helps in appreciating developers’ work. SCM supports developers’ teamwork in a way that they do need to bother only about development, nothing else. Writing source code is primary developers’ responsibility. But source code merging and version control are not responsibilities of developers even though it is related to source code as well as writing source code. SCM is a whole new world beyond development. And while this world exists, developers can do their work (writing source code) effectively without tedious distractions. World of SCM provides guarantee that if there is source code written, then this code will be part of the final product. Therefore, work of the developers is appreciated if final user likes the product.
  6. SCM makes software development more efficient, meeting project goals more quickly. It reminds crane and scaffolding helping builders at the construction. It would take much more time to build any building without the help of construction support services. And SCM plays the same role for software as construction support services play for construction – make development more effective and quick.
  7. SCM = professionalism. Configuration manager title requires thorough expertise in several fields, such as: software development lifecycle, software development, administration, quality assurance and project management. Configuration Management is complex integral discipline. Skillful configuration manager will probably have a lot of experience and knowledge about software engineering. I consider configuration manager to be high level professional with unique vision of software development processes and practices. And I would like to consider myself to be such kind of professional.

I think that’s it even though it seems that I can extend this list up to 20 items and talk endlessly about why I love configuration management. There are many reasons why it has become my passion. Among these reasons are those I have mentioned in the current post and the one I have not. The last reason why I love SCM is that I have unique vision of effective SCM and its practices. I would like to promote those ideas. That’s, actually, why I have started this blog and that’s what I will talk about in my future posts. Hope to see you here soon reading my next articles.

Initial post: what I will write about in the blog

Welcome to my blog curious stranger, no matter who you are. At this first blog entry I make an attempt to describe my plans regarding future content of this blog.

First of all, I consider myself to be software configuration management (SCM) expert. It means that I should, most probably, write about SCM on a regular basis. Well… I made such attempts in past, but for some reasons I’ve been engaged by other activities (trainings, conferences, educational activities, offline SCM evangelism, etc). But, as it turns out, nothing could replace the power of written word. I would like to give it another try – express my thoughts on SCM in an accessible and unobtrusive manner as though I would talk with you over a lunch discussing interesting aspects of configuration management.

Over last 4 years I have been developing a clear vision of software configuration management and its best practices. It’s time that I share this vision with you. Not only that I’ve been working as a software engineer, trainer and configuration manager, but also had a chance to participate as a speaker in numerous conferences, conduct educational activities and, as a result, come up with an exhaustive training covering software configuration management practices: version control, build management, deployment management, continuous integration, branch & merge management, release management, versions numbering. I will use materials of the training in order to prepare content for this blog. I have a lot to write about – not only configuration management, but also project management, quality assurance, requirements management and software engineering in general.

I want to make emphasis on the fact that everything I will write about in this blog will be based on my personal vision of configuration management. Primary basis of this vision is the unique version numbering approach I’ve developed after exhaustive research in the field of configuration management. It might seem tricky at the first glance, but I will try to make it as more accessible for understanding as I can.

Here is the short list of topics I would like to cover in my future posts:

  • How version number is formed?
  • Types of branches in version control systems
  • What affects the number of branches in source code repository?
  • What can we tell about the application having only its version?
  • Relations between source code repository artifacts
  • How version numbering affects the way builds and deployments are managed?

Hope you will find my articles interesting and useful. Stay tuned!