 This month is the annual retrospective for the year and normally next month is the predictions for the coming year, but they are too coupled in my mind to separate. So, just to frustrate our overworked and underpaid editor, I am combining them this year. Note that the topics presented below primarily reflect changes in the way software is developed, tested and released and affect CM more than they are based in CM. They are in no particular order.
Security and Intellectual Property
Looking Back
CM, especially Software CM, increasingly has to deal with code that expresses Intellectual Property in a distributed fashion. By this, I mean we are using more multi-site repositories, more distributed repositories and more “cloud” or service/hosted repositories. Some of the problems are:
- Many of these communicate over connections that are not truly secure. Often the security of the connections is left as an exercise for the IT department, many of which are overwhelmed with other more imperative work and others who do not really understand how to secure connections in the first place. Add that many developers work remotely using open WIFI connections and the problem only gets worse.
- The locations where these non-centralized repositories reside may be countries that do not abide by the same security (and privacy) laws and regulations as the host country. This can make enforcement of “leaked” IP (or even identification of stolen IP) difficult or impossible.
- Workspaces on local developer systems, often laptops, is generally not physically secure nor is it encrypted to prevent loss in cases of theft.
- Local developer systems are often more vulnerable to hacking, malware, viruses, etc. since they do not have the “corporate IT infrastructure” in place to prevent it. Additionally, even in cases where this infrastructure is possible on a workstation or laptop, it would degrade performance to such an extent that developers would disable it.
The reason CM has to be concerned is that we are the “last ones to touch it” in cases of exploitation. We have the reputation of being paranoid (and if we don’t, then shame on us) so at a minimum we need to be aware at both business and technical levels as to what security is actually in place. We then need to monitor for two things, even if we have no ability to do anything about it:
- Insertion of unauthorized code (as well as defect records, enhancement requests, change data, etc.) into our repositories
- Unauthorized exposure of critical IP
Looking Forward
I predict that, even if does not happen in 2010, it will not be long before these situations will occur and make the press. Preventative measures should be investigated, implemented and/or integrated into existing processes and tools to at least detect and track violations.
Agile Maturation
Looking Back
The Agile Methodologies are maturing, and personally I think it is about time. By maturing, I mean that they are stabilizing and that canned approaches that work are now becoming readily available. There are consulting organizations that can help companies do a fairly rapid transition from more classic methodologies to Agile ones while making significantly fewer mistakes along the way. There are now tools available, both COTS (Commercial Off-The-Shelf) and FOSS (Free/Open Source Software), that either have an Agile mode or have been created from scratch to support Agile methodologies.
Unfortunately, Agile is still perceived as a silver bullet solution by a lot of people. As success stories accrue, mangers and CXOs want to jump on the bandwagon to remain competitive. This is causing its own problems. One problem that has started to be recognized within the Quality industry is the lack of stability in production releases and upgrades. Agile is a great approach for development when requirements are fluid or unknown and when features need to be added quickly into a product. It is not always the best approach for factoring in fixes (maintenance).
Looking Forward
I predict that the trend towards using Agile methods for new product and new feature development will continue, but a more traditional iterative approach will be used more often for production release maintenance. The integration and testing of the resulting codebases to create new baselines will be interesting to see. The challenge for CM, both personnel and tools, will be to support both models at the same time within the same repositories.
Rapid Response CM
Looking Back
There have been several articles and forum threads over the past year dealing with how CM is now having to respond extremely quickly to changes in development methodologies and practices. CM infrastructure must be in place to support the existing way of doing business as well as the “new way” – and it must do so before the “new way” is needed. Many organizations will go through several “continuous improvement” cycles while they tune new processes and procedures (“discovering” new problems to overcome along the way). Depending on how many different teams are using the same CM infrastructure, the rate at which CM needs to not only respond quickly and flexibly, but to also maintain backward compatibility, is approaching a limit. Soon, we will simply not be able to keep everything running properly. Standardized metrics, both process and technical, become increasingly difficult to produce and are prone to be faulty when they are.
So far as I have been able to hear from others in the trenches, we are surviving, but many are barely hanging on. Hiring additional CM resources to support “lean and mean” methodologies is not something that Management wants to hear.
Looking Forward
There are several tool suites and tool integrations being worked on by COTS vendors that may help alleviate some of this pain – and many are posed for launch in 2010. There are also FOSS tools such as git that have matured to the point where they are not only attractive in themselves, but integrate with other tools as well. Additionally, CMers will continue to apply more of an Agile approach to their own work, especially in the way of handling rapidly changing/evolving requirements. More and more back-end configuration and integration will be done using state- and/or data-driven approaches that will mean faster turnaround of requested changes.
Development-Directed CM
Looking Back
Again, the advent of Agile methodologies is causing many organizations to place the CM group under Development – and even if they don’t, Development is being given more power to dictate the requirements CM must implement. Historically it was discovered that the best approach was to have CM be its own organizational unit at the same level as Development and Quality – and to have veto power over both process and procedure changes 9as well as releases). The second best approach was to have CM be a subset of Quality where they contribute to Quality’s ability to exercise the same veto powers. Being under Development has tended to remove the ability to veto anything while being mandated to violate core CM principles just to make Development “better.”
Over the last year, this tendency has increased; or at least that is what many postings seem to indicate. CM is still responsible for the tools and infrastructure, but increasingly they are having branch/stream patterns, merging patterns, etc. dictated. This is analogous to having a requirements specification dictate the framework and specific code that should be implemented instead of letting Design and Development control those aspects of development. This is a dangerous trend that we have seen repeatedly over the years.
Looking Forward
The good news is that this trend rarely lasts for long. The bad news is that I think it will take more than a year for enough failures to manifest themselves (and get the press attention to make them visible). Once it does, however, I think we will see a swing back to where CM has more control over the process – at least to the point where they can reject things that will cause more problems than they fix. We will still need to be able to rapidly adjust all aspects of the CM infrastructure, processes and procedures as the days of us being able to “take our time” are gone. It is just that we will be part of the decision making process instead of just implementers.
Commercial vs. FOSS Tool Wars
Looking Back
There has always been a battle between commercial tool vendors and FOSS tools. On the one hand, FOSS tools are free, the support is often fairly good and fixes are available quickly. The down side is that few of them are integrated out of the box and that installation and administration must be done by the end user. When problems crop up, and they do, then it requires a fairly high level of technical sophistication to be able to diagnose root causes and submit defect reports that give enough detail to allow the problem to be resolved. COTS tools have been following a trend of becoming all things to all people (i.e. monolithic tools or suites of more or less integrated standalone tools). Some of the vendors are actively pursuing integration with non-competing products, both COTS and FOSS, as a value-added approach to gaining marketing share.
During the last year or so, the growing number of ALM (Application Lifecycle Management) tools and the need for CI (Continuous Integration) build systems has changed the CM tool landscape somewhat. The COTS ALM tools that were already present such as AnthillPro, BuildForge and ElectricCloud have matured and increased their ability to integrate with other VC (Version Control), DIET (Defect, Issue and Enhancement Tracking), code quality, static analysis, unit test, code coverage and “low-level” build tools. They provide both centralized reporting (dashboards), process/workflow control and release capabilities. FOSS tools such as AnthillOS, CruiseControl and Hudson provide similar base capabilities, but do not support the range of integrations or depth of control “out of the box.” What all of these tools/suites provide is a centralization of CM metadata and metrics and the ability to only learn one user interface – one that non-CM users have access to and can understand. Unfortunately, their primary benefits are also their disadvantages. They cause product lock-in. If something were to happen to COTS tools, such as is rumored to be happening to the old Rational suite of tools offered by IBM, then alternatives may have to be found and found quickly “before the license expires.”
It is easier to looks at individual tools that are integrated into this ALM landscape, tools such as the VC tools AccuRev, ClearCase, CM+, cvs, git, Harvest, Perforce, Serena Dimensions and subversion and see which meets the specific needs of an organization. Similar choices exist with DIET tools (such as AccuWork, Bugzilla, ClearQuest, JIRA , Team Track and Trac) and the other components of an integrated solution mentioned above. For each class of tool there are choices to be made to maximize productivity and minimize cost. In other words, there is a large range to choose from to minimize the total cost of ownership of the CM tool suite.
Looking Forward
I foresee that the ALM trend will accelerate during the coming year and that there will be variations specifically tailored to Agile development. The number of “outside” integrations will increase and the consolidation of data for reporting purposes will as well. Dashboards will become a part of our life and if the tools do not provide them, we will have to! In an effort to gain a foothold in this market niche, some vendors will start offering free or extremely inexpensive introductory offers. FOSS “vendors” will continue grow their market share via word of mouth and exposure through venues such as CM Crossroads. The dominant IDEs will continue to dominate with few to no new viable entries. In terms of distributed Version Control, I foresee a greater penetration by git and its add-ons.
The Web’s Dependency on Fat Pipes, etc.
Looking Back
Most of the dashboards and ALM GUIs are dependent on some form of web server. For the most part, these are Apache, Tomcat or Microsoft offerings. The density of graphics, data and the sheer number of links on each page require significant bandwidth to display fully. This is even truer with regard to technology-related web sites where the presence of flash, advertisements, reference links, etc. can cause many systems to time out before they even begin to pull all of the information necessary to display a page. The bandwidth necessary to support both our tools and our reading habits has become excessive.
Even more troubling is that it is becoming increasingly difficult to make these pages web server agnostic. I use a restricted Firefox as my browser of choice on my workstations and laptop. JavaScript, popups, cookies, “foreign” links, etc. are all blocked by default. This is true regardless of whether I am running on Windows or Linux (or even AIX). I also have a browser on my latest PDA. Some of the sites I visit require IE-7. Others will not work with IE-7, but will with -6. Some will not work with Firefox at all. Chrome, Linx, Opera, the list goes on. There are standards that all browsers are supposed to adhere to, but few do. This is even a problem for tool vendors that use a Web GUI. During this past year at least one of the tools I use daily stopped working reliably with specific versions of Firefox. The vendor resolved the problem quickly, but problem remains that there were so many permutations they were not able to catch it during testing.
Looking Forward
These problems are going to get worse. Maybe by 2011 we can see some relief, but faster network connections and dependency on specific browsers/servers will probably be the answer we get.
Overblown Web sites
Looking Back
I mentioned this above, but I want to repeat it. I even have trouble with intranet sites at various customer locations. Currently, I keep three different browsers loaded just so I can visit both intranet and internet sites of interest. On my Linux laptop, I even have a chrooted (jailed) browser set fully opened up so I can visit some sites safely.
As I also mentioned above, I got a new PDA/phone this year (and yes, it is an Android-based one). It has some nifty browsers available so I thought I would be able to look at sites such as message boards and CM Crossroads while on the road. No such luck. There is generally too much data to display, too many links or the presence of graphics that cannot be displayed. Ever had a site that tries to determine if you are a human by displaying some graphics characters and asking for you to enter them? What do you do when the browser cannot display the graphics? In my case, I gave up - for now. There needs to be more consideration given to using open standards for graphics, video, etc. so that the material is displayable regardless of platform. There needs to be a return to the concept of either allowing a user to specify preferences for what they see (and the initial default is fairly crisp and lean) so they have a hope of seeing something or reducing the clutter and bandwidth requirements for web pages in general and home pages in particular.
Looking Forward
In general, I see no relief in sight. And that is depressing.
Connections via Mobile Devices
Looking Back
This topic ties in with the previous two topics, so bare with me. The majority of us CMers are geeks (you may substitute your own favorite word for “geeks,” so long as you admit to being a reasonably technologically sophisticated person) and as such tend to have gadgets such as PDA phones or netbooks that we use to keep in touch with our world. This means that the tools we use need to be able to support these restricted devices. IE, Chrome or Firefox are probably too much to expect of these devices, so either offer a /m option (for mobile) or just present data in a simpler form.
The rate at which PDA phones are evolving and being accepted into general use is something that I did not expect, but then again that is why not being able to use them is causing problems.
Looking Forward
Here I foresee some relief. The tool vendors will listen and make the tools, especially dashboards and admin GUIs, more accessible from mobile devices. Now if the mobile device manufacturers will start putting decent VPN clients on them…
IEEE and Other CM Standards
Looking Back
As many have seen in the General CM forum this past year, our own Bob Aiello and others have been working on revising existing standards (as well as starting to create several new ones) where the role of CM is being more fully covered. While most of us have not seen the drafts of these, I think it is a positive step that the work is being attempted at all. There is even an attempt at resurrecting the CM Compendium of Thought, or whatever we need to call it for legal reasons. As is always the case, these things move slowly so any progress at all is encouraging.
Looking Forward
I am looking forward to hearing details of what the various drafts contain. Hopefully we will be able to get some of the authors and/or reviewers to give us some articles this coming year detailing what they contain and maybe contrasting them to other comparable standards. There are also ventures underway to standardize Requirements language and CMDB content, so hopefully we can hear more about these as well.
Increasing Confusion Over What CM “Is”
Looking Back
The more we learn, the less we know. Someone mentioned to me recently that the definition of CM is like the old story of a man wearing two watches – he never knows what time it is. Once again there have been many postings at many sites (not just at CM Crossroads) trying to determine just what is meant by CM. Most of us agree that it stands for Configuration Management, but a good case can also be made for Change Management. Regardless, even if we pick one of these, what they mean depends in turn on not only who you talk to, but in what context and when. CM as “acquired” many hats over the past 20 years – some of which we never should have worn. So far, even definitive answers have done nothing but spark more discussion and controversy.
Looking Forward
I foresee a day when this question, along with a lot of others, will be answered. Unfortunately, it will be long after I am dead. And probably after all of you are too, so I guess I foresee this debate continuing and the answers evolving and changing as the times change. I look forward to participating in the discussions.
Happy Holidays everyone!`
Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis supporting a modified Agile-SCRUM development methodology. He uses a combination of AccuRev, CVS, Bugzilla and AnthillPro (as well as custom tools). He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), FWLUG (Fort Worth Linux Uscers Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).
Trackback(0)
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed
guys can you make the articles smaller or add a video / podcast instead of a big write-up. I do appreciate your efforts.However,its easier and helps audience grasp faster what you intend to say.