Traditionally we performed code review before commit, and I had an argument with my colleague today, who preferred code review after commit.

First, here's some background,

1. We have some experienced developers and we also have new hires with almost zero programming experience.
2. We'd like to perform fast and short iterations to release our product.
3. All team members are located at the same site.

Answer: What's Your Branching Strategy? (37 Votes)

If the developers have their own private branch for development (which I'd recommend in most situations anyway), I'd perform the code review prior to merging with the trunk or main repository. This will allow developers to have the freedom to check in as frequently as they want during their development/testing cycle, but any time code goes into the branch that contains the delivered code, it gets reviewed.

Generally, your bad experiences with code reviews sound more like a problem with the review process that have solutions. By reviewing code in smaller, individual chunks, you can make sure it doesn't take too long. A good number is that 150 lines of code can be reviewed in an hour, but the rate will be slower for people unfamiliar with the programming language, the system under development, or the criticality of the system (a safety critical requires more time)—this information might be useful to improve efficiency and decide who participates in code reviews.

Answer: Pre-Commit (15 Votes)

I've recently started doing pre-commit reviews in a project I'm in and I must say I'm pleasantly surprised about how unproblematic it is.

The biggest drawback of post-commit reviews that I see is that it's often a single-person-only afair: Someone reviews the code for correctness, but the author is not usually involved unless there's a serious mistake. Small problems, suggestions or hints don't usually reach the author at all.

This also changes the perceived result of the code reviews: it's seen as something that only produces additional work, as opposed to something where everyone (the reviewer and the author of the code) can learn new things every time.

Answer: Check in Early & Often (7 Votes)

Developers who work for long periods—and by long I mean more than a day—without checking anything into source control are setting themselves up for some serious integration headaches down the line. Damon Poole concurs:

Developers often put off checking in. They put it off because they don't want to affect other people too early and they don't want to get blamed for breaking the build. But this leads to other problems such as losing work or not being able to go back to previous versions.

My rule of thumb is "check-in early and often", but with the caveat that you have access to private versioning. If a check-in is immediately visible to other users, then you run the risk of introducing immature changes and/or breaking the build.

I'd much rather have small fragments checked in periodically than to go long periods with no idea whatsoever what my coworkers are writing. As far as I'm concerned, if the code isn't checked into source control, it doesn't exist. I suppose this is yet another form of Don't Go Dark; the code is invisible until it exists in the repository in some form. ...If you learn to check in early and check in often, you'll have ample time for feedback, integration, and review along the way...

I've worked for a couple companies that had different approaches towards this. One allowed it, as long as it didn't prevent compiling. The other would freak out if you checked in any bugs at all. The former is much preferred. You ought to be developing in a kind of environment that would allow you to collaborate with other people on things that are still in progress, with the understanding that it will all be tested later.

The most direct way to improve as a software developer is to be absolutely fearless when it comes to changing your code. Developers who are afraid of broken code are developers who will never mature into professionals.

I would also add that for peer reviews, if someone wants you to change something, having the history of your original version in source is a very valuable learning tool.

Answer: Two-Phase Commit (5 Votes)

Most repositories today support a two-phase commit or a shelveset (private branch, pull request, patch submission or whatever you want to call it), that will allow you to inspect/review work before pulling it into the main line. I would say that leveraging these tools would allow you to always do pre-commit reviews.

Also, you might consider pair coding (senior pairs with junior) as another way of providing a built-in code review. Consider it as a quality inspection on the assembly line instead of after the car has rolled off.

Answer: Weigh Benefits, Decide (1 Vote)

Gives reviewers confidence they are reviewing the author's latest revision.

Helps insure everyone reviews the same code.

Gives a reference for comparison once revisions made from review items are complete.

No Running Commits During the Review

I have used Atlassian tools and have seen running commits occur during the review. This is confusing to reviewers, so I recommend against it.

Post Review Revisions

After reviewers complete their feedback, verbally or in writing, the moderator should ensure the author makes the requested changes. Sometimes reviewers or the author may disagree as to whether to designate a review item as a fault, suggestion, or an investigation. To resolve disagreements and ensure investigation items are cleared correctly, the review team depends on moderator judgment.

My experience with around 100 code inspections is that when reviewers can reference an unambiguous coding standard, and for most kinds of logic and other programming faults, review results are generally clear cut. Occasionally there is a debate about nit-picking or a point of style can degenerate to argument. However, giving decision power to the moderator avoids stalemate.

Post-Review Commit

Gives the moderator and other reviewers a data point to compare against the pre-review commit.

Provides metrics for to judge both the value and success of the review at defect removal and code improvement.

The fast and short iterations are signs of a development organization that has little idea of what it is doing. The standards of work are so poor on the web that almost anything goes. But arguing about the details of code reviews is just an example of the blind leading the blind.

I prefer having code reviewed pre-commit. People have a tendency to be lazy, and once the code is in the code base changing it is a pain in the butt. We have a code review requirement before checking in, and enforcing that post-checkin would be nigh impossible.

Granted, we have a lengthy test suite to catch bugs, so if you're confident you won't need to make any major changes, you can parallelize your work by starting the automation while waiting for another dev to be free for code reviewing,

Guess it depends on your release cycle too. We do monthly and long term releases but we have a main trunk and a release branch in our SVN. Things can be checked into TRUNK just about anytime but can only be merged into the release branch during that's code scheduled release cycle.

A "commit" in a DVCS is literally just giving a name to some changes you made. I can't even imagine how the reviewer would get your changes if you don't commit them somewhere. I suppose you could send them as patches, but even that's just a different kind of commit.

At my last job, we used a source code revision system called Accurev and it had a pre-commit action of "keeping" your changes. What this did was that it provided a quasi-private branch for any changes you had and it gave you a revision history of your kept files. Another user using Accurev could look at your workspace (which was managed on a central server) and see what changes you had kept. This made a pre-commit review easier because they could just diff the kept files against the mainline files.

At my current job, we're using subversion and that doesn't have anything like Accurev's keep action. On top of that (at least in our environment), having a private branch is a pain in the ass (that may have to do with the way we manage private branches, but that's a different topic). This is where the "developers should check in early and often" argument comes into play. I can keep making changes in my local sandbox, but until I commit them, they aren't backed up and I don't have any local revision history, so if I get to a good milestone (but still not to the point of doing a full commit), I can't really create a line in the sand at that point that I can roll back to if in the next iteration of major changes I make a huge mistake and just want to start over.

