12

Edit: Given the recent downvoting (+8/-6 at this point) it was made clear to me that Gartner's lifecycle is a biased metric from a programmer's perspective. This is something that is part of a paper I'm going to present to management, and management types are part of Gartner's audience.

Giving DVCS exposure & enthusiasm (that "could" be deemed as hype, or at least attacked as such), think about the following question when reading this one: "how could I use Gartner's hype cycle to convince management that DVCSs are ready (or ready-enough) for us, and that it is not just hype"

Just asking if DVCSs is hype wouldn't be constructive, Gartner's hype cycle is a more objective instrument than just asking that (even if this instrument is regarded as biased). If you know any other instrument please, by all means, mention it.

Edit #2: I agree that Gartner's Life Cycle is not for every technology, but I consider it may have generated enough buzz to be considered hype by some, so it maybe deserves to be at least evaluated/pondered as such by using this instrument in order to prove/disprove it to whatever degree. I'm an advocate of DVCS, BTW.

Edit #3: Thanks for your answers. Bounty goes to Caleb for answering my question with detail and practical advise. Accepted answer goes to philosodad for providing another useful instrument and answering beyond my question.

I'm doing research for a whitepaper I'm writing in favor of DVCS adoption at company and I stumbled upon the concept of social proof. I want to prove that the social proof of DVCS adoption is not necessarily cargo cult and doing further research I now stumbled upon Gartner's hype cycle which describes technology maturity in 5 phases.

enter image description here

My question is: what could be an indicator of the current location of Distributed Version Control Systems (I mean git, mercurial, bazaar, etc. in general) at a particular phase in the hype cycle?... in other (less convoluted) words, would you say that currently expectations of DVCSs are a) starting, b)inflated, c)decreasing (disillusionment), d)increasing (enlightenment) or e)stabilizing (mature) and (more importantly) why?

I know it is a hard question and there is subjectivity involved, but I'll grant the answer (and the traditional cookie) to the clearest argument/evidence for a particular phase.

