Version Control and “the 80%”

This entry was posted by on Tuesday, 16 October, 2007 at

11/17/07: Before posting an angry comment about this post, please see the follow-up post!

Disclaimer: I’m going to make some crazy sweeping generalizations — ones which are based on my 12 years of observing the software development industry. I’m aware that I’m drawing some oversimplified stereotypes, but I think most of my peers who work in this industry will nod their head at some point, able to see the grains of truth in my characterizations.

Two Types of Programmers

There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%.

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90′s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.

Shocking statement #1: Most of the software industry is made up of 80% programmers. Yes, most of the world is small Windows development shops, or small firms hiring internal programmers. Most companies have a few 20% folks, and they’re usually the ones lobbying against pointy-haired bosses to change policies, or upgrade tools, or to use a sane version-control system.

Shocking statement #2: Most alpha-geeks forget about shocking statement #1. People who work on open source software, participate in passionate cryptography arguments on Slashdot, and download the latest GIT releases are extremely likely to lose sight of the fact that “the 80%” exists at all. They get all excited about the latest Linux distro or AJAX toolkit or distributed SCM system, spend all weekend on it, blog about it… and then are confounded about why they can’t get their office to start using it.

I will be the first to admit that I completely lost sight of the 80% as well. When I was first hired by Collabnet to “design a replacement for CVS” back in 2000, my two collaborators and I were really excited. All the 20% folks were using CVS, especially for open source projects. We viewed this as an opportunity to win the hearts and minds of the open source world, and to especially attract the attention of all those alpha-geeks. But things turned out differently. When we finally released Subversion 1.0 in early 2004, guess what happened? Did we have flocks of 20% people converting open source projects to Subversion? No, actually, just a few small projects did that. Instead, we were overwhelmed with dozens of small companies tossing out Microsoft SourceSafe, and hundreds of 80% people flocking to our user lists for tech support.

Today, Subversion has now gone from “cool subversive product” to “the default safe choice” for both 80% and 20% audiences. The 80% companies who were once using crappy version control (or no version control at all) are now blogging to one another — web developers giving “hot tips” to each other about using version control (and Subversion in particular) to manage their web sites at their small web-development shops. What was once new and hot to 20% people has finally trickled down to everyday-tool status among the 80%.

The great irony here (as Karl Fogel points out in one of his recent OSCON slides) is that Subversion was originally intended to subvert the open source world. It’s done that to a reasonable degree, but it’s proven far more subversive in the corporate world!

Enter Distributed Version Control

In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny.

And what’s not to love about DVCS? It is really cool. It liberates users, empowers them to work in disconnected situations, makes branching and merging into trivial operations.

Shocking statement #3: No matter how cool DVCS is, anyone who tells you that DVCS is perfect for everyone is completely out of touch with reality.

Why? Because (1) DVCS has tradeoffs that are not appropriate for all teams, and (2) DVCS completely blows over the head of the 80%.

Let’s talk about tradeoffs first. While DVCS dramatically lowers the bar for participation in a project (just clone the repository and start making local commits!), it also encourages anti-social behavior. I already wrote a long essay about this (see The Risks of Distributed Version Control). In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work; in a decentralized system, the default behavior is for each developer to privately fork the project. They have to put in some extra effort to share code and organize themselves into some sort of collaborative structure. Yes, I’m aware that a DVCS is able to emulate a centralized system; but defaults matter. The default action is to fork, not to collaborate! This encourages people to crawl into caves and write huge new features, then “dump” these code-bombs on their peers, at which point the code is unreviewable. Yes, best practices are possible with DVCS, but they’re not encouraged. It makes me nervous about the future of open source development. (Maybe the great liberation is worth it; time will tell.)

Second, how about all those 80% folks working in small Windows development shops? How would we go about deploying DVCS to them?

  • Most DVCS systems don’t run on Windows at all.
  • Most DVCS have no shell or GUI tool integrations; they’re command-line only.
  • Most 80% coders find TortoiseSVN full of new, challenging concepts like “update” and “commit”. They often struggle to use version control at all; are you now going to teach them the difference between “pull” and “update”, between “commit” and “push”? Look me in the eyes and say that with a straight face.
  • Corporations are inherently centralized entities. Not only is their power-structure centralized, but their shared resources are centralized as well.
    • Managers don’t want 20 different private forks of a codebase; they want one codebase that they can monitor all activity on.
    • Cloning a repository is bad for corporate security. Most corporations have an absolute need for access control on their code; sensitive intellectual property in specific parts of the repository is only readable/writeable by certain teams. No DVCS is able to provide fine-grained access control; the entire code history is sitting on local disk.
    • Cloning is often unscalable for corporations. Many companies have huge codebases — repositories which are dozens or even hundreds of gigabytes in size. When a new developer starts out, it’s simply a waste of time (and disk space) to clone a repository that big.

Again, I repeat the irony: Subversion was designed for open source geeks, but the reality is that it’s become much more of a “home run”for corporate development. Subversion is centralized. Subversion runs on Windows, both client and server. Subversion has fine-grained access control. It has an absolutely killer GUI (TortoiseSVN) that makes version control accessible to people who barely know what it is. It integrates with all the GUI IDEs like VS.NET and Eclipse. In short, it’s an absolute perfect fit for the 80%, and it’s why Collabnet is doing so well in supporting this audience.

DVCS and Subversion’s Future

Most Subversion developers are well aware of the cool new ground being broken by DVCS, and there’s already a lot of discussion out there to “evolve” Subversion 2.0 in those directions. However, as Karl Fogel pointed out in a long email, the challenge before us is to keep Subversion simple, while still co-opting many of the features of DVCS. We will not forget about the 80%!

Subversion 1.5 is getting very close to a release candidate, and this fixes the long-standing DVCS criticism that “Subversion merging is awful”. Branching is still a constant-time operation, but you can now repeatedly merge one branch to another without searching history for the exact arguments you need. Subversion automatically keeps track of which changes you’ve merged already, and which still need merging. We even allow cherry-picking of changes. We’ve also got nice interactive conflict resolution now, so you can plug in your favorite Mercurial
merging tool and away you go. A portable patch format is also coming soon.

For Subversion 2.0, a few of us are imagining a centralized system, but with certain decentralized features. We’d like to allow working copies to store “offline commits” and manage “local branches”, which can then be pushed to the central repository when you’re online again. Our prime directive is to keep the UI simple, and avoid the curse of DVCS UI (which often have 40, 50, or even 100 different commands!)

We also plan to centralize our working copy metadata into one place, which will make many client operations much faster. We may also end up stealing Mercurial’s “revlog” repository format as a replacement for the severely I/O bottlenecked FSFS format.

A Last Plea

Allow me to make a plea to all the DVCS fanatics out there: yes, it’s awesome, but please have some perspective! Understand that all tools have tradeoffs and that different teams have different needs. There is no magic bullet for version control. Anyone who argues that DVCS is “the bullet” is either selling you something or utterly forgetting about the 80%. They need to pull their head out of Slashdot and pay attention to the rest of the industry.

Update, 10/18/07: A number of comments indicate that my post should have been clearer in some ways. It was never my intent to say that “Subversion is good enough for everyone” or that “most of the world is too dumb to use DVCS, so don’t use it.” Instead, I’m simply presenting a checklist — a list of obstacles that DVCS needs to overcome in order to be accepted into mainstream corporate software development. I have no doubt that DVCS systems will get there someday, and that will be a great thing. And I’m imploring DVCS evangelists to be aware of these issues, rather than running around thoughtlessly trashing centralized systems. :-)