Either way, I'm a big fan of code review prior to committing to the mainline, regardless of how much of a superstar the developer is because even superstars make mistakes.

I'd definitely say review post commit. A developer needs to be able to finish work and move on in a timely manner. Especially if they work different hours.

DVCSes exist. Stop operating on bad assumptions.

If you aren't using a DVCS, you already fucked up. If you aren't using a workflow manager like Gerrit for a development team big enough to worry about "working different hours", you fucked up again.

I've really got to bite my tongue to not be equally snarky back here...

So you're saying that you should use multiple repositories on a DVCS system because your company makes you wait to push until it's been reviewed?

It just seems really dumb. The company should just have you commit to a non-production branch and push. They can bring changes from your branch as they're reviewed. It's post commit in that you can forget about it, and it's pre commit in that unreviewed code never goes into production.

A "commit" in a DVCS is literally just giving a name to some changes you made. I can't even imagine how the reviewer would get your changes if you don't commit them somewhere. I suppose you could send them as patches, but even that's just a different kind of commit.

Maybe I'm off base, but what I'm picturing is: 1. Programmer makes changes. 2. Programmer finds other programmer 3. They sit down and go through his changes 4. Either they stamp them good and he pushes/commits, or they reject the changes.

Perhaps with teams that are in the same office pre-commit reviews could work but for remote teams I find that post-commit reviews work the best. One of the strengths to committing often is that you're code is always backed up.

Each of our developers have their own working branches which they can commit to as often as they like. Once they want to merge with the master branch, they can do a pull request. At that point, the developer is saying their code is ready to be reviewed. I can then checkout their branch remotely and review it with them. Once the code has been review and tested it's merged into the master branch. We are using git so a team using SVN might have a different workflow.