dukeofgaming
  • 13,943
  • 6
  • 50
  • 77
  • 1
    at **[more than 10 years](http://en.wikipedia.org/wiki/TeamWare "TeamWare DVCS has been there before Y2K")**, it has to be at "Plateau of Productivity" per that artificial scale – gnat May 26 '12 at 04:46
  • @gnat: I agree 100%! Back in 2000, when I worked at Sun I used SCCS/Teamware, which got it right. I scratched my head wondering how anyone could possibly like CVS. Linus Torvalds thought the same, and stuck with BitKeeper until he made Git. It's CVS/SVN that had the unnecessary hype! – Macneil May 26 '12 at 05:03
  • @Macneil well per my recollection, CVS/SVN were capable of running on Windows and Linux, while TeamWare/SCCS has been locked in Solaris filesystem (at Linux it run more or less, if one knew how to hack over spurious "zero checksum" bugs). Not that I mean one or other is better, just adding some facts – gnat May 26 '12 at 05:09
  • 7
    The time scale on the chart doesn't seem to relate to time since original introduction. Just for example, "Wireless power" is shown toward the left side even though Tesla did it in the 1890's and even if we restrict it to high tech/computer kinds of things, passive RFID tags have been using it for quite a while too. – Jerry Coffin May 26 '12 at 06:18
  • @gnat: Time doesn't mean anything here. Any given technology may stay forever on a specific stage, and even die there. – CesarGon May 26 '12 at 12:50
  • +1 Excellent question. I've always wondered why all the fuss about DVCS. My intuition says they are probably right past the peak of inflated expectations, but I don't have arguments to defend that as a proper answer. Looking forward to people's replies though. – CesarGon May 26 '12 at 12:56
  • Why all the downvoting? – dukeofgaming May 28 '12 at 19:00
  • The trouble with the "hype cycle" used to determine "where a technology is" is that it implies that all technologies are equally worthwhile. It says more about how people view technologies then whether they are worth adopting. Where would you put "http" on that chart? Was there ever a "trough of disillusionment" for html? – Gort the Robot May 29 '12 at 00:19
  • @StevenBurnap Well, AFAIK, there was never hype about HTTP, it just started to pick up organically, which I think is not the case with DVCS. – dukeofgaming May 29 '12 at 00:26
  • You can't extirpate the hype around HTTP from the hype around the Web. Http, by enabling the web, was going to change absolutely everything about everything overnight. Then came the .com crash. I think it is a mistake to confabulate hype with organic/inorganic adoption. Hype is how a thing is being talked about, adoption is how many people are using a thing. The people using a DVCS are the people benefitting from using VCS, and this adoption seems quite organic from here. – philosodad May 29 '12 at 17:16
  • Looking at your task, I would definitely use the adoption curve in Rogers rather than the hype cycle to talk to management. We're seeing a lot of hype because we're in a period of rapid adoption, and we're in a period of rapid adoption because development teams are finding this useful and telling other programming teams about it. Which generates hype. – philosodad May 29 '12 at 17:19
  • Why are you using the "Hype Cycle" model to time your adoption of DVCS technology? I concur that it is a good model to help combat and reduce your own behavioral biases, and to help gain objectivity in your decision making process, but it would be a mistake to only adopt a technology once a consensus opinion has been formed. Competitive advantage comes from being able to step back, understand your own biases, and use that understanding to make decisions both faster and more rationally than your competitors. Come up with your own criteria. Use **them** to make an informed decision. – William Payne May 30 '12 at 20:42
  • @WilliamPayne Could you add that to your answer and elaborate on the criteria you would use?. I can address your question better after that :) – dukeofgaming May 30 '12 at 21:06
  • @dukeofgaming - I have modified my answer as you requested, but it is difficult to identify relevant factors without some information about the nature of the development work you are currently engaged in: I.e. Embedded? Safety Critical? Websites? Enterprise Applications? Consumer software? Academic? What kind of environment are you working in? Open Source / Community development? Startup? SME? Large Corporation? Government? – William Payne May 30 '12 at 22:52

4 Answers4

15

I don't claim to be an expert on the subject of hype cycles, but I'll offer a few observations:

  1. The hype cycle seems to be more a product of expectations and media coverage than a characteristic of technology itself. My dictionary says that hype is "extravagant or intensive publicity or promotion." It defines publicity as "the notice or attention given to someone or something by the media." Media is a collective term for the various channels of mass communication.

  2. If you accept the previous point, it follows that the hype cycle applies only when the media covers a given technology.

  3. It's not at all clear that the hype cycle applies to all technologies. Scientific journals are filled with reports of advances which are never noticed by the mainstream media. Without media coverage, expectations are less likely to be inflated and the trough of disillusionment can be avoided.

  4. Distributed version control systems aren't so much a new idea as a refinement of an old one. It's a stretch to call them an "emerging technology" of the sort that the hype cycle is supposed to predict.

Before you start to build a case for where DVCS's fit on a hype cycle graph, you need to build a case that distributed version control is subject to the hype cycle at all. Does distributed version control as a "technology" get media coverage? Are there now, or have there ever been, inflated expectations for distributed version control? Is it likely that DVCS users will become disillusioned when DVCS products don't live up to expectations?

It seems more likely to me that distributed version control is just an improvement on an existing category of products, just as SVN was an improvement on CVS. If you were to chart the adoption rate of SVN, I don't think you'd get a plot that looks like the hype cycle; instead, you'd get a plot that increases steadily up to the plateau of market dominance, followed by a long slow decline as distributed systems like 'git' gain popularity.

If you really need a hype-cycle answer, I'd suggest that DVCS joined the game at the bottom of a period of disillusionment/frustration with non-distributed version control systems and has been climbing the slope of enlightenment as the adoption rate increases.

