Two More Very General Consulting Question

[Martin Gregorie]

Have you thought about how "devel" sounds to a native English speaker? I
wouldn't use that abbrev.

That is a non-issue. The spelling makes the meaning clear.

 

[Andreas Leitgeb]

Have you thought about how "devel" sounds to a native English speaker? I
wouldn't use that abbrev.

If you're referring to "devil", then I think it is not all that similar.
(not even phonetically). If you mean something else, then please let me
know. (email ok, if you prefer)

PS: anything to say about pros and cons of DVCS, too?

 

[Tom Anderson]

I can imagine managers to be more afraid of longer sync-intervals,
resulting from the DVCS-philosophy, than of not seeing all devels'
interims work.

The DVCS philosophy does not result in longer intervals between sharing
work with your colleagues (what i assume you mean by "sync-intervals").

Both centralised and distributed VCS makes it easy to share work with your
colleagues. You can do it as often or as seldom as you choose, or your
process dictates. The choice of centralised or distributed VCS has *no*
bearing on it.

I have come across this belief before. I honestly don't know where people
get it from.

It would have to be a client whose devels are working remote, and where
the benefits of piling up some work before a sync outweighs the higher
risk of conflicts happening.

No, as i explained, DVCS has benefits even in a conventionally-organised
team.

I do understand this motivation. The "scapegoat" is typically the one
who is in the best position to fix a problem, so identifying him without
having to ask everyone is worth as much time as by what the scapegoat
will be able to fix it more efficiently than anyone else on the project.

DVCS is capable of recording history just as precisely as centralised VCS.
Indeed, because you can have multiple local commits in between pushes, it
can record *more* details about history.

DVCSs also give you tools to erase and rewrite history, but it is your
choice whether you use them or not. If you care about history, don't use
them.

tom

 

[Tom Anderson]

Tom, no need to sell _me_, I am sold already.

Ah, sorry. When you wrote:

I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.

I assumed that meant that you didn't think DVCS had universal benefits.

That's why I have tried three times in as many years to introduce a DVCS
in a real work environment. Each time it's been a SVN shop (which is
part of the problem, they've already got SVN).

I'll tell you why it's failed:

1. It's (legitimately) hard to convince a client that a centralized DVCS
model is significantly better than a SVN setup. It has to be
_significantly_ better because they are facing a migration of history
(History is super-important in these organizations. It is how you locate
scapegoats.)

There are conversion tools which will import repositories, with history,
from other VCSs into various modern DVCSs; we used cvs2git to convert some
of our projects from CVS to Git, and it worked pretty well. There was a
bit of manual faffing about, though - i think the conversion took about a
day to get right. I believe the conversion from Subversion to Hg/Git is
much smoother than from CVS, because Subversion at least has atomic
commits.

Nonetheless, i recognise that conversion is not necesssarily
straightforward. I've seen questions on the Mercurial mailing list about
people having real trouble with it - although of course that's
self-selecting, as the people for whom it goes smoothly don't post!

2. Very few arguments that have to do with benefits for _developers_ are
important. You don't have to convince developers, you have to convince
managers.

2. Only the developers amongst the client personnel understand your
"local commits" argument, or the other one (better branching/merging
than SVN). Problem is, very few of the managers get it, and _they_ are
the ones that need to be convinced.

I've encountered my share of client managers that actually don't see
your description of local commits as being a good thing, unlike you or
me or most developers. To them that all sounds like coders wasting time
at best, and unsupervised work at worst.

Interesting and depressing. Why on earth are people who don't understand
programming making decisions about programming tools? These sound like
very sick organisations. Plenty of those around, of course!

In fact I'm satisfied that hg/git are always at least as good as svn,
and usually better.

It's simply that I have yet to encounter a team environment where the
managers bought this.

This is just baffling to me. These people make software, right? So it's in
their interest to have the best tools for making software? This is like
shipwrights preferring to stick with forge welding rather than adopting
arc welders.

But, yes, it happens. On my last big external project, we used CVS; we
pointed out that CVS wasn't very good, and suggested moving to Git/Hg, and
the client came back and suggested moving to their corporate standard,
which was Team Foundation Server. We quickly backtracked and said that CVS
was just fine. Ugh.

tom

 

[Andreas Leitgeb]

The DVCS philosophy does not result in longer intervals between sharing
work with your colleagues (what i assume you mean by "sync-intervals").

If all changes committed to local "clone" get automaticall sync'ed
to some master repository, then there's little change from status quo.

If not, then obviously the interval between syncs is longer than that
between commits.

Both centralised and distributed VCS makes it easy to share work with your
colleagues.

I haven't yet *worked* with git/hg/...
I've however used a dvcs to retrieve the source of some open-source
project that I wanted a newer version of than packaged with my OS
distribution and I've skimmed over a couple of howto's telling how
to use the new DVCS, often with guides for CVS'lers about the replace-
ments for each of their previous typical command lines.
Guess what: the new commands were constantly more complicated.
Instead of typing one command to see the locally modified files, and
available changes from the repo for the current subtree of the project,
one has to sync first, then issue one command for this and another for
that and yet another...

If some external person were to talk me into this, I might also
tell them that I'd change to TFS, just to make *him* stfu on this.

You won't get anyone off CVS who hasn't yet fallen victim to CVS's
limitations, and less have, than you might think.

Maybe it's like you won't get a Joe Doe user off Windows, unless he's
just lost a week of work to viruses... And strangely enough, some haven't.

I have come across this belief before. I honestly don't know where people
get it from.

Typically, they read it between the lines of what dvcs-advocates write.

No, as i explained, DVCS has benefits even in a conventionally-organised
team.

I've read some (in this thread, and before), but didn't so far
find any that I'd buy as relevant for my projects at work. Arved(?)'s
remarks (about clients refusing dvcs) seemed to me, as if his clients
happened to share my version of reality.

DVCS is capable of recording history just as precisely as ...

Oh, sure, never doubted that. The comment I answered appeared to
ridicule management's desire to find "scapegoats" as primary drive
behind (over?)valueing vcs-history. As if they were always just trying
to find someone to sack.

 

[Jim Janney]

1. History is super-important in these organizations. It is how you
locate scapegoats.

History is an important working tool for me. It's the first thing I
look at when I want to know why a piece of code is written the way it is
rather than the way I think it should be, or the way I originally wrote
it. Fairly often there turns out to be a reason, usually tied to a
customer request.

 

[Arved Sandstrom]

History is an important working tool for me. It's the first thing I
look at when I want to know why a piece of code is written the way it is
rather than the way I think it should be, or the way I originally wrote
it. Fairly often there turns out to be a reason, usually tied to a
customer request.

I have a bunch of reasons for valuing history. One of the most important
ones ties in with my role as a software consultant who usually works on
fixing or adding to existing applications, and it is quite similar to
yours: looking for the "why". More often than not there are either no
requirements or design documents, or they are incorrect or obsolete, and
so frequently the only place one can derive requirements for future work
is in the existing code.

This is actually part of an identified field of work; just Google on
"business rules extraction". Although a lot of that field has to do with
static analysis, if you've got good history available then there is
clearly valuable information there too.

Still, while you may have good reasons for valuing history, and I'd like
to think that I do, and no doubt plenty of other developers have good
reasons, a lot of places don't. You'll know when you're in a toxic place
when people are much more interested in the "who" rather than the "why",
and not so they can get the "why" from the horse's mouth either.

AHS