Why is it that we keep revisiting configuration management “best practices”? It is not that they are not well covered. It is because they keep changing and every time we look at the process of development from a different perspective, we learn something new. Over the last few years, I have found that what we do under the guise of CM differs in how we identify the problems to be solved, how we address those problems and even what tools are appropriate.
This month, there were several areas that have not really been covered from the viewpoint of how they impact CM that I have been dealing with either personally or with others in the CM industry as we try to help each other. These are software architecture, branching and merging, hardware, and documentation.
Software architecture is a combination of the framework the rest of the software operates under and the directory (package) hierarchy the software resides in. This is the part of a software system that is least flexible in that it tends to need backward compatibility and a consistent, documented, stable interface specification. And yes, I use the “s” word even in agile shops. Imagine just how difficult it would be to develop software if the underlying language kept changing – sometimes between builds! This is what it is like to develop software where the core functions keep changing.
So how does this work in an agile world? Several people have commented recently that being agile does not mean no long term thinking; just no long term scheduling. There seem to be two practices that work:
- Determine the architectural needs for user stories that are at least one to two sprints later and schedule them so that they are done well before they are needed. The interface documentation needed by developers and testers should be done no later than the one sprint cycle before it is needed so it is available for planning.
- First, break the product backlog into functional and architectural requirement, where functional requirements are generally represented as user stories. As user stories are prioritized, they are dependent on architectural requirements that also have to be included into a sprint. This means that the initial sprints tend to consist of fewer user stories and more architectural tasks.
Personally, I like the first approach better. It allows the “architecture” to be treated as a separate product the user stories are dependent on. No user story can be considered for a sprint unless its dependencies, at the architectural level, are satisfied. By defining what is needed for each user story and taking into account their desirability (think implementation priority), it is possible to prioritize the backlog for the “architecture” and develop it using agile methods too.
Regardless, the way software is physically architected can have a serious impact on the problems experienced within a SCM framework – especially the version control component. If software is modular and hierarchical in nature, in other words not pathological or “spaghetti,” then parallel development is easier. There will likely be fewer conflicts that require merges since, most of the time, changes will be focused on isolated features. When this is not the case, merges often take far longer than planned and produce results that need to be almost completely regression tested. Some of the code that is common to multiple “functions” will artificially appear to be “fragile,” leading to unnecessary refactoring or possibly even unnecessary rewrites.