Building a House

About a month ago, I provided a post in this blog that suggested that enterprises consider taking some of the processes that are used to produce Subversion (as an example of good open source processes): In addition to the code. That stirred some interesting discussions, more offline than online, so I wanted to revisit this topic.

I find it disappointing, if not surprising, that enterprises are so reticent to consider the less restrictive, but still process-driven configuration management procedures that the Subversion project utilizes. I get a lot of initial backlash when I talk about open source processes. The reality is the backlash is not really coming from knowledge, but uninformed impressions. It is almost funny to think of organizations, who depend upon open source technology (e.g., Apache, Linux, Subversion, etc.), rejecting the processes that produced it without true consideration. That’s like saying "I love my house and find it to be of high quality, but I wouldn’t consider building another one the same way." What happened to good old plagiarism of successful ideas and processes?

For example, visibility seems an obvious approach to better quality that should be enabled by our processes. First, one is going to be more cautious in their work knowing that it can potentially be seen by the broader project team. It is a strong deterrent to shortcutting the coding standards that the project (or the enterprise) has identified. Second, the code benefits by having more eyes reviewing the changes, which means a higher probability of issues being identified earlier in the lifecycle at a lower cost to their enterprise. I realize some people are reticent to having their work "exposed", but that shouldn’t be an inhibitor to doing the right thing. Most of the people that you really want doing the work will welcome the chance to share their "brilliance" at a more detailed level. This visibility is achieved to some extent by general read access, but also by posting deltas to a mailing list and its associated archive. Visibility can also be enhanced through an association of the delta with a change request

If visibility is achieved, then it is logical to consider what the impact would be to other processes. Who would consistently violate accepted processes if they knew the team saw those violations and knew the team is impacted by those violations? How would the broader team react to these violations? Aren’t people hired with the expectation that they will do the right thing for the enterprise and as an extension of that, for the project team?

Contrast that to implementing a hook that impacts everyone’s productivity and, while forcing adherence, can be consistently required for some users versus correcting their behavior. Each user pays a price with every operation just in case they "might" be violating a process. Of course, since we’re talking version control (aka a time machine) the changes can be rolled back if a violation occurs. And consider the fact that this won’t be isolated to one type of violation, but will be repeated for many different types which will build on the impact to each individual.

I think enterprises need to become more open minded and consider the benefits to the approach the Subversion project takes versus the process enforcement that most lean towards today. Since you’ve built your house on Subversion (Apache, Linux, etc.), it seems reasonable to look to build other houses in the same way.

Bob Jenkins

Bob Jenkins has spent over 17 years focused on application life-cycle tools. At CollabNet, Mr. Jenkins consults with enterprises that are planning to adopt Git or Subversion on how to apply best practices to their SCM processes. He aslo helps define the areas of investment by CollabNet in open source version control tools.

Tagged with: , , , , , , , , ,
Posted in Subversion
6 comments on “Building a House
  1. Mutant Web says:

    Why Code Visibility is Important

    I read an interesting blog post this week on Submerged (the official Subversion blog) which had an interesting take on why open-source development models work. The blunt of it came down to the fact that people write better code when it is exposed and r…

  2. Ken Sykora says:

    Good stuff.. couldn’t agree more.

  3. Chris Ziehr says:

    We live in a world that does not judge the ‘goodness’ of a house solely on whether the owner loves it and considers it ‘good’. In fact, our world has many different zoning ordinances and building codes that form an unavoidable set of criteria of goodness.
    And here’s where the metaphor no longer works: in the world of construction, we hire an expert (or set of experts) that know the laws and codes so we don’t have to. In the business world, we can not afford to have these experts, and it is not feasible to train every practitioner on every law/code — much less, to expect them to retain that knowledge on multi-year developments.
    We need to rely on process for that memory of the steps necessary to meet the laws and codes of our market space. So it is not, as suggested, hypocritical to refuse to accept the process standards that were utilized in the development of an open source tool as the processes for the development of a product for a commercial aircraft or military sensor. In fact, it is exactly right to NOT have those processes be the same, as the laws and codes for the developments of each are very, very different.

  4. Bob says:

    The assumption you’re making is that there are different laws and codes, but that is merely your assumption. Many times perceived differences in laws and codes are just that, perceived. Many are out of date and require replacement or modification. My metaphor says that’s exactly the case for enterprises. Just saying the old ordinances and laws are different isn’t justifying them. Somehow we like to perceive ourselves as different rather than like others. I’ve seen this for one enterprise versus another over and over. Each time, the people explain to me that their development and their processes are unique to them. Yet, there are rarely significant diffences, though there might be nuances of difference. Many times what an enterprise perceived as a requirement had no real business case or in fact, couldn’t support the professed purpose.
    There is no such thing as one size fits all, but assuming that things have to be different is just as wrong. My point was that enterprises need to consider the processes that are being used and see what’s applicable rather than ignoring them. Processes that have produced the market leader in version control (according to Forrester) should be considered by anyone who also wants to be a leader in their market. And no one is suggesting a complete adoption, but a reuse of what can apply.

  5. Chris Ziehr says:

    To the notion that we need to be open-minded and not make assumptions about processes, I wholeheartedly agree.
    But I’m not making an assumption; there ARE real differences in the requirements placed on different industries (aerospace, military, automotive vs. food & drug, vs. video games, anit-virus software) that DO necessitate differences in processes. These differences should not be ignored (can’t be, to be successful), but should be embraced. Companies dealing in a market space with greater external oversight and auditing requirements benefit from applications created on “lighter”, less expensive, and more flexible processes. They just may not be able to use the same process for their own developments.
    I would also add that none of my comments should be construed as implying that Subversion won’t work in a variety of environments. To the contrary, I work at a multi-billion dollar aerospace company, and we have found Subversion to fit easily within our processes and provide us with advantages over other tools we have used.
    But, we can’t assume this will be true for all tools and processes.
    Thanks for the discussion.

  6. Bob says:

    I also appreciate the discussion and think we are pretty much on the same page. You want to emphasize the differences while I’m advocating that assumed differences should be re-evaluated rather than suggesting none exist. I’ve consulted with all sorts of companies in all types of markets/industries in the past 11 years for both Rational and CollabNet, but found far less real requirements differences than simularities. I often find people who are closed minded about their belief in differences and that’s who I’m talking to.
    There can absolutely be different requirements caused by compliance requirements, organizational interactions, etc. Thus I said consider and use appropriately. To assume that practices can’t be utilized based on the source of those practices is what I’m saying is hard to justify.
    I can say that I haven’t found an environment where Subversion can’t work, but I have seen ones where it has to be supplemented to meet requirements. That should come as no surprise given that version control is not where the differences really come, but more in what is applied around it in the definition of software configuration management.

Leave a Reply

Your email address will not be published. Required fields are marked *