Since we don't know what VCS is being used here, I think generally the best guideline I can offer is "Make sure the code is reviewed before it enters its final resting place, where a developer would reasonably expect to check out code from that resting place and have it work. There is almost nothing guaranteed to be a major, profitless time-sink than tracking down recently-introduced bugs in "stable" code that could have been caught in review or pre-final-resting-place testing. It takes less time for you and your reviewers to find before it's in the wild than it will for someone less familiar to find it when your code sneakily blows up.

I would also strongly second the comments about using a DVCS, "snarky" though they may have been, and Gerrit is a powerful tool to solve exactly this problem. With Gerrit, the un-reviewed changes can't even get into the "real" branches in the repository, so that's an added bonus for those downstream developers who may be depending on your stability. Of all of the VCS systems I've used for some time (SVN, Perforce, StarTeam, Mercurial, and of course, Git) this setup is by far the best for keeping more than about 5 developers playing in the same pool together.

A "commit" in a DVCS is literally just giving a name to some changes you made. I can't even imagine how the reviewer would get your changes if you don't commit them somewhere. I suppose you could send them as patches, but even that's just a different kind of commit.

Maybe I'm off base, but what I'm picturing is: 1. Programmer makes changes. 2. Programmer finds other programmer 3. They sit down and go through his changes 4. Either they stamp them good and he pushes/commits, or they reject the changes.

It seems like a bad idea to me.

In my shop we can package our changes into a discreet diff file, that when opened on another machine with repository access will show you the diff against the version of the files the original change was made. Basically a portable version of a commit without comitting. We do developer reviews in a largely asynchronous manner via email, we don't need to be at each other's desks, or even in the same country. And I can back up all my changes on a seperate share entirely. It's great because if I'm prototyping I can save that prototype elsewhere without having to worry about the overhead of a branch.

Is that not a normal tool to have? To package diffs like that? It makes code reviews super easy.

I definitely prefer to use branches for different features or feature groups, in which case each branch is a work in progress anyway. In this case committing is fine, and in fact better, as it means people can easily see the code and review it that way, without the need for specific code review sessions. Reviewing your own code before committing seems logical, but I think more often than not you're likely to miss mistakes in something you've just been working on, so it's usually wasted time more often than not.

I think the branching strategy is key; good separation of working branches, with clear indication of stable (adequately tested) versions of that branch (for developers to pull from). When a version is about to be tested before being flagged for stability then if issues are found they can be flagged for review then.

I mean, in theory if you're using unit testing then all you should have to do before committing is run the relevant suite of unit tests for what you were working on, and if passed just commit away. I much prefer unit testing to code review anyway; except perhaps for newer members of a team whose coding style may not quite match up to your standards for naming, structure etc.

I would also strongly second the comments about using a DVCS, "snarky" though they may have been, and Gerrit is a powerful tool to solve exactly this problem. With Gerrit, the un-reviewed changes can't even get into the "real" branches in the repository, so that's an added bonus for those downstream developers who may be depending on your stability. Of all of the VCS systems I've used for some time (SVN, Perforce, StarTeam, Mercurial, and of course, Git) this setup is by far the best for keeping more than about 5 developers playing in the same pool together.

It sounds like what Gerrit does follows exactly what I said. Developers can push their work, so it's essentially finished. And people can review later. That's post-commit reviewing as far as the devs are concerned.

The problem comes in when you ask developers to stop before moving on to new work until they can get their review done. Or worse, ask them to move on, but stop in the middle of that when someone finishes reviewing their patch and says they can commit it. Or the worst possible, finish, move on, finish again, move on, finish again, move on, now in the middle of that go back and apply that patch they wrote 3 weeks ago that has finally gotten reviewed.

However you facilitate it they need to be able to finish the task and put it into a queue where if all goes well they won't have to do anything else with it.

A "commit" in a DVCS is literally just giving a name to some changes you made. I can't even imagine how the reviewer would get your changes if you don't commit them somewhere. I suppose you could send them as patches, but even that's just a different kind of commit.

Maybe I'm off base, but what I'm picturing is: 1. Programmer makes changes. 2. Programmer finds other programmer 3. They sit down and go through his changes 4. Either they stamp them good and he pushes/commits, or they reject the changes.

It seems like a bad idea to me.