115 Comments to Version Control and “the 80%”

  1. jackr says:

    October 16th, 2007 at 2:07 am

    One other 80/20 thing: open source projects tend to have a much higher proportion of “20%ers” than companies do. The reason should be obvious, or rather the many reasons:
    – OSS communities reward merit, value of contribution, excellence — you know, the 20% stuff
    – 80%ers tend not to view programming as entertainment, 20%ers do, and many work on OSS because they’re not getting enough entertainment in their day jobs
    – 80%ers have a life, and, well … ;-)

    OSS communities are largely voluntary associations. The rewards appeal to the 20%, not to the 80%. So, OSS communities actively self-select for the 20s.

    Which helps to explain why so many OSS projects are “80%er-hostile.”

  2. A Reminder to the 20% to Pull Your Head Out of Slashdot « John Bracken says:

    October 16th, 2007 at 6:36 am

    [...] October 16, 2007 Lately I’ve recoiled at attempts to use the software industry as a metaphor for online behavior by the rest of us, but Ben Collins-Sussman’s Version Control and “the 80%” post has given me pause.  (Ben is renowned as one of the original developers of Subversion, which I’m told is a [the?] leading version control system.) [...]

  3. Borek says:

    October 16th, 2007 at 7:13 am

    Very good and insightful read – and I totally agree with you.

    Borek

  4. Eric H says:

    October 16th, 2007 at 7:31 am

    Brilliant as usual

  5. webmat says:

    October 16th, 2007 at 5:58 pm

    Great article! Lots of good points.

    I’m currently using bazaar here and there at work (locally on my PC, not officially). I have been known to mildly advocate DVCSes to my coworkers (just explaining what it is and some advantages, mainly). I have to admit that you’re right: I often get “what do I care?” looks :-)

    Hearing what’s in store for SVN, I can’t wait to see the next versions. You’re right in saying that it’s much easier to grasp for the 80% programmers, which is a great thing. I like the fact that some of the things I love about DVCSes are going to make it in SVN :-)

    In your article you mention tools having hundreds of commands. You obviously given Git a try :-) It also scared me away for that reason. However I strongly suggest you give a quick look at either Mercurial or Bazaar. I’ve used them both and the amount of commands for each fits on one page. They’re a breeze to use, altough yes, they are command-line for now. Although I’m aware that there is a TortoiseBzr in the works (or maybe even available, I haven’t tried it yet).
    http://bazaar-vcs.org/TortoiseBzr

    Oh, Mercurial and Bzr work like charms on Windows.

  6. Colin Barrett says:

    October 16th, 2007 at 6:16 pm

    I thought your language was a little confusing — you seemed to be were talking about DVCSes in general (and conceptually), but many of your criticism were in fact of the current spread of DVCS technologies and systems that exist today.

    Your points largely spot on, though. I do think that it’s not totally a fair comparison though — AFAIK none of the DVCS tools out there are even 1.0, and many are changing very rapidly.

    I do object to one specific point though: “With a centralized system, people are forced to collaborate and review each other’s work”. No they’re not. People just check in and ignore everyone else anyway. This happens /all the time/, at least on our project, maybe we just suck (you know Augie, right? Ask him about Evan). A centralized system simply forces you to share your changes if you want to version them. You shouldn’t have to make that tradeoff.

    To end on a positive note, my biggest headache right now with svn is how fuzzy the concept of “branch” is. I was just thinking how much I really wish you guys had a DAG, and then you mention adopting RevlogNG! That’d be awesome.

  7. Ben Collins-Sussman says:

    October 16th, 2007 at 7:18 pm

    Hi Webmat,

    The ‘hundreds of commands’ reference was actually a reference to Bitkeeper, though I heard that that Git has similar problems. :-)

    I’m already a mercurial user, and I like it a lot — very usable.

  8. Ben Collins-Sussman says:

    October 16th, 2007 at 7:24 pm

    Replying to Colin:

    I’m aware that I’m criticizing DVCSes which are (barely) 1.0 technologies. I have no doubt that they’ll get better over time, and that many of my criticisms will be fixed. On the other hand, I’m mainly responding the fanatical evangelists of DVCS; I’m trying to get them to be aware of these current flaws, and why DVCS is still mostly inaccessible to “the 80%”.

    If you have people using a centralized repository that are blindly clobbering other people’s changes… then you have a serious social problem. :-) The fact that it’s centralized just makes you more acutely aware of the problem, since a few people tend to spoil the public well for everyone, rather than spoiling their own private well.

    Not sure I understand your “branch” complaint… the subversion filesystem *is* DAG, in fact. That’s why copying a directory (making a tag or branch) is a constant-time operation: it’s just making a new hard-link to an existing inode in the DAG. There’s a whole layer in the repository that covers up the DAG, trying to make it look like a normal filesystem.

  9. Colin Barrett says:

    October 16th, 2007 at 8:11 pm

    Responding to fanatics and such legitimizes them. Don’t let them get under your skin, or address any logical flaws in their arguments calmly. I feel your pain though (“Firefox will never look good on the Mac because it is cross platform”).

    You know Augie Fackler, right? Ask him about Adium. He’ll tell you all about build breakages and stuff (people are better, but yeah…)

    The problems, at least for me are (and you can see all these in the Adium repository):

    – People committing to multiple branches in the same commit
    – Multiple hierarchies in branches/ (ex: branches/summer_of_code_2006/student_name/)
    – Copies of things other than trunk/ in branches/ (ex: branches/ChangeLog/changelog.txt)

    All of this makes automated tools for looking at history go absolutely crazy. It’d be nice to enforce some invariants there :\ Again, social problems, but as you said, defaults matter.

    The concept of a versioned file system is cool and all, but lets enforce some invariants here, or something…

  10. Colin Barrett says:

    October 16th, 2007 at 8:14 pm

    s/skin, or/skin, and/

  11. Kalid says:

    October 16th, 2007 at 8:38 pm

    Great article. I recently wrote about regular VCS and DVCS systems, aimed at newbies (of which I am for DVCS). In my view, *any* VCS is a good VCS given that most people in the 80% aren’t using anything. I found the arrogant “DVCS are better, fool!” quite off-putting as well.

    Keep up the good fight — introducing people to new tools is a crawl/walk/run process :)

  12. dextrous says:

    October 16th, 2007 at 8:57 pm

    Good walk through, from long time, I wanted it to say same thing to fanatics who are so obssessed with them selves that they are not even bother about others.
    I fully agree with you that DVCS might be good for some project but not all, this fact has to be realized, as I use subversion I know what it is capable of and its not as bad as it was qoted by some fanatic freaks.

  13. Distributed Version Control for the Other 80% - Kyle Cordes says:

    October 16th, 2007 at 9:26 pm

    [...] Ben Collins-Sussman, one of the key developers behind Subversion, argues in Version Control and the 80% that distributed version control will remain a niche interest, and will not move in to the mainstream (as his favorite tool certainly has). He has a number of good reasons to back up this thesis. [...]

  14. share reading in October « Robot Brain says:

    October 16th, 2007 at 9:44 pm

    [...] 2. Version Control and the “80%” [...]

  15. Why I HAVE to use Git from now on... — Josh Kim dot Org says:

    October 16th, 2007 at 10:09 pm

    [...] EDIT: Version Control and “the 80%” [...]

  16. TunnelRat says:

    October 16th, 2007 at 10:23 pm

    I gotta admit, I am in the 80% and totally agree with Shocking statement #2. I know Microsoft and nothing else — its been that way for 15 years. That goes for VSS. I just started a freelance ASP.NET gig and my DBA buddy wanted to use Suberversion. I said no f-ing way. I had to admit, I never heard of it.

    But why bother? I been using version control since PVCS. And VSS is the defacto standard among the enterprisy 80%. It even shows up on job reqs.

    There is no silver, no cool tool to handle a large project with a lot of developers checking stuff in. IMHO, merging and branching doesn’t work well, and exclusive checkouts are the way to go. That means you need good team leads and configuration managers to sort out the bs. Code reviews, continious integration, and discipline are what it takes.

    But if it has a VisualStudio plug-in, maybe even I’ll try it. But you can have all that LAMP, Ruby, Lisp stuff — I have bills to pay.

  17. zach says:

    October 16th, 2007 at 10:37 pm

    Interesting take on the adoption of version control and an excellent summary of why large corporations will be slow to adopt DCVS, but I’m a little put off.

    I am shocked by shocking statement #1. Am I that naive, or is 80% of our industry really as characterized? Just because they’re vocational (I’m willing to accept this part of the premise) doesn’t mean that they’re bad at their job — version control and a working Linux abilities are vital tools for a programmer.

    And why lump Eclipse in the “bad / clueless practice” category? I run eclipse — on Linux — and am continually amazed at how much it aids my development. It’s got built-in refactoring tools, great debugging (including remote jvms), and it dramatically automates much of the boilerplate java forces you to write. If you are developing Java, you have either a) Eclipse or another IDE with the features named, b) deep, deep black magic macro skills with your text editor, or c) something wrong with you.

    Yes, I’m relatively new to the field. Maybe if I had an additional decade of experience under my belt I would agree with the 80% summary, but there is no way on earth 80% of the developers where I work are so ignorant of best practice. Seeing the agreement in the comments above, I’m forced to conclude that the hiring bar is a lot higher than average where I work, because if you don’t know how to use version control and dig through a directory on Linux with your shell, you are not getting hired.

    Thanks again for the interesting article.

    zach

  18. zach says:

    October 16th, 2007 at 10:45 pm

    Dangit, just read the comment above mine.

    Very saddened,

    zach

  19. Chris Smith says:

    October 17th, 2007 at 12:48 am

    After thinking about this for a while, I think there’s a confusion between technology and policy here. The confusion exists on both sides of the fence. Distributed version control systems are a somewhat different technology; but it’s by no means true that they require different policy.

    I’d be willing to bet that among corporate software development using version control systems, there still exists one central repository that everyone thinks of as “the” code base. Certainly there is one where I work now. Similarly, I can think of no place I’ve ever worked with a traditional version control system where developers didn’t keep a working copy of the entire code base on their systems, and sync it up with the repository on occasion.

    There’s a good point here. This kind of organization exists for a reason, and it’s not just because everyone has adapted to the limitations of technology. Anyone preaching the gospel that we should no longer have a centralized code base is going to hit a wall. This is all too common among the DVCS community.

    Similarly, though, it’s incorrect to argue that distributed systems are not workable just because they aren’t tied to that policy decision. What needs to be said is that it’s entirely possible to reproduce that same policy decision while using darcs, for example, and everything still works fine. Sure, darcs doesn’t require that decision, but neither does darcs preclude it.

    Eventually, what I’m sure will happen is that businesses will cautiously pursue incremental changes to their policy decisions. Eventually, they’ll arrive at a sort of hierarchical arrangement of code repositories for large projects, which will fit the organization’s structure a little better than current centralized systems do. It remains true that a necessary component for this migration is that they adopt “distributed” systems (perhaps after the movement changes its name), because the change relies on the simple fact that using an organization-neutral VCS makes it easier to tweak the organization. One doesn’t have to wait for the software to catch up.

  20. Shanti Braford says:

    October 17th, 2007 at 1:49 am

    While it’s fun to play with new technologies, version control seems like one of those things you’d want to make sure was really well dogfooded (and that your data was consistently backed up / secure).

    One recent blog post about a startup said that they started out using git, without a central server, and started sharing the repo between two client machines. I’m sure 99.9% of the time this is perfectly alright, but for my paranoid self I prefer –

    central repository on a server that’s backed up regularly
    at least 2 checked out copies on different machines (at least one of which is not a laptop)

    But maybe I’m just being paranoid, or not fully understanding git / DVCS.

  21. Daniel Svoboda says:

    October 17th, 2007 at 1:53 am

    Unfortunately I am part of third category of programmers, and now I can’t clasify myself, because there is no percentage left for me in your description. Looks like I don’t even exist.

  22. Mark says:

    October 17th, 2007 at 2:03 am

    The biggest problem in Subversion I encounter roughly weekly with the 80% crowd, is the fact that version control information is stored separately for each directory. They keep renaming (or more often, deleting) the directories and they get themselves into a mess. Git is better here because it has one directory for meta data.

    git is a non-starter for them due to a complicated mental model
    (index, git-commit -a, and related). Merging/distributed is not a problem since most will not use any different than subversion (update/push)

    Mercurial sems nice, but seems less robust in behavior than svn.

  23. James says:

    October 17th, 2007 at 3:14 am

    I admit the 80% does exist – and they are not all programmers. I develop Flex and many of our assets are images, animations, movies and sounds. Plus XML configuration files. I’d love artists to use VCS but they have real trouble using SVN.

    Most of the complaints I saw in the Linus git video are around merging. He’s probably never used Perforce WinGui but that is sweet (note SVN devs: If you can match Perforce’s safe merge and auto-merge behaviours your most of the way there … in fact just become an open source Perforce clone, it is really the best). Really – auto merging files with no warning is brain-dead behaviour. Notify the user a merge is pending and allow them to sort it out at their leisure.

    I guess I’m in the 20% since yesterday I installed Mercurial and set up a test repository to give it a go. The merging seems similar to Perforce (warns before merge – auto merges – conflicts raised into graphic 3-pane merge app).

    Your claims are both founded and unfounded. I could put together a hierarchical process using DVCS where programmers push to leads, leads push to higher leads and so forth until it hits testing/release/etc. Breaking code into modules keeps confidential stuff confidential (e.g. check-out pre-built confidential modules and source section modules). In fact, I like the idea of not having to download large 3d source files and just having a pre-built place to pull from. Leads become responsible for aggregating and reviewing. It creates a responsibility chain that a central system does not have. Code escalation.

    Good comments though – SVN is the best popular free choice ;)

  24. Nikhil says:

    October 17th, 2007 at 5:26 am

    I totally agree about the 80/20 divide. But unfortunately the 80% guys will never read this post of yours, because the programming blogosphere is written and read only by the 20%, ;)

  25. Pierre THIERRY says:

    October 17th, 2007 at 7:39 am

    zach, you say “version control and a working Linux abilities are vital tools for a programmer”.

    While I would tend to agree (I couldn’t develop without version control and a powerful OS at hand), most of the IT industry would have been decimated for a long time if that was even remotely true.

    Most programmers probably don’t even understand the very basic notions of version control, not to speak about branching and merging, never learned regular expressions and a devent scripting language.

    They (sometimes) store regular snapshots of their code on CDs, search/replace is the most complex tool they’ll ever use when it comes to automatic code change and do a lot of basic file manipulatins by hand.

  26. Mike says:

    October 17th, 2007 at 8:08 am

    Hmm. The thing that pushed me to look at git in the first place was using Subversion for a few months and seeing how unpleasant it is. The whole ‘svn copy’/trunk/tags/branches thing is hard to use and hard to understand. For the unwashed 80%, I like RCS–it’s quite simple and handles the simple cases, which, as you say, are all that the 80% really need anyway.

  27. Jay says:

    October 17th, 2007 at 8:10 am

    What f..ing planet do you come from?

    “In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work;…”

    I have been in the IT industry for years and have _NEVER_ had a meaningful code review. Vey very rarely are people working on the kinds of projects where they need to collaborate to any great extent. A lot of businesses have a buy instead of build software mentality.

    This does remind me. I was working on a very large project to redo a order entry system. If the code I had written was wrong the company would not be able to ship product. When having a casual BS session with the manager of the project I mentioned that I though code reviews were a great idea and that are company should do them. I also mentioned that I had been at the company for 3 or 4 years and we had basically never done them. Guess what? I was the first person on the project to get a code review.

    I was fairly nervous and all about it. They scheduled the meeting. I printed out the 60 or 70 pages of code. They arrived at the meeting about ten minutes late. They didn’t get much past the fifth or six page. Done. Good to go. This is code that _had_ to be correct or we didn’t ship computers out the door.

    The place I am out now also has code reviews and we do them before we put anything into production. Guess what, I have never had to change anything as a result of the code review. As a matter of fact fairly often they are done by a person that may not even understand the technology I am working with.

  28. 20Percent says:

    October 17th, 2007 at 8:37 am

    “I just started a freelance ASP.NET gig and my DBA buddy wanted to use Suberversion. I said no f-ing way. I had to admit, I never heard of it.”

    What Microsoft tools are you using for Continuous Integration?

  29. Ben Collins-Sussman says:

    October 17th, 2007 at 8:59 am

    Jay: my comment about “being forced to collaborate and review work” was specifically about the impact of centralized repositories on *open source* projects. That’s a completely different culture from corporate software development, where code reviews almost never, ever happen. (You’re totally right about that — I’ve been there.)

  30. Jared says:

    October 17th, 2007 at 9:30 am

    I’m sort of one foot in, one foot out of the 80%. I do the vast majority of my programming in a platform agnostic language (Javascript.) Previously I programmed my sever side stuff in PHP, I wanted to learned Ruby but in order for me to learn Ruby I need a project to do so that is relevant to me, not just some hello world app. I’m currently in a Gig that uses vb.net as the back end. I wanted so bad to use SVN starting my project because I recognise the benefits of using a versioning system, but I’ve never used it before and when I installed it I had NO EFFIN CLUE what anything really meant. I don’t have time to read through a cryptic manual meant for the 20%, I need a simple tutorial that spoon feeds me the basics in a clear and step-by-step manner. I simply don’t have time to tinker and learn by trial and error like I used to.

    And like many things open source when you go to look for help you usually just find a hostile forum, or if you’re lucky an irc channel with nothing but idlers, but more likely a cob-webbed newsgroup (which usually precludes a great majority of the 80% ever even knowing it exists,) with nothing but a slew of unanswered questions by newbies like myself. Not exactly saying this is the case with SVN, but lets just say I’ve become disillusioned when it comes to looking for support on OSS projects. More OSS startups should model their support after Mozilla in my opinion, they have such an active support userbase on mozillazine, irc and newsgroups whatever your choice you’ll find a lot of mostly friendly people looking to help.

  31. Andrew Bettison says:

    October 17th, 2007 at 9:45 am

    I would say it’s more like 5% – 20% – 75%. The band in the middle are more or less competent, and may or may not actually enjoy their work. Five percent are well above competent, they are on about excellence in one way or another. Easily seventy percent are below competent, and don’t understand why the rest get so enthusiastic, and resent being treated like inferiors.

    This distribution is found in all professions and trades. Medicos, financial advisers, teachers, social workers, bureaucrats, law makers. Scary when you think about it.

    I remember once saying to some co-workers, while enthusing about the latest developments in interpreted languages (Python, Perl, Java, etc.), “If you don’t love the stuff, what are you doing here?” Blank looks. Left me in no doubt I was surrounded by 80%-ers.

  32. Karl Fogel says:

    October 17th, 2007 at 10:27 am

    Great essay!

    I was talking about it with jackr (see first comment) and others recently. One thing we thought was that the differences between today’s centralized and decentralized systems are divisible — that is, it’s more of a feature-by-feature difference than a monolithic “fully centralized” versus “fully distributed” difference. Everyone agrees Subversion should have local commits, and “foreign branching”, for example. It just might not get those features at the same time.

    There are certain features that, today, tend to be present in the distributed systems but not in centralized ones (just as there are the reverse, e.g., locking & lock notifications). Some of those features come more naturally to the distributed systems, I won’t deny that (and again, the reverse is true as well), but the point is that it’s the features users use, not the single adjective used to describe the system as a whole.

  33. Vile says:

    October 17th, 2007 at 11:10 am

    ’tis the ideas that count. Next generation of version control systems will have picked the best ideas from each of the current ones.

  34. MaryG says:

    October 17th, 2007 at 11:22 am

    Great article! I’m not a programmer (though I am in the website development business) but we’ve got programmers here that I’ve never really looked at in this point of view. The agents here at Agents of Value are more or less part of the 80%, although I would like to think that there’s one or two who has the potential to be one of the 20%.

  35. undees says:

    October 17th, 2007 at 11:27 am

    TunnelRat, you might be surprised. A few years ago, I was in a shop that used TortoiseCVS. It was easier than any other tool we had tried, because it plugged straight into the shell. We didn’t have to launch a separate client as with VSS or PVCS or Perforce. Our file icons in Explorer or any file dialog were shaded red or green for “modified” or “unmodified.” All of the developers on my team were able to pick it up like (*snaps fingers*) that.

    And as others have mentioned, Subversion has pretty much the same level of friendliness if you install TortoiseSVN. (And on the DVCS front, Mercurial has the young but promising TortoiseHg.)

    I have bills to pay, too, and that’s why I don’t put up with crap tools that impede my ability to pay said bills.

  36. Thomas Arendsen Hein says:

    October 17th, 2007 at 12:07 pm

    “In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work;”

    This is only true for the people having commit access to the central repository.
    So usually people will send patches, often against the latest release instead of trunk/HEAD/tip/whatever. Other people (which are probably those half way between the 80% and the 20%) will send tar/zip archives which contain all their changes.

    “in a decentralized system, the default behavior is for each developer to privately fork the project.”

    In Free Software projects using centralized systems, the default behaviour (at least for all the 80% people and most of the 20%) is to not have commit access, so the default is what I described above. For Free Software projects using a DSCM, the same is true for the described 80%, because they don’t know how to handle the SCM, so these people still can send their zip archives. For the 20% the situation is to either share their patches as before, keep their changes private as before, or (new option!) to publish their repository, so other people can benefit from this.

    So, yes, there will be more “forks” than before, but now you have a chance to reintegrate these forks (i.e. merge the branch) which would have been very tedious with a centralized SCM.

  37. Josh’s Blog › Version Control Techniques says:

    October 17th, 2007 at 2:21 pm

    [...] by josh. Posted on Wednesday, December 31, 1969, at 4:00 pm. Filed under Programming. Bookmark the permalink. Follow comments here with the RSS feed. Post a comment or leave atrackback. [...]

  38. Head On » Blog Archive » Distributed Version Control says:

    October 17th, 2007 at 3:49 pm

    [...] I just read this article on distributed version control by Ben Collins-Sussman who is a lead developer behind Subversion. If I understand his arguments, he basically says that DVCS is better than centralized VCS, but you probably should not use one since 80% of all developers are too dumbfounded too understand VCS at all. [...]

  39. Marc Charbonneau’s Blog » Version Control and “the 80%” says:

    October 17th, 2007 at 5:32 pm

    [...] From iBanjo, on the topic of distributed version control systems in small corporate development environments: In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny. [...]

  40. Susannah Simons says:

    October 17th, 2007 at 8:16 pm

    Don’t forget that you still have the 80%/20% divide at both Google and FogCreek.

    Not that this was your main point, but even using these two companies in your throwaway example is to overlook a point. Google is so much larger a company than FogCreek, and the work that Google does is so much more diverse, that to draw equivalence between the two of them is to invite dismissal on the grounds of hyperbole.

  41. Steve says:

    October 17th, 2007 at 11:59 pm

    offline commits and local branches…THANK YOU! i’m surprised more systems don’t allow this…

  42. BIll Black says:

    October 18th, 2007 at 7:56 am

    “640 K should be enough for everybody!”

    And you want now us to think Subversion should be enough for everybody?

    Maybe DVCS is not good enough for all, but only good for the top 20%. It doesn’t matter. Linux was once good only for the top 2%. NOw we have “consumer Linuxes”, and the same I do expect in a few years for DVCS, once all the top 20% simplify and iron every wrinkle on DVCS.

    – Biil.

  43. BIll Black says:

    October 18th, 2007 at 8:34 am

    Awwww, come on!

    DVCS is not going to change the landscape on how we design and code.

    Object orientation is going to change the landscape: we will stop writing software, because software will be able to write itself.

    You are missing the whole point!

    We need no stinking ESBs and SOAs, the software in the future will read what we have written in the past, connect to it, and ask us what we want to do. Then simply perform.

    Who needs coders in such an environment?

  44. Ben Collins-Sussman says:

    October 18th, 2007 at 8:35 am

    A number of comments indicate that my post should have been clearer in some ways. It was never my intent to say that “Subversion is good enough for everyone” or that “most of the world is too dumb to use DVCS, so don’t use it.” Instead, I’m simply presenting a checklist — a list of obstacles that DVCS needs to overcome in order to be accepted into mainstream corporate software development. I have no doubt that DVCS systems will get there someday, and that will be a great thing. And I’m imploring DVCS evangelists to be aware of these issues, rather than running around thoughtlessly trashing centralized systems. :-)

  45. Daniel Barkalow says:

    October 18th, 2007 at 11:59 am

    I’m not so concerned about the 20% and the 80%. I’m more concerned about the .2%, the .8% and the 99%. As far as I can tell, 99% of the world doesn’t use anything at all: not a DVCS, not Subversion, not a commonly-visible directory that things are put in; not a series of releases by some maintainer; not patches; they email their latest version of the thing they’re working on to a list of the other people they’re working with, and hope that the next version anybody produces includes their changes. It’s like they’re using “rcs”, but doing it in their heads. That’s who I’d like to reach, in part because I sit near some of them, and I can hear them trying to find current versions of things and waiting for each other to finish working on documents, and I’m always cringing at the lost work and wasted effort.

    I think it’s possible, and it’s got more of a DVCS feel to it, for me. The users understand the difference between “Save As…” (commit) and “Send” (push). They know about “Check Mail” (fetch). They do merge or fast-forward by hand. They’ve got no centralization, beyond the fact that, at the end of the process, some particular person is going to issue the press release.

    That’s what I want to see somebody write; unfortunately, I don’t know how to use any of the software that these users know how to use, let alone how to write such software.

  46. Sam Vilain says:

    October 18th, 2007 at 5:14 pm

    Strange, I guess that either means that Catalyst is full of 20% programmers, or we must have very good internal training.

    Or, of course, this argument is apologist rubbish :-) .

    Admit it, you’re just clinging to your old ways in exactly the same way that you accuse people using DVCS clinging to theirs. Your argument falls apart #1.

    Your argument falls apart #2, when you realise that DVCS can be configured to work just like Centralized systems, because it’s more like a constraint which is removed than a different constraint. So you can benefit from the same simplicity of operation if you choose, and then people who do not need this can work without the shackles if they choose.

    Yes they are not yet as integrated into things like the Windows shell. However the GUIs have already far surpassed anything you will see in the Subversion space so this is becoming less and less important.

  47. Matthieu says:

    October 18th, 2007 at 6:10 pm

    Errr…

    > o Most DVCS systems don’t run on Windows at all.

    Can you cite *one* DVCS that doesn’t run on Windows?

    > o Most DVCS have no shell or GUI tool integrations; they’re command-line only.

    Can you cite *one* DVCS that doesn’t have a GUI and that is command-line only?

    I won’t argue about the “centralized systems encourrage review” Vs “decentralized systems encourrage bad practices”, other people did so already, and you probably know it’s wrong if you already looked at a few examples in real life.

  48. Matt Galvin says:

    October 19th, 2007 at 11:08 pm

    Great post. I have had more than one battle trying to introduce people to version control. I have had the most success with Subversion largely because of granular permission control, the Subversive Eclipse plugin and TortoiseSVN… and it is my VCS of choice.

    I can’t even begin to describe how much I agree with the whole reality thing. People really need to come back to Earth and get and keep a solid grip on reality. I love what I do, but most people simply don’t care. I always try to keep that in mind. Introducing new tools can be less painful if it is done at the right time and with a little bit of care and understanding.

    It’s a little weird to me, and I think it mostly comes from being overly enthusiastic, that the top 20% can so easily loose touch with reality and fail to view things from other peoples perspectives. Our first thoughts should be about “how will others feel about this tool”… not… “I think it rocks so I am going to try and force it on everyone else by driving them nuts pushing it every chance I get”. If a person likes a tool use it for your personal projects, you can’t expect everyone else to want to use it the way you want to. Especially in the business world. Companies tend to have very strict requirements, they don’t care about the latest trend (things come and go all the time), they care about keeping their business running, keeping customers happy and keeping the money rolling in. And nevermind government agencies… I will not even go there, if you have worked with them then you know what I am getting at. Technologies are just tools, it’s not cool to them. They most often take the… if it ain’t broken, don’t fix it approach.

    I am really glad to hear about the improvements you guys are working on for the upcoming releases of SVN. Can’t wait to use the new and improved features. Thanks! and… keep up the great work!

  49. Matt Galvin says:

    October 19th, 2007 at 11:20 pm

    And even if it is broken they still don’t want to fix/improve it unless it is costing them money or lost revenue.

  50. Dan says:

    October 20th, 2007 at 2:26 pm

    Thanks for the interesting story.

  51. behdad says:

    October 20th, 2007 at 4:33 pm

    I think the main point your article misses (or is not clear about) is that corporate environments (small Windows shops, banks, …) and Open Source community need NOT use the same tools.

  52. Kurt Christensen says:

    October 21st, 2007 at 2:21 am

    Ben, thanks fo rthis post. You wrote:

    “In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work”

    I work in your 80%, and you simply cannot underestimate the importance of this. In a very large corporate IT shop, the inability of developers to cooperate with each other in sane ways literally shuts down development by leaving the build perpetually broken.

    One other comment: your numbers are off – the 80% is much more like 99% outside of Silicon Valley, and many of us – shockingly – aren’t *complete* idiots and don’t like being addressed as such.

  53. Shabs says:

    October 21st, 2007 at 8:25 pm

    Ben:

    For Subversion 2.0, a few of us are imagining a centralized system, but with certain decentralized features. We’d like to allow working copies to store “offline commits” and manage “local branches”, which can then be pushed to the central repository when you’re online again.

    I’m beginning to think Subversion development is being poisoned by an influx of Perforce brain damage.

    First, changesets, which are basically useless as implemented. You _need_ patch-hunk-level granularity to make this a useful feature for general use — the person who justified the lack of this by saying “this is what 90% of users need — ignore the other 10%” has the percentages backwards, or at least very skewed from reality.

    Then the svn update interactive merge feature, which breaks lots of existing shell scripts and is difficult to drive from a script (and –non-interactive is insufficiently granular, because it shuts off password access as well)).

    And now a distinction between “offline” and “online” usage. Holy thionite, man. Next, you’ll be introducing Perforce’s idiotic mainframe-era “forms”.

  54. Ben Collins-Sussman says:

    October 21st, 2007 at 10:13 pm

    Shabs, perhaps you’d like to come to the dev@subversion.tigris.org list and discuss your opinions about new svn 1.5 features? Drive-by criticisms of discussions that took months are sort of… unfair. :-)

  55. Rams says:

    October 22nd, 2007 at 12:08 am

  56. Ian Clatworthy says:

    October 22nd, 2007 at 7:41 pm

    Ben,

    It’s great to see you raising these issues and doing so in such a well written way. While thesedays I’m actively encouraging people to look at DVCS technology and Bazaar in particular, I’ve spent most of the last 12 years managing teams in a corporate environment using CVS. I’m highly familiar with many of the points you’ve raised. For example, the maximum number of branches our developers could manage on their laptops was 3 or 4 because of the huge size of the code base. The code was mission critical 24×7 – quality and processes to achieve it were major focuses of our team.

    I must say though, that while each of your “shocking statements” are true, many of your other points about DVCS technology simply aren’t correct. They may apply to select tools and DVCS fan-boys (Git and Linus perhaps) but they don’t apply to Bazaar and (to a lesser extent) Hg. Bazaar in particular directly supports the central workflow model. In fact, it supports many workflows really well and really cleanly as illustrated in http://bazaar-vcs.org/Workflows. I’ve argued for some time now that the future of version control is neither central nor distributed, it’s adaptive. See http://ianclatworthy.wordpress.com/2007/06/21/version-control-the-future-is-adaptive/.

    Suggesting that central VCS is inherently better because it forces developers to check in to a central location more frequently is a myth. It’s a bit like saying “You’re allowed to talk to anyone in the company on the phone but only through a centrally registered conference call.” Used correctly, DVCS increases collaboration and leads to a much higher quality trunk than I’ve ever experienced or seen by teams using central VCS tools.

    It’s good to hear of some of the improvements planned for Subversion. They will greatly help many people do their job more effectively. Together with companion tools like TeamCity, they will be sufficient for many teams for some time. However, there are compelling advantages to DVCS that mean no amount of adding features to a central-only VCS tool can match it. See my recent paper on Why DVCS Matters (http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf) for a a summary of these.

  57. About version control and “the 80%”… « Francesco Crippa says:

    October 23rd, 2007 at 4:16 am

    [...] Today Luca sent an interesting post on mugshot. [...]

  58. Ted says:

    October 26th, 2007 at 5:44 pm

    I think you have to have a middle ground between the 20%ers and the 80%ers. I’ve done things like taking the time to learn a language over the weekend for fun, and I’ve certainly gotten in arguments over algorithms with friends and of course have tried linux, but I also program in C# and Java (although, I barely do any work in my Java class and the only C# work I do is XNA stuff), and I like Windows. I’ve never participated in an open source project before although I guess I’m only 17. Whatever, maybe one day I’ll be a 20%er, but for right now I feel more like an mix between the two.

  59. ganeshram iyer says:

    October 29th, 2007 at 10:38 am

    Thanks for putting the stuff I already knew and was pondering upon into a blog. It is definitely better received and accepted when someone as well known as you states it. I have been considering similar nature of collaboration in the CAD world and your article provides some valuable insight on which route to pursue to reach a larger audience.

  60. Stefan says:

    November 2nd, 2007 at 10:42 am

    I think there are three types of programmers, not just two. You forgot those who are interested in new stuff and try everything out, but still go home friday afternoon and forget about computers until monday. Those who use Windows every day but still try Linux from time to time (and then go back to Windows again, because there’s always at least one device that doesn’t have a driver or the driver is so buggy it constantly freezes the system).
    And sometimes even those people contribute to open source projects :-)

    But you’re absolutely right about the problems of DVCS. They’re (at least for now, I’m sure they’ll improve) way too complicated for the average people. If you count the programmers out there who never even used version control (besides making a copy of their source folder from time to time and renaming that folder with the date of the copy) you will find that those still outnumber the ones who use version control by thousands.
    Try explaining DVCS to them – after a five minute introduction they will already have mentally shut down, built a defense wall against such a complicated beast – and from that time on, you won’t get through to them anymore and they’ll find any excuse to not use version control at all.

    When I joined TortoiseSVN (yes, I joined, I didn’t start it), it was because at that time there simply was no version control system available that I would have considered introducing in our company. I found a lot back then, but they all were much too complicated to use or had a really high learning curve. I knew that I just wouldn’t be able to explain those to my coworkers (especially the one at the desk to my left back then) and get them to understand.
    That’s why I joined TortoiseSVN, and I’ve tried to keep it as easy to use as possible, hiding as much of the internals of version control as possible (e.g., you won’t find any peg revisions in TortoiseSVN – it always tries to find that itself). To be honest, most of the time I had to implement something in TortoiseSVN I was thinking about that guy to my left and how I would that feature to him – if I couldn’t come up with an explanation that he would understand I went back to the drawing board and tried to implement the feature a different way.
    And I think that’s one of the reasons why TortoiseSVN is one of the more successful SVN clients.

  61. Kim Sullivan says:

    November 8th, 2007 at 2:26 am

    Sam Vilain: “However the GUIs have already far surpassed anything you will see in the Subversion space so this is becoming less and less important.”

    Great! I’m looking for some DVCS plugin that is on par with Subclipse/Subversive. Could you please post the link? I only found “Mercurial Eclipse” but that didn’t impress me, so I’m stuck with a local SVK repository becuse I can acess that with Subclipse.

  62. Two Types of Programmers? « Justin Rudd’s Drivel says:

    November 26th, 2007 at 3:29 pm

    [...] 26, 2007 · No Comments Via Jeff Atwood, I found Ben Collins-Sussman discussion of two types of programmers. What uttercrap. They took a gray issue and are trying to make it black and white. There are not two types or fourteen types. There are an infinite amount of programmers. [...]

  63. Aninimous says:

    November 26th, 2007 at 5:38 pm

    By that measure, we wouldn’t have either Linux or *BSD today, to name just two.

  64. evanx says:

    November 27th, 2007 at 4:51 am

    i wouldn’t say that many of the 20% people (working in banks etcetera) have never used version control – they all do, in my experience, they use an IDE with SCM plugin. Also i wouldn’t say they all use Microsoft only – there is a large percentage using Java/Eclipse, especially in banks, government, etcetera, mostly for web app server development.

  65. iBanjo » Blog Archive » Version Control and the… Long Gradated Scale says:

    November 27th, 2007 at 3:39 pm

    [...] My previous post about version control and the 80% deserves a follow-up post, mainly because it caused such an uproar, and because I don’t want people to think I’m an ignorant narcissist. Some people agreed with my post, but a huge number of people took offense at my gross generalizations. I’ve seen endless comments on my post (as well as the supporting post by Jeff Atwood) where people are either trying to decide if they’re in the “80%” or in the “20%”, or are calling foul on the pompous assertion that everyone fits into those two categories. [...]

  66. sven says:

    November 27th, 2007 at 3:43 pm

    They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development.

    You must be one of those crazy bitches that uses strictly vi for your editor. Things like Intellisense/Content Assist are more helpful than you think.

  67. Ben Collins-Sussman says:

    November 27th, 2007 at 3:47 pm

    sven: I use emacs, actually. :-) And yes, emacs has something quite similar to Intellisense too. I never type whole symbol-names out.

  68. Are you in the 80% or the 20% of programmers? « Jim 2.0’s Blog says:

    November 27th, 2007 at 11:53 pm

    [...] Jeff’s article is based on Ben Collins-Sussman’s article written about a week earlier. Ben writes: The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. [...]

  69. The Two Types of Programmers « Pramit’s Weblog says:

    November 28th, 2007 at 1:36 am

    [...] November 28, 2007 at 6:35 am (Uncategorized) The Two Types of Programmers Contrary to myth, there aren’t fourteen types of programmers. There are really only two, as Ben Collins-Sussman reminds us. There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools. [...]

  70. Are you a 80% or 20%? :: Fat Penguin says:

    November 28th, 2007 at 1:58 am

    [...] If you are currently working as a programmer, what kind of a programmer are you? an “80%” or “20%”? If you’re not familiar with these types, you may want to read this or that. [...]

  71. Curious Chap » Blog Archive » The Two Types of Software Development says:

    November 28th, 2007 at 6:06 am

    [...] What spurred me to ink my thoughts is Ben Collins-Sussman’s recent Version Control and “the 80%” post where he separates developers into two groups: the 20% alpha geeks and the 80% folks. Ben, one of Subversion’s developers, dares to write: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...]

  72. Hisham Abboud says:

    November 28th, 2007 at 6:15 am

    Great post, and it inspired my own post. I agree totally with your 80/20 description. Personally, I would have divided the post into two separate ones: one describing the 80/20 observation, and the other regarding DVCS.

  73. Picando Código says:

    November 28th, 2007 at 7:36 am

    Los dos tipos de programador

    En blogs, portales de noticias, empresas, centros de educación en programación, etc. generalmente se tiende a describir distintos “tipos” de programadores. Hace en poco en un blog en TechRepublic, nombraban 10 tipos distintos de programad…

  74. Big geek says:

    November 28th, 2007 at 3:41 pm

    [...] So, over to what popped to mind this time. I was reading an interesting post about programmers: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...]

  75. Anna-Jayne Metcalfe says:

    November 29th, 2007 at 5:38 am

    “version control and a working Linux abilities are vital tools for a programmer”.

    That’s an interesting statement Zack. While I totally agree with the former, the latter is just one way of saying “the ability to motivate yourself to learn (and, crucially, keep learning) how to manipulate a system at a low level” or similar. Learning how to use GNU/Linux effectively is just one way of doing that – you could equally well substitute self-motivated learning of any skill which isn’t well supported by the mainstream.

    In my experience all too many of the “80%” just don’t do that – I’ve lost count of the number of times I’ve had to “educate” a supposedly senior developer about const correctness or how to use STL containers efficiently. For a disturbingly large subset of developers, “Merge” is a terrifying word.

    FWIW I’ve cut myself a career as a Windows developer and I’ve never got around to learning GNU/Linux – but that doesn’t mean I don’t keep up to date with what’s going on in the wider community. I’m all too well aware of what’s going on with C++0x, dynamic languages etc…it’s just that I simply don’t have the time to do everything I’d like to (my free time usually gets eaten up by company admin), so something usually has to give.

    As the saying goes, “We live in interesting times”. :)

  76. No soup for me » Blog Archive » Where did the geeks go? says:

    November 29th, 2007 at 10:50 am

    [...] So, over to what popped to mind this time. I was reading an interesting post about programmers: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...]

  77. Yet Another Blog » Blog Archive » Dois tipos de programadores… says:

    November 29th, 2007 at 5:29 pm

    [...] Quem quiser ler mais: http://blog.red-bean.com/sussman/?p=79 [...]

  78. oh how i hate the 80:20 | blog@tim-dawborn: ~$ says:

    November 29th, 2007 at 11:56 pm

    [...] Posted November 30th @ 3:56 pm by tim (for people who dont know the 80:20 programmers version, http://blog.red-bean.com/sussman/?p=79) [...]

  79. links for 2007-12-02 - Leere Signifikanten says:

    December 1st, 2007 at 8:24 pm

    [...] iBanjo » Blog Archive » Version Control and “the 80%” (tags: article blog development opensource programming svn dvcs subversion) [...]

  80. Suburban Chicago PHP » Blog Archive » Dave’s (Poignant) Guide to PHP says:

    December 2nd, 2007 at 3:17 am

    [...] Ruby and Haskell are the big “indie” programming languages these days. The 20% kind of programmers see them pushing the boundaries and breaking us out of the C++/Java influenced paradigms which have dominated for more than a decade. They’re the programming languages of rebels…digital Che Guevara t-shirts, if you will. [...]

  81. Low Country Software Ramblings » I don’t feel like one of the top 20%… says:

    December 2nd, 2007 at 2:54 pm

    [...] Posted by benoit on 02 Dec 2007 at 12:54 pm | Tagged as: career, ramblings Jeff Atwood at Coding Horror recently talked about two types of programmers (triggered by Ben Collins-Sussman’s source control comments). The top 20% which are interested in professional development, and the remaining 80% which are more like 9-5 clock workers, and are not doing the magazines/blogs/conferences thing. As Jeff clarified, here’s not dissing the 80%, just pointing out that they are unreachable by conventional means. [...]

  82. Rob Conery » Hey Cool Kids - Alt.Crank is Boring says:

    December 2nd, 2007 at 10:20 pm

    [...] I’m not trying to take a swipe here; I just really dislike divisive posts, in any fashion. I didn’t get past the first sentence. I literally clicked away, knowing that what was coming was yet another summation of our industry, and the millions of people in it, wrapped up nicely into little buckets for easy digestion: Contrary to myth, there aren’t fourteen types of programmers. There are really only two, as Ben Collins-Sussman reminds us… [...]

  83. Man Bites Blog » Blog Archive » There are two types of readers of this post.. says:

    December 3rd, 2007 at 12:57 am

    [...] In the first post,  Atwood riffed off Ben Collins-Sussman’s observation that there are two kinds of programmers — the 80% and the 20% (following the variant of the 80-20 rule that 20% of the people do 80% of the work) to suggest that those of us in the 20% (the assumption being that reading programming blogs is sufficient to identify oneself among the 20%) should devote more of our energy to bringing the 80% up to our level, and less time arguing and showing off to the other 20%. [...]

  84. Version Systems « a developer’s breadcrumb says:

    December 5th, 2007 at 6:14 pm

    [...] If you want know more, please have a look at “Enter Distributed Version Control” section in this post: Version Control and “the 80%. It has remembered to me that I would not shave without a version system, if only I could. [...]

  85. svn synonym < David Lynch says:

    December 11th, 2007 at 12:07 pm

    [...] All this should become irrelevant shortly, though. Subversion 1.5 (according to an aside in this developer blog post) will automatically track much merge metadata so the requirement to specify revision ranges of changes to merge should be eliminated in the common case. I look forward to it. Post a comment | Trackback URI [...]

  86. Paul Hsieh says:

    December 31st, 2007 at 8:42 pm

    Beside the fact that this 80/20 is just some number you pulled out of thin air, you are setting up a false dichotomy. As a corporate developer myself, I have grown increasingly frustrated with CVS and tools like it precisely because its poor branch/merge semantics and/or lack of a local repository. I had found myself doing my own “ad hoc” source control by saving away files in an “intermediate state” before check-in to the central code repository.

    The central code repository is supposed to represent a high quality, if not pristine view of the source. Every checkin is supposed to bring the source closer towards the project’s goal. However, that does not jive with the way people (like me) work. I need to sometimes be very experimental, and try radical/risky things that I don’t wish to expose to the rest of the developers. But I need to be able to back out in baby steps, precisely because I know that my “catastrophic code error” (like a global find and replace gone bad) rate will be much higher. And I don’t want to pay the insane cost of branching then merging the tree every time I do this. So having a local repository is critical for me to maintain my own productivity level, while not interfering with anyone else’s.

    I have not yet tried something like GIT or Mercurial, or Bazaar. I instead use *two different* source control systems: CVSNT and Perforce. CVS is the corporate central repository, and Perforce is my local repository. This way I get the benefit of CVS annotate to know what other people have done to the sources, and I get to use the very powerful and nice Perforce (that has a free single user license) for me to try my experiments in. This works great for me (since I get to work uninterrupted in the way *I* am most confrtable) and my company (which is only exposed to my good changes that have reached the corporate standards for level of quality).

    The goal of DVCS systems, as I understand it, are to solve my problem in a single system. I don’t buy this idea that I am among some elite 20% of developers that code this way. My contention is that *anyone* whose main development system is a laptop instead of a desktop *already* understands a good argument for having a local repository.

    If you want to clone some features from GIT you are going to have to start with the idea of a local repository. Otherwise, I just don’t see SVN as having any serious future.

  87. All the cool kids are using Git « Arthur Koziel says:

    January 2nd, 2008 at 3:47 pm

    [...] All the cool kids are using Git Posted in Software by Arthur on January 2nd, 2008 In the past week i switched all of my local Subversion repositories to Git, i made this change after reading Version Control and “the 80%” – which ironically was written by a Subversion developer. After reading the article and watching Linus Torvald’s Google Talk about Git, i took the Git – SVN Crash Course and was immediately hooked. [...]

  88. jamess says:

    January 3rd, 2008 at 10:03 am

    My instinct, from my experience, is to say that the majority of developers in the world are lone developers. Sometimes they are successfull and get more developers to join them in their quest. Then there are purpose software teams that are building large applications who will have established cultures and are resistent to change. Almost every developer I know started as a lone developer tinkering with code. Perhaps these statements are incorrect and I certainly can’t back them up but it makes sense to me.

    The vast majority of these lone developers will generally not see the benefit of revision control over taking some sort of backup (my turn to generalise with sweeping statements).

    The group I see as being a large driving force in adopting tools like Mercurial and Bazaar is those growing from being a single developer to getting a co-worker and the progression from that point. The reason I say this is that the barrier to entry is next to nothing for these two tools.
    To use either of these two tools is simply adding a single folder which does not pollute your project. To pull out of the decision is simply deleting the folder. The tools are simple and require only a few commands to get the basics done.

    Centralised repositories require an install of a server and are more constraining in their use. Centralised repositories have a larger learning curve in how to deal with a server or in a lot of cases requires a sysadmin who is willing to help, beaurocracy is a killer of a lot of things.

    For me I see it as a natural evolutionary step for lone developers progressing onto team development which will drive Bazaar and Mercurial.

    I use Bazaar and Mercurial in particular for this comment as these are the only two DVCS I have used and I do not know if my comments are true of others.

    There are other reasons why I think Mercurial and Bazaar are improvements over subversion but this post is about majorities and status quos and so is probably not relevant.

    I don’t think that I am disagreeing with your post too much just adding more perspective.

    The only sure thing I know is that things will change.

  89. T1 Internet Access says:

    January 18th, 2008 at 7:18 pm

    I think you have to have a middle ground between the 20%ers and the 80%ers. I’ve done things like taking the time to learn a language over the weekend for fun, and I’ve certainly gotten in arguments over algorithms with friends and of course have tried linux, but I also program in C# and Java (although, I barely do any work in my Java class and the only C# work I do is XNA stuff), and I like Windows. I’ve never participated in an open source project before although I guess

  90. Volatile (ie., highly dynamic) supergraphs « Utterances of a Zimboe says:

    January 27th, 2008 at 10:45 am

    [...] So, this ‘volatile supergraph’ thingy should be rather easy to implement (no hard non-trivialities) if you was a systems designer (and not part of the 80%) and I’d be very excited to have it working. I bet a few googol other zimboes would be as well. [...]

  91. Tu te imbunatatesti? | Codetaku says:

    February 2nd, 2008 at 3:52 pm

    [...] Ben Collins-Sussman amintea ca sunt 2 tipuri de programatori: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...]

  92. patrickwilsonwelsh.com » Dynamic Languages, Blimps, and “Compiler as Nanny” says:

    February 15th, 2008 at 11:50 am

    [...] Power Programmers, Alpha Geeks, the ones who some now claim in public (reasonably, I believe) that can outproduce “vocational programmers” by a factor of 10 or more (there is that same math, hmm)? It turns out that one of the primary indicators of one of those guys or gals is that they just cannot keep their hands off of lots of different languages. And they are really good at comparing entire language systems and development systems to one another. And they really like dynamic languages, because they are so much faster. And they really, really like unit tests, because suites of them save their behinds so frequently. [...]

  93. kevin jo says:

    February 18th, 2008 at 10:25 pm

    version control pro is a very easy version control tool and very cheap.you can visit http://www.upredsun.com/vcpro/vcpro.html and learn more…

  94. Hey! It’s Brian! » Blog Archive » Death by Dialog Box says:

    March 30th, 2008 at 9:25 pm

    [...] I’ve always been interested in Ruby on Rails development. The rapid adoption and growth of Ruby as a language and Rails as a framework has been inspiring. Unfortunately, it has yet to grow beyond the ranks of early adopting alpha programmers. Much of this can be blamed on the lack of an easy to use, fully integrated IDE for development. Developers like things like syntax highlighting, intellisense, refactoring tools and interactive debuggers. Until yesterday I had yet to come across an exceptional IDE for Rails development. So, my consideration of RoR for any reasonable sized projects was nil. [...]

  95. Clay McCoy says:

    April 10th, 2008 at 3:29 pm

    In this blog you criticize DVCS for the wrong reasons, I’ll get to that later. Then you mention all the enhancements to SVN which are all DVCS features (offline commits, local branches, consolidating all the metadata directories…) These features won’t fix some of the biggest failings of SVN.

    Here are reasons why some of your criticisms of DVCS are misguided.

    “In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work”

    With SVN people are forced to put their code in the main repository in order to commit their work at all. They don’t have a choice. Everyone reading this knows that putting your code in the same place and collaborating are NOT the same thing.

    “They have to put in some extra effort to share code and organize themselves into some sort of collaborative structure.”

    It’s not extra work, it is sharing code along the lines of an existing social structure. It’s usually less work to commit locally until you want to collaborate or move the code off your machine, and the push it all when you want to.

    “Yes, I’m aware that a DVCS is able to emulate a centralized system; but defaults matter. The default action is to fork, not to collaborate!”
    When it is your only option it is not a default. It is a limitation.

    The fact is that if you have developers that don’t play nicely with others, the tool isn’t going to matter. I have seen more people refrain from commits with SVN than DVCS because in their mind they aren’t ready to commit to trunk and creating a branch is too hard. This is a problem with the individual regardless of tool, and with SVN this guy (who is the 80%) doesn’t even have the capabilities of VCS locally.

    ” * Managers don’t want 20 different private forks of a codebase; they want one codebase that they can monitor all activity on.”

    There is only the one codebase that matters usually, this is moot.

    ” * Cloning a repository is bad for corporate security. Most corporations have an absolute need for access control on their code; sensitive intellectual property in specific parts of the repository is only readable/writeable by certain teams. No DVCS is able to provide fine-grained access control; the entire code history is sitting on local disk.”

    Parts of the repo, and history are two orthogonal concepts. This doesn’t even make sense. If parts of your repo need different security you can create a different repo. You have to do the same thing in SVN. A certain range of history is not going to be what you need to protect.

    ” * Cloning is often unscalable for corporations. Many companies have huge codebases — repositories which are dozens or even hundreds of gigabytes in size. When a new developer starts out, it’s simply a waste of time (and disk space) to clone a repository that big.”

    This is blatantly false. I’ve used git-svn on several large repos. My local git repo with all the history is ALWAYS smaller than the SVN snapshot. One 7gb svn snapshot was a 3.5gb git repo. Half the size and the whole history. The bare git repo (without a working copy) was only 35mb (yeah, with an m). Having the whole history, and the ability make local commits and branches makes most operations way faster. Which all argues that on a large code base you SHOULD be using DCVS.
    Just like most of the rest of your post, I find that assertion was made completely out of ignorance.

    The real trade off between Subversion and a DVCS like git is usability vs. power. Subversion has great IDE integration, and windows GUI’s. To me the gui seems unnecessary and I would rather have the features. This is not the case for everyone. It’s a safe bet that most of the DVCS’s are going to catch up in the usability department before SVN gets the features, and that fact does matter to everyone.

  96. Duncan Mac-Vicar says:

    April 15th, 2008 at 2:18 am

    I don’t agree with you. You are focusing on the team, and assuming the model is fixed.

    With DVCS you can still follow a centralized model with one repository where all developers can push to.

    The nice things is that even if you follow that model, I am still free to push my changes to my laptop instead, work from home, then push them to my server, continue working in the train, create 300 branches and easily merge them when I am back. I can’t do that with subversion, I usually need to commit in order to work again from another place (and I still need network access).

  97. “Two Types of Programmers”… « JP’s Web Place says:

    May 3rd, 2008 at 6:15 am

    [...] A sua volta quel post ne cita un altro, dello stesso autore, in cui vi è questo favoloso trafiletto, che quoto e sottoscrivo. Two Types of Programmers [...]

  98. Shek’s Blog | My first real post! says:

    May 11th, 2008 at 2:15 pm

    [...] motivation that lighten me is from a post on iBanjo, I was shock when I saw about half of the 80% folks’ characteristics are similar to [...]

  99. Alexander Yuryshev says:

    June 4th, 2008 at 4:37 pm

    I’m totally agree with you in one point – DVCS is not for every project.

    But I disagree with your Pareto distribution.
    My point of view:
    80% – doing NOTHING. (As my colleague said after learning Ruby : “Anyway, Java is the only language in which you can write MILLIONS LINES for enterprise projects)
    16% – doing SOMETHING
    3% – doing WELL
    And 1% – are extremely good, with .2 % doing EXTRA.

    It’s my not very honest opinion.

    Anyway:
    1. Thank you for SVN
    2. My apologies for my English

  100. Los dos tipos de programador | Picando Código says:

    August 11th, 2008 at 5:29 am

    [...] los tipos de programadores. “Contrario al mito, no hay catorce tipos de programadores.. Hay realmente solo dos, como nos recuerda Ben Collins-Sussman. Hay dos “clases” de programadores en el mundo [...]

  101. RagingDragon says:

    August 29th, 2008 at 7:08 pm

    RE: James in post 23

    The heirarchical model you describe is pretty much how the Linux kernel and many (if not most) open source projects work.

    The point about choosing the best tool (i.e. VCS) for the job (i.e. your current project) is pretty much a truism. And one that fanatical supporters of any particular tool/product/project tend to forget. But I think conflating vocational programmers with incompetent (i.e. incapable of learning new tools) and dead wood (i.e. unwilling to learn tools) programmers was a mistake which insults the vocational programmers. I’m certainly in the alpha programmer group, but I’ve worked with vocational, incompetent and dead wood programmers.

    The vocational programmers are perfectly capable of learning any VCS or pretty much any other new tool. Some know about best practices, and would like to learn the new tools and techniques; however, they won’t go out of their way to do so, nor will they take the initiative to convince management of the need for process changes. But they will quietly support the alpha programmers. Others vocational programmers are smart but risk averse, and thus don’t like change, and still others are ignorant of best practices. These two groups will likely become interested in best practices after seeing them used. If management are alpha programmers, or support the alpha programmer(s) then the vocational programmers will do what they’re told.

    Some organiziations completely lack alpha programmers (perhaps processes are so bad they got fed up and found employement elsewhere…). In other places the dead wook programmers wield alot of influence (probably because they’re the “legacy system” experts), or the management themselves are dead wood programmers. And these are the places where resistance to change is pathological. And unfortunately, the programming departments in alot of large corporations are dominated by dead wood.

  102. Southwestern Virginia Developers Forum » Thinking about Distributed Source Control says:

    August 30th, 2008 at 8:36 am

    [...] that will adapt Git to SVN repositories.  And of course, it never hurts to have a dose of the other side before you adopt a new [...]

  103. Richard says:

    October 8th, 2008 at 3:58 am

    Actually, there are three types of programmers!
    You forgot to mention the people that do version control by hand using dos batches that copy files between directories whose names contain version numbers.

  104. IBlog » Hola de nuevo, Pareto. says:

    October 16th, 2008 at 4:47 pm

    [...] Two types of programmers by Ben Collins-Sussman. http://blog.red-bean.com/sussman/?p=79 [...]

  105. JiangXin says:

    December 24th, 2008 at 1:16 am

    Centralized VCS with sound features from DVCS (offline commit, local branch) is right way for Subversion.
    For me, subversion’s vendor branch is hard to maintain. Hg+MQ is better. If subversion 2.0 has some sort of MQ like plugin, it is cool.

  106. Brandon Zylstra says:

    January 30th, 2009 at 3:13 pm

    Your argument about Subversion fitting the needs of big corporations better makes sense, based on the need for fine-grained access control and preferring a centralized system. (It’s generally best to use the tools best suited to the job at hand!)

    And your future changes proposed for SVN are also quite welcome. Subversion’s future looks bright indeed.

    Your arguments about the risks of distributed version control, however, really make it sound like you’re grasping at straws. I almost stopped reading at that point, laughing and deciding SVN was dead in the water if this was the best argument its creator had to offer.

    May I recommend expunging that paragraph? You’ll have a much stronger argument, and will alienate fewer people, and will be dismissed by fewer people who’ve never seen the terrible things happening that you’re describing as risks of systems that you probably don’t use.

    Thanks, and good luck with SVN 2. I look forward to trying it out again at that point.

  107. The Programmer Continuum – What Does Being in the Upper 20% Really Mean? | Alan's Technical Musings says:

    February 15th, 2009 at 7:44 pm

    [...] couple of articles I have recently read talked about two classes of programmers: the bottom 80%, which are the [...]

  108. Google Tech Talk by Douglas Crockford on ‘JavaScript: The Good Parts’ « Yet Another Random Thoughts Blog says:

    April 14th, 2009 at 8:40 pm

    [...] this is not the reality for most people. Let’s agree on something Ben Collins-Sussman said: Most of the software industry is made up of 80% programmers (I know this is oversimplified, but it is good for my point). That said, javascript sucks at a [...]

  109. My Fitment In This Classification « A Coder’s Life … and Programming Languages says:

    April 30th, 2009 at 2:30 pm

    [...] on April 30, 2009 I taking this excerpt from a very old,interesting and controversial blog post of Ben [...]

  110. Life @ Refactoring: SVN 还是 Hg, 是个问题 says:

    August 26th, 2009 at 10:23 pm

    [...] Version Control and “the 80%” [...]

  111. Anhar says:

    August 28th, 2009 at 3:13 am

    I think the whole premise is wrong, I think its more like:

    80% > 15% > 5%

    where the 15% is what everyone here calls the ’20%’ the 5% are the REAL legends, these are the guys that don’t just use the latest tool,tech, they create them from scratch.

    If they are given Source control for example, they want to create their own, from scratch.

    Or given OpenGL, they want to write their own, but no its not enough. They dig even further they want to write graphics rasterisers in assembly, but even that is not enough, they dislike that fact that modern CPU (ALU) adder microelectronics are slow due to propagation delays, so they want to re-engineer them! I know I have, come to think of it, I think at this stage this is probaly the 1% so:

    80% > 19% > 1%

  112. james mckay dot net » The two types of programmer says:

    October 3rd, 2011 at 2:01 am

    [...] when somebody writes that on their blog, they’re generally criticised as being elitist and condescending. This is because [...]

  113. Dave’s (Poignant) Guide to PHP | Suburban Chicago PHP says:

    December 16th, 2011 at 10:52 pm

    [...] and Haskell are the big “indie” programming languages these days. The 20% kind of programmers see them pushing the boundaries and breaking us out of the C++/Java influenced paradigms which have [...]

  114. Distributed Version Control for the Other 80% - Kyle Cordes says:

    March 28th, 2012 at 6:52 am

    [...] Collins-Sussman, one of the key developers behind Subversion, argues in Version Control and the 80% that distributed version control will remain a niche interest, and will not move in to the [...]

  115. Los diferentes tipos de programadores | Punto Geek says:

    February 5th, 2013 at 10:01 am

    [...] Distintos tipos de programadores en Viviendo entre Pingüinos. Original por IBanjo [...]