Instead of relying on the hype cycle for your argument, I'd suggest focusing on the adoption rate of distributed version control and the reasons for it. There's plenty of anecdotal evidence that people are switching to DVCS because it works; on the other hand, I haven't heard of anyone switching back to a non-distributed system because they were disappointed. To get some hard data, you might try talking to a hosting company such as Beanstalk. Also, pay attention to interoperability between centralized systems and distributed systems. I hear that 'git' plays very nicely with SVN. Centralized systems continue to work pretty well in the corporate realm, so emphasizing the "plays nicely with" aspect could make a DVCS less risky and therefore more attractive to decision makers.

Update in response to OP's edit:

how could I use Gartner's hype cycle to convince management that DVCSs are ready (or ready-enough)[?]

I think that there are a few approaches that could help here, and all rely on hard data:

Google Trends. Google obviously collects a ton of data about what's on the net and what people search for. A few days ago, I looked for (but couldn't find) evidence of the hype cycle w.r.t. distributed version control. http://trends.google.com/ says that there's not enough data for the terms dvcs or distributed version control when I limit the region to the US (and the dvcs results for the world don't seem very relevant or helpful). Searching for more specific terms was somewhat better, but complicated by the fact that product names like git and mercurial have other meanings (who knew?). The result for git shows a trend that might be due in part to the version control system:

git trend

Trying to make that more specific to version control, I tried git repository:

git repository trend

One more... figuring that if people are adopting git there ought to be an increasing trend in searching for help with git commands, I tried git pull (blue), git commit (red), and git rebase (gold):

git pull/commit/rebase trend

That last graph seems to provide the best evidence that people are adopting and using git.

Google search.

Try simply searching for terms like distributed version control and note the dates on, say, the top 25 articles you find. Plot the results. Most of top hits I found had dates in the 2007-2009 range. If the hype cycle applies, and if you can show that most of the media coverage happened 3-5 years ago, that seems like pretty good evidence that we've moved beyond the peak of inflated expectations.

Collect examples of projects that use DVCS.

There are plenty of examples in the open source world, including some big ones like Linux. (Linus Torvalds created git to help manage Linux development.) More useful to you will be examples of corporations that use a DVCS. (If there's anything managers hate more than adopting a technology too early, it's being behind the times.) Hype is just that -- buzz about a technology or product. If you can find evidence of corporate adoption of DVCS, that'll help counter the "it's just a lot of hype" argument perhaps better than anything else.

Last tips:

  • Be specific. Your company isn't going to adopt an entire technology -- you'll adopt a specific product. Some products are always going to be less mature than others. Pick two or three well-known DVCS products and show how each would fit into your development process. Managers like concrete ideas better than vague promises, so analyzing the tech in specific terms will make them feel more comfortable.

  • It's not all-or-nothing. Any real project using a DVCS is still going to have a central repository, so fears about losing control of the crown jewels can be easily assuaged.

  • No need to give up your current system. Some tools, like git, can play well with existing version control systems, like svn. So you can easily add DVCS to your development process without giving anything up.

  • Start small. Unless you're at a small company that has just one project, it ought to be easy to incorporate DVCS into the process for just one or two of your projects. You don't have to jump in head first -- just dip a toe.