Ah, sure, I guess that might work. However, I agree that it doesn't seem like a very good idea even when possible (review within an office). For one, it gives an incentive to create large commits, since you don't want to invite someone over for every one-liner.

It's great because if I'm prototyping I can save that prototype elsewhere without having to worry about the overhead of a branch.

Is that not a normal tool to have? To package diffs like that? It makes code reviews super easy.

Just out of curiosity... What VCS are you using that you find yourself worrying about the overhead of a branch? Pretty much every one I've used stores a branch using less space than a patch (diff) of a moderate size would take.

I would also strongly second the comments about using a DVCS, "snarky" though they may have been, and Gerrit is a powerful tool to solve exactly this problem. With Gerrit, the un-reviewed changes can't even get into the "real" branches in the repository, so that's an added bonus for those downstream developers who may be depending on your stability. Of all of the VCS systems I've used for some time (SVN, Perforce, StarTeam, Mercurial, and of course, Git) this setup is by far the best for keeping more than about 5 developers playing in the same pool together.

It sounds like what Gerrit does follows exactly what I said. Developers can push their work, so it's essentially finished. And people can review later. That's post-commit reviewing as far as the devs are concerned.

The problem comes in when you ask developers to stop before moving on to new work until they can get their review done. Or worse, ask them to move on, but stop in the middle of that when someone finishes reviewing their patch and says they can commit it. Or the worst possible, finish, move on, finish again, move on, finish again, move on, now in the middle of that go back and apply that patch they wrote 3 weeks ago that has finally gotten reviewed.

I am not sure if it was clear before, but I wanted to explicitly state that Gerrit works with/on top of Git.

Often if there are no conflicts (e.g., two devs edit the same file around the same lines) it can be used to commit changes to the final repository in an arbitrary order regardless of the order the devs pushed them to Gerrit for review. It is also fairly simple to upload new versions of the changes if more changes are required.

In general, if your change is fairly simple, you can push your change to Gerrit and immediately switch to working on the next task, whether that is a dependent change or something different altogether. After that, all of the stop/start/restart/try-again/rework stuff is largely mitigated if you're using Git [properly*] since it's pretty quick to stash, checkout your change, respin your change, checkout whatever you were working on, pop your stash, and get back to whatever you were doing.

I'm not sure how much effort it took us to do this at my employer, but if you want to get really fancy, you can even tie Gerrit in with a build bot (which can potentially run tests in addition to building) and get automated testing on your code before it gets in the repository.

It's not perfect, though. The amount of email I get from Gerrit is obscene, and sometimes it's hard to find if there have been new comments on changes without wading through the emails. Sometimes there are things that it flags as conflicts that would have actually been fine so you end up taking a few minutes to rebase something and push a new revision for review, but I'd rather have false positives on conflicts than false negatives.

Despite its flaws, after using it for the last couple years and really getting used to the workflow, I would not want to go back to any of those systems I mentioned previously.

eggy78 explained it pretty well. This is exactly what Gerrit is for, and I restate that if you've got enough developers to need to worry about being blocked/unblocked by code reviews, you're mad if you aren't using it (or something equivalent, but I haven't found anything in the same ballpark).

You need to find the right balance between having too many commits and not enough commits. If you don't have enough commits, the changes are too big and that will cause various headaches (merge conflicts, etc). On the other hand, if you commit too often you are wasting time.

Where I work, if it's a fairly small change (hundreds lines of code) I will always review and test the code before committing, then commit it, deploy it, and do some final testing last minute testing (which should never find any bugs. If you find bugs here, you screwed up somewhere and should slap yourself on the wrist).

For big changes, as thousands of lines of code, then you should create a branch and commit frequently with little or no pre-commit reviews. Then once the whole job is finished and tested and you're happy with it, do a final review as part of merging your branch back into trunk.

If my change is somewhere between 700 lines and 3,000 lines then I'll make up my mind based on past experience and how confidant I am in the code I wrote. Sometimes there's just no substitute for experience when you're deciding what to do.

Another point I'd like to make, I am a firm believer that there should not be any known problems in code you commit to trunk. If you aren't finished yet, then _do not commit to trunk_. Make a branch, and commit to that instead. Merge it into trunk when it's actually finished. Trunk should always be a few last minute tests/sanity checks away from being deployed.