In short, identify the points of resistance and address them as clearly as you can.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • It's maybe not media coverage as known, but I think Linus' git talk gave DVCSs good exposure (if you consider internet as media) http://www.youtube.com/watch?v=4XpnKHJAok8 – dukeofgaming May 26 '12 at 05:32
  • BTW, getting hard data from DVCS hosting sites its an excellent idea (+1 for that and questioning if DVCS can be considered in the cycle) – dukeofgaming May 26 '12 at 06:45
  • 1
    The hype cycle applies in all but a few degenerate cases, even where not reported by the media. The cases where it doesn't are where there is never initial adoption (stillborn tech) and where the trough of disillusionment hits zero (often due to the tech being superseded by something wholly better). – Donal Fellows May 26 '12 at 14:15
  • 2
    When was the "trough of disillusionment" for the web browser? – Gort the Robot May 29 '12 at 00:20
  • 1
    @StevenBurnap Was the browser hyped at any moment? (genuine question) – dukeofgaming May 29 '12 at 01:47
  • @StevenBurnap, when non-IE browsers were picking up but many sites were still "optimised for IE"? – Peter Taylor May 29 '12 at 15:25
  • The web browser reached its hype maximum during the .com boom, as the number of new adopters reached its max. It's impossible to disconnect the hype around the browser from the hype around the web itself... for most users, the two were indistinguishable at the time. – philosodad May 29 '12 at 17:10
  • @philosodad That's exactly the problem with saying something like Donal Fellows' statement that the hype cycle applies in (nearly) all cases: applies to what, exactly? To the web overall? To web browsers? To a specific web browser? To version control systems generally? To distributed version control? To git? There's no doubt that there are hype cycles, but what's being hyped isn't always clear. – Caleb May 29 '12 at 19:35
  • 1
    On the other hand, does the hype cycle apply to ANYTHING? Is there any actual research that supports this? As far as I can tell, the hype cycle is almost entirely about fitting the news pattern to something after the fact. It doesn't tell you anything about the future, the current state of a innovation, its curve of future change, or even if you should adopt it or not. – philosodad May 29 '12 at 23:55
  • It seems to my untutored eyes that the hype cycle is attempting to characterize the dynamics of human opinion formation, and as a result is only loosely coupled to adoption rates or technical maturity. It is perfectly possible for a very mature and widely adopted technology to gain sudden exposure to a new audience and to go through the "Hype cycle" with that new audience quite independently of any other technical characteristics. – William Payne May 30 '12 at 20:35
  • 1
    @WilliamPayne I'll grant that it's possible that some community could suddenly discover an existing technology, and that the media within that community might generate hype/buzz following the hype cycle pattern. I'd point out, though, that the chart in the OP's question is labelled "Hype Cycle for Emerging Technologies." Also, it's not enough to posit that such a thing *could* happen -- you really need to point to examples where that *has* happened. As philosodad points out, whether the hype cycle is real or just perceived is an open question. – Caleb May 30 '12 at 22:30
  • @Caleb -Well, given that some commentators have already pointed out that DVCS technologies have been around for 10 years (at Sun at least), it is possible that DVCS is such an example. The hype cycle conforms well to my intuitions about human nature, but it is not a Singleton - you need to identify and define the community that it describes. Different communities (or different parts of the same community) are likely to follow their own trajectories. Since the mass media create a well defined community, perhaps the cycle is (only?) well defined when the mass media are involved? – William Payne May 30 '12 at 22:42
  • @WilliamPayne The alleged hype cycle seems to be a product of the mass media (see the first point in my answer). I agree that it seems to reflect formation of opinions even on an individual level, but I don't think it's meant for that. Remember that it's something that Gartner came up with, and they're basically in the business of reporting on and predicting large-scale trends. – Caleb May 30 '12 at 23:34
  • @Caleb - I agree that, as a tool, it appears to be intended for use in situations where mass opinion is driven in concert by mass media. Today, however, the media landscape is rather more fragmented and the analysis correspondingly more complex. – William Payne May 31 '12 at 00:40
5

The hype cycle measures the amount of news/buzz that a particular thing generates, not the actual use of the thing or it's actual productivity value. So... I would say that from that perspective, DVCS is reaching a spike in its news cycle. Enough people are actually using it and encouraging other people to use it that it is getting a lot of buzz in the tech world. Once adoption is more widespread, I expect that news/buzz to fade a bit when something new and shiny comes along, and then rise again as people start to understand the systems more completely.

One way to look at the hype cycle is to look at the number of new adopters. The number of new adopters of a technology tends to follow the same exact curve shape as the hype cycle. It makes sense that the buzz around a given new technology is going to grow rapidly as the technology gains a large number of new adopters. The early adopters spread the innovation, and the middle adopters generate the buzz.

The buzz during rapid adoption of an innovation is neccessarily poorly informed. If there are a lot of people who know of something but don't know about it, they are going to have different and possibly greater expectations than experienced users. So that's where the hype comes from.

The buzz after the rate of adoption has peaked is going to fall off... partly because earlier, unrealistic expectations have not paid off (DVCS will make you more productive, perhaps, but it won't fix all your problems) and partly because something else is going through a rapid adoption period and is taking up all the mindshare. Hype is fickle.

But at some point, you start getting a fairly constant rate of new adopters, the innovation has become the norm, and the new adopters want to know how to use this thing that they've already decided they need to use. Then the buzz around the innovation is all about what people actually are doing with it now that they are using it, rather than what they could do with it if they were using it.

So if you took the hype curve and put it next to the S-Curve of adoption rates (See Everett Rogers "Diffusion of Innovations") you would expect the hype to peak where the S-curve is steepest, trough as the S curve changes direction, and rise again as the innovation reaches its full market saturation.

DVCS is in a period of rapid adoption, so we're probably somewhere around the peak of the hype cycle.

philosodad
  • 1,775
  • 10
  • 14
  • So, essentially you are saying that DVCSs could be at the peak because people are still preaching about it?, or rising again because it is getting understood better? – dukeofgaming May 28 '12 at 19:22
  • I would say that the potential pool of adopters is still large, so there's a lot of curiosity and new, excited users. If you look at the S-Curve in Rogers "Diffusion of Innovations", DVCS is, I think, on the steep part--it's rapidly being adopted. This rapid adoption generates hype in news/buzz. As adoption saturates, hype decreases. The thing is now old news. Then, when adoption becomes the norm, news and buzz become more about what people are actually doing, rather than what they could do. – philosodad May 29 '12 at 16:51
  • 1
    philosodad, could you ellaborate on this as part of the answer? – dukeofgaming May 29 '12 at 17:04
  • @dukeofgaming I've modified my answer to elaborate on that point. – philosodad May 29 '12 at 17:12
2

argument/evidence of a particular phase

Whatever phase could that be, it has to be one that matches the fact that technology is in professional use for "more than 10 years", since distributed VCS TeamWare has been there for more than that: pdf User's Guide referred below is dated July 2001.

Per Wikipedia, TeamWare's largest deployment was inside Sun itself, where (bar a few exceptions) at one point it was the only VCS used - that makes thousands developers using the tool. TeamWare has been used to manage Sun's largest source trees, including those for the Solaris operating system and the Java system.

https://i.stack.imgur.com/J68MH.png

Wikipedia article refers to a Usenix message from Evan Adams, who was the architectural lead for TeamWare, which states in particular:

In the spring of 1991 we decided to implement the TeamWare project...

TeamWare is a set of command line and GUI tools built from several common libraries. The libraries are provided by the TeamWare group for use by the TeamWare applications; they are not provided for more general use.

TeamWare is a code management product that encourages parallel development and is built on top of SCCS. A user makes a copy (bringover) of an SCCS hierarchy thus creating a personal hierarchy. In this hierarchy the user makes and tests changes. These changes are then integrated (putback) into the original hierarchy. If the integration hierarchy contains changes which are not in the user's hierarchy, then TeamWare detects that there have been parallel changes and refuses the integration. Therefore, users must incorporate changes in the integration hierarchy into their own hierarchy before integrating. TeamWare also includes the filemerge utility, a graphical three-way differences program allowing users to merge parallel changes. TeamWare tracks both source file changes (SCCS deltas) and file renames...

If you're interested, find more details here:

Per my recollection, centralized CVS / SVN back then had an advantage of being capable to run on Windows and Linux, while TeamWare (SCCS) has been locked in Solaris filesystem (at Linux it run more or less, if one knew how to hack over spurious "zero checksum" bugs).

gnat
  • 21,442
  • 29
  • 112
  • 288
  • 4
    There are technologies of 10+ years before the peak of inflated expectations. I'm not sure time alone can position a particular technology at a phase. – dukeofgaming May 26 '12 at 05:26
  • @dukeofgaming well **more than 10 years is an objective fact** and I state just it. Whatever subjective "phase" / "hype-measure" would be stuffed over it, the fact has to be there – gnat May 26 '12 at 05:49
  • 1
    Sorry, I still don't get your point. If I understand correcty you are saying ~10 years are an objective fact, but for what phase? – dukeofgaming May 26 '12 at 06:02
  • my point is, DVCS technology is in professional use for more than 10 years. As for whatever subjective phase one could possibly infer from it, I have no idea – gnat May 26 '12 at 06:24
  • Hmm, I'd argue that real attention towards DVCSs could've started with BitKeeper and not TeamWare. Although I get your point now, if it wasn't for BitKeeper (circa 1999), Git & Mercurial (circa 2005), Bazaar (circa 2007), distribution in VCS wouldn't had started to be popular IMHO... unless TeamWare was greatly adopted and buzzed around (i.e. hyped)? (I don't know about this) – dukeofgaming May 26 '12 at 06:42
  • well per Wikipedia, "TeamWare's largest deployment is inside Sun itself, where (bar a few exceptions) at one point it was the only VCS used. TeamWare has been used to manage Sun's largest source trees, including those for the Solaris operating system and the Java system..." - decide for yourself if that counts as great adoption – gnat May 26 '12 at 07:09
  • -1 The fact that a technology has existed for a long time doesn't automatically position it on an advanced hype cycle stage. Some technologies are "slower" than others at maturing. Some die before reaching the plateau of productivity. – CesarGon May 26 '12 at 12:54
  • @CesarGon your reasoning appears based on premise that technology maturity can be defined only in context of [Hype cycle](http://en.wikipedia.org/wiki/Hype_cycle). Feel free to correct if I misunderstood – gnat May 28 '12 at 10:47
  • 1
    @gnat: Well, I think that "Hype Cycle" is a big misnomer. The Hype Cycle is not about hype but technology maturity. Hype is just a consequence of a technology being much talked about but not mature enough; the cycle shows this *but also* other aspects, such as adoption. So, in summary, I am taking the Hype Cycle for what it portrays wrt maturity rather than hype, hype being just a minor issue. – CesarGon May 28 '12 at 13:43
  • @CesarGon I don't follow sorry. More than 10 years ago, DVCS has been used by thousands developers in projects like Solaris OS and Java system - what other facts one would need to conclude on technology maturity? – gnat May 28 '12 at 14:58
  • 3
    @gnat: I don't deny DVCS' merit in that respect. But the Hype Cycle model assesses maturity plus expectations together; a technology may be quite mature, but if expectations about it are extremely high, it can still be disappointing (hence disillusionment). In my opinion, the expectations about DVCS have been way higher than what it has delivered. In addition, DVCS may have been used in Solaris and Java projects, but that does not mean that its maturity and expectations are balanced. Hence high hype. – CesarGon May 28 '12 at 18:08
1

My Answer:

I think that the answer lies somewhere between "Internet TV" and "Cloud Computing" on the rising shoulder of the "Peak of Inflated Expectations" (Although I think that both of these have moved on somewhat rapidly in the past couple of years).

Nature of the Hype Cycle:

As I understand it, progression through the hype cycle is characterized by an evolving awareness about the pros and cons of a particular technology, rather than by any objective measure of "maturity" (whatever that means).

Before we have accumulated a sufficiently diverse set of experiences to build balanced (and independent) opinions, crowd dynamics (naturally) hold sway, with highly correlated opinions with little diversity, subtlety or depth of analysis.

This is as true in the "Trough of Disillusionment" as it is in the "Peak of Inflated Expectations"

If the community were to produce a wide and diverse range of different opinions, with in depth analysis about where and when it is appropriate to deploy DVCS and where and when it is not, then we can infer we are in the "Plateau of Productivity" (Or at least some way up the "Slope of Enlightenment").

If, on the other hand, the discourse is focussed on the superiority (or otherwise) of a technology without regard to the dips and folds of the competitive landscape upon which it stands, then we might infer that we are either on the "Peak of Inflated Expectations" or the "Trough of Disillusionment". We could even be in both phases at the same time, if the community is divided into camps by a flame war.

:-)

Evaluation of DVCS according to these criteria:

From the relatively shallow analysis that I have seen in the discourse so far, and the relative absence of negative commentary, I would estimate that we are currently climbing the "Peak of Inflated Expectations", with questions (such as this one) indicating that there are some who are preparing the slope down on the other side.

I think a strong indicator of the maturity of DVCS technology (from a corporate standpoint) will be when the debate shifts from asking simply "Why DVCS?" to "How can we best structure our workflow and processes around DVCS to maximise benefit to the organisation?".

From what I have seen, we are not all there yet. (Although some of our more sophisticated compatriots are leading the way)

The role of the Hype Cycle in decision making:

The "Hype Cycle" model is a model of behavioral bias, and it helps us understand our own mental state. If we can determine that a technology is hyped by others, then that may affect our own mental stance, and (at the risk of some double-think) we may need to compensate accordingly and force ourselves to behave rationally in choosing our selection criteria.

Selection Criteria:

Needless to say, selection criteria choices are extremely context dependent.

Personally I would do (as a sort of brainstorming exercise) a short (15 minute) SWOT analysis of each option that you are considering, together with (seriously) a PEST analysis of the situation to ensure that you bring broader (non-technological) factors in your analysis.

SWOT for Distributed VCS

Strengths:

  • Flexibility - more freedom to choose different workflows.
  • Better performance over low-bandwidth/high-latency network connections - better for distributed teams & off-site workers.
  • More sophisticated merge functionality, allowing you to branch more often. (I am not sure that this is a good thing).
  • Source code is "backed up" on each developers machine. (pretty bogus, this one, as it might interfere with proper disaster recovery planning)

Weaknesses:

  • Flexibility - Because we have more freedom to choose different workflows, we need to do additional work to define which workflow we are using, and to enforce it.
  • Complexity & Conceptual Difficulty (especially for non-software-developer team members).

Opportunities:

  • Perhaps the flexibility can be utilized to engineer a workflow that is better suited to business needs?

Threats:

  • Perhaps we will spend so long re-engineering our workflow we will loose focus on our core product?
  • It can be difficult to get some people to use even simple tools, especially if they do not believe that they are necessary or are otherwise not motivated.

SWOT for Centralized VCS

Strengths:

  • Provides an in-band implicit communications channel for business organisation & process.
  • Restricts possible workflows to a (in many cases reasonable) subset.
  • Makes it easier to set up CI & other development automation tools.
  • (SVN specific) Supports huge repositories.
  • (SVN specific) Very stable, used by lots of big, conservative organisations.
  • Politically more acceptable in a top-down command & control organization?

Weaknesses:

  • Inflexible.
  • Poor performance over low-bandwidth / high-latency connections, making it harder to use for distributed teams and off-site workers (especially if the repository gets big)

Opportunities:

  • Perhaps we can use the monolithic nature of the repository to help developers navigate the product and reuse each other's code more?

Threats:

  • If the project suddenly becomes hyper-important and we need to bring in additional developers working on other sites, can they effectively work with a SVN repository hosted (for them) off-site?
  • If the set of developers grows so large that coordinating them becomes difficult, will the single centralized repository become a bottleneck? (Can we get around this any other way?)

Conclusion:

Which VCS to use is dependent upon individual circumstance. For many of the situations in which I have worked, a DVCS with a centralized workflow would have done just fine, but I would have had to justify the time & effort to build out mechanism to support and enforce workflow, which would have been (still is) difficult.

Ultimately, I think that the discussion should center around the question: What workflow best suits our business? The best tool to use should follow naturally from the answer to that question.

William Payne
  • 1,161
  • 8
  • 20