Sometimes something comes up, and you need to deploy trunk quicker than you expected. Committing half baked code to trunk will catch you with your pants down, especially if the guy who committed it calls in sick or is in another time zone.

Try to prevent errors, failures, bad designs early in the development cycle

If you're preventing bad design at commit time then you're doing it wrong as the design should be in place before any code hits the page thus the code itself should merely be an implementation of a pre-determined design and not simply the programming going off to write the code off the bat. There seems to be this habit that when university students graduate they throw away all the knowledge of good programming practices in favour of 'type code then sort out the disaster down the track' as the approach of system analysis and design. In all due respects, by the time you get to the typing stage the only thing you should be doing is transliterating from all the written up documentation to what ever programming language you've decided to us.

I'll second the comments that it depends enormously on the developers you're working with and the type scale of the projects—the caliber and experience of the former, and the structure of the latter being significant factors.

My personal preference is development branches for all bug fixes and feature development that gets reviewed before merging into trunk (I've opted for our trunk to be our live version, rather than branches); we tag our trunk every week it has active changes checked into it, as well as tagging the versions used for each client project (since we always want to use either the latest—when starting a new project for a client—or the same version we've used on that project previously to ensure consistency). Branching for each development cycle can get hairy if you have a large project or lots of developers, though, if you're using something a little older like SVN.

And yes, snark at not using a DVCS notwithstanding, there are often good reasons to still be on a centralized VCS, including the fact that it's just easier for people whose main task isn't programming to keep their heads around what's going on. (That's my situation: I'm the only full-time developer, supporting a group of chemical engineers who program. SVN is a good fit for us.) In any case, you can leverage a DVCS to apply the same philosophy I outlined above with a much larger group. Branch for development, review before check-in. That way you have good revision history (you can micro-commit if you like, which is my preference, especially when dealing with the horrendous legacy code I'm usually swimming in), and get the benefit of reviewing before it joins the main stream and impacts everyone else.

Another point I'd like to make, I am a firm believer that there should not be any known problems in code you commit to trunk. If you aren't finished yet, then _do not commit to trunk_. Make a branch, and commit to that instead. Merge it into trunk when it's actually finished. Trunk should always be a few last minute tests/sanity checks away from being deployed.

I think there's probably some confusion about terminology both in the original question and in some of the comments here. Perhaps it's a difference in how users of different version control systems refer to the actions they take within those systems.

In Git, a commit is nothing that ever needs to be avoided; it only impacts one branch, it's easily reversible, and it really shouldn't be any more controversial than hitting ctrl+s after typing a few lines of code. In my office we all do our development in feature branches based on a staging branch we use as master. We could commit 100 times a day if we wanted to and nobody else would be impacted by it. It makes absolutely no sense to require code review before commit, so I suspect that the original question is using "commit" as an equivalent to what I would refer to as a "merge" or possibly "push".

If that's the case, I wouldn't want unreviewed code merged into production. Any time you're putting code in a place that other devs on your team are going to wind up having it in their feature branches (which would happen with code merged into production in our office), it ought to be thoroughly tested and reviewed before getting there. It's not terribly difficult to undo changes, but what's the point of doing review in the first place if you're waiting until after the well everyone's drinking from is already potentially poisoned?

As a tester in a Scrum environment, I vote for checking in the code at the same time it's sent for code review. Code that's not checked in is not testable by outsiders. Often the code reviews will come back with notes but no changes, so waiting for the code review becomes an unnecessary delay. (I prioritize testing reviewed code, of course, to avoid having to re-test after an alteration.)

But more than that, encouraging code check ins helps the programmer to develop self-confidence in their ability to deliver. It discourages being fearful and non-committal.

Having to merge beastly code changes all at once also puts the testers in an awkward position and increases the likelihood of unforeseen incompatibilities between two or more peoples' work.

It's more difficult to do pre-review check ins in some workplaces, but if you're following Scrum your team size should be relatively small and it should be easy enough to avoid stepping on other peoples' toes.

Code review after commit is like checking your brakes after a crash. While you can revert your changes easily enough it's still a poor way to go about it.

crhilton wrote:

I'd definitely say review post commit. A developer needs to be able to finish work and move on in a timely manner. Especially if they work different hours.

Both situations depend on branch strategy as per the article. If you are working on a pure development branch, it is pretty inefficient to review "checkboxes added to form... next thing is the textboxes!" but instead it would be a lot more practical to review once the entire form is completed and do a whole functional test and bugfix checkins then.

If you are working on a hotfix to a major release, what if the customer audits the changes (i.e. every checkin to the product)? I am talking about fairly large operations where downtime equals hundreds of thousands of dollars an hour. What are you going to tell them? Oh this checkin was untested? We have customers where this would be a tricky scenario (admittedly some customers can be more difficult than others). Considering the sizes of these fixes as well, it can be practical for pre-checkin reviews as it doesn't hold the dev up from the core tasks.

The commit of a change or new code is always a risk and a potential break of the current software. The review of colleague is our organization mandatory, and in my team we use it all the time.

We use four steps before a commit is done:The first step is to write a proper test case for your problem, without any errors of course .The second step is a line by line code review. Check for the correct coding standards, use of libraries (reuse of code), efficient code etc. In essence it is not a functional check of the software, that should already have been covered by the test cases.The third step (optional) is a review by a QA engineer, who will test the new software in some known business cases which are not yet handled (or difficult to handle) in automated tests (especially UI related stuff).Finally the business analyst (our customer) has to agree on the given solution.

I would also strongly second the comments about using a DVCS, "snarky" though they may have been, and Gerrit is a powerful tool to solve exactly this problem. With Gerrit, the un-reviewed changes can't even get into the "real" branches in the repository, ...

It sounds like what Gerrit does follows exactly what I said. Developers can push their work, so it's essentially finished. And people can review later. That's post-commit reviewing as far as the devs are concerned.

I think it depends on what you mean by commit. Area you talking about any commit to the VCS or are you talking about a push to trunk, master or whatever you want to call the "common development branch"?

In a DVCS you typically commit all the time, to your local branch. So your changes are tracked by your local copy of the DVCS. If you are working on a larger change you can also push your local branch to the central repo so other people can easily get your changes. (With Git this is not strictly necessary as people can pull from your private repo, but I haven't really tried that in a "real" setup.)

crhilton wrote:

The problem comes in when you ask developers to stop before moving on to new work until they can get their review done. ... Or the worst possible, finish, move on, finish again, move on, finish again, move on, now in the middle of that go back and apply that patch they wrote 3 weeks ago that has finally gotten reviewed.

However you facilitate it they need to be able to finish the task and put it into a queue where if all goes well they won't have to do anything else with it.

I'd say that if it takes longer than a day or two to get a review though then something is wrong with your setup. But I've been in the same situation myself and sometimes it takes longer to get people to do reviews. (Although I think a week is on the outside of what's acceptable.)

What I've seen is usually that when people are working on bigger changes they tend to work with more time between commits but also with smaller groups of people. (Perhaps max of 5 or so.) So even if you don't merge to a common branch there are not all that many people committing changes so it doesn't become a huge problem.) During these cycles reviews are done on bigger chunks of code and they take longer. Sometimes in this mode I've checked in to the master branch before a review is done. Because it's not really expected that the master branch should be bug free. (You should do regression testing on your own first though, to at least verify that everything builds and you haven't broken something.)

When functionality is in place it becomes more of an issue of fixing bugs. And then you'll likely be doing reviews before merge to common branch. But since the fixes are usually small it seldom takes more than an hour or so to get an ok on it.

I suppose it really depends on your project and in what sort of environment the development takes place.

In the team in which I work we use Gerrit and Jenkins. Gerrit allows for the modifications to be reviewed before they are merged into the master branch. Only once you have two positive votes will the merge be permitted. In addition to humans we have Jenkins running integration builds, where compilation, automated test cases and code correctness are tested, such as with jslint. If Jenkins fails, then the patch set is automatically given a -2.

This process works for us, but given different team sizes, infrastructure and so on, this may it work for someone else. I do feel though, that code should always be run through and automated integration build and human code review before it is ready to be merged. You should never be too proud to have someone give their opinion of your code style or the way you approached your solution - we all learn through the process.

Note, that to use Gerrit you first need to be using git as your source control solution.

If you aren't using a DVCS, you already fucked up. If you aren't using a workflow manager like Gerrit for a development team big enough to worry about "working different hours", you fucked up again.

With that "open-minded" attitude of yours, I bet you're a real pleasant teammate to be around.

I've worked at a couple of different companies on many different projects using many different tools. And I'd say that my experience is that he is right. (And I do think that attitude is nice for my team-mates to have. It may not be nice for the managers however.)

You could use a "normal" VCS that isn't distributed. But in the end I think you will become less efficient if you do. (Git does live something to be desired on the GUI front though, that seems to be why some people hate it.) If you're not using tools to help developers get their work done then they will waste time doing boring administrative work manually. The absolute worst is if you have broken tools which go out of their way to hinder the developer by introducing "hidden states" and similar problems. Then you have developers wasting time doing manual administration in a tool that tries to make it harder for them.

Tools, processes and workflow are all things that should make it easier for you to do your work. This may not always mean that it's easier for you to check something in and say you're done however. Because they should also help you do things right with code reviews, unit tests and other such things. That way you, the developer, can concentrate on doing the things that the computer can't do automatically. Ie the creative stuff.

If you aren't using a DVCS, you already fucked up. If you aren't using a workflow manager like Gerrit for a development team big enough to worry about "working different hours", you fucked up again.

With that "open-minded" attitude of yours, I bet you're a real pleasant teammate to be around.

I am driven to make things better. I make people more productive and I make the environment more enjoyable to work in because of it. So, yes, I'm pretty pleasant to be around.

But I don't put up with shit, and in 2012 using a CVCS is a sign of institutional and cultural failure. It may be your shop's only one, in which case you are still far better off than most places--but it remains one. It is a sign of a lack of commitment toward empowering your people to do great work.

That bad developers get pissy when I don't respect their bad choices is, very honestly, not my problem.

If you aren't using a DVCS, you already fucked up. If you aren't using a workflow manager like Gerrit for a development team big enough to worry about "working different hours", you fucked up again.

With that "open-minded" attitude of yours, I bet you're a real pleasant teammate to be around.

I've worked at a couple of different companies on many different projects using many different tools. And I'd say that my experience is that he is right. (And I do think that attitude is nice for my team-mates to have. It may not be nice for the managers however.)

You could use a "normal" VCS that isn't distributed. But in the end I think you will become less efficient if you do. (Git does live something to be desired on the GUI front though, that seems to be why some people hate it.) If you're not using tools to help developers get their work done then they will waste time doing boring administrative work manually. The absolute worst is if you have broken tools which go out of their way to hinder the developer by introducing "hidden states" and similar problems. Then you have developers wasting time doing manual administration in a tool that tries to make it harder for them.

Oh, I'm not questioning the benefits of a distributed VCS. I'm more focusing on Blacken00100's attitude of "if you don't do it my way, you fucked up." That's an incredibly crass and negative thing to say about someone, when there are plenty of reasons why someone may not do it Blacken's way, few of which are because he or she "fucked up." In my particular case, my company uses Visual Studio, so we use TFS as our VCS for its natural and easy integration. We do lose out on the benefits of a DVCS, but being a Microsoft-based shop, we gain in other ways.

Oh, I'm not questioning the benefits of a distributed VCS. I'm more focusing on Blacken00100's attitude of "if you don't do it my way, you fucked up." That's an incredibly crass and negative thing to say about someone, when there are plenty of reasons why someone may not do it Blacken's way, few of which are because he or she "fucked up." In my particular case, my company uses Visual Studio, so we use TFS as our VCS for its natural and easy integration. We do lose out on the benefits of a DVCS, but being a Microsoft-based shop, we gain in other ways.

Yes and no. We've recently been moving back towards using a non DVCS (from Git to Perforce). And it's made me appreciate Git a lot more. But there are some people who prefer Perforce (well, not many, but still) and it seems to be mostly because of the UI.

But personally I'd say that a DVCS is so much more powerful that if you know how to use it and the power it gives you then you are in fact "fucking up" if you go with a traditional VCS. Eg a DVCS makes it quite easy to do things like grep your changelog to see what has happened in files.