Re: [rdiff-backup-users] Restarting development

[Gavin]

Yes indeed,

The post bellow is exactly how I feel about rdiff-backup.

Having been using rdiff-backup for a long time and watching this list
for just as long I have seen many of these
little 'hairs' grow. As a user I can't believe that the core code is
that bad or thrown away, since rdiff-backup has served me
faithfully for a long time now.

As a coder I can certainly appreciate that it can be easier to write
your own split function than to figure out somebody else's,
especially if it is not extremely well commented or laid out. But
rdiff-backup is somewhat larger and more mature than a
split function and I also know that it's a long road to get to that
level of maturity in a new code base.

It's really great to see dev interest again either way, I was starting
to think I would have to start building a migration plan :-)

Cheers
Gavin
>>
>>
>>
>
> This discussion and your comments here remind me of this old post from
> Joel Spolsky:
>
> "Things you should never do, part I"
>
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
>
> I'll include some excerpts below, but first want to say I'm not
> necessarily advocating any particular approach to this. I'm a
> relatively new rdiff-backup user and I love it.  It's so much nicer to
> use than my old approach of my own bash scripts + rsync + hard links.
> I'm just happy that people are talking about development and
> maintenance -- I want to see this project thrive. But in the role of a
> user, I don't want to vote for any development plans. (I will be happy
> to help with some testing for either version however.)
>
> But! I think Joel's points are valid and I always think of them when
> people talk about wanting to start over.
>
>
> From the article (with the acknowledgement that he may be talking
> about larger programs, but it seems that rdiff-backup has grown to be
> quite comprehensive...):
> _______________________________________
>
> We're programmers. Programmers are, in their hearts, architects, and
> the first thing they want to do when they get to a site is to bulldoze
> the place flat and build something grand. We're not excited by
> incremental renovation: tinkering, improving, planting flower beds.
>
> There's a subtle reason that programmers always want to throw away the
> code and start over. The reason is that they think the old code is a
> mess. And here is the interesting observation: they are probably
> wrong. The reason that they think the old code is a mess is because of
> a cardinal, fundamental law of programming:
>
> It’s harder to read code than to write it.
>
> This is why code reuse is so hard. This is why everybody on your team
> has a different function they like to use for splitting strings into
> arrays of strings. They write their own function because it's easier
> and more fun than figuring out how the old function works.
>
> As a corollary of this axiom, you can ask almost any programmer today
> about the code they are working on. "It's a big hairy mess," they will
> tell you. "I'd like nothing better than to throw it out and start over."
>
> Why is it a mess?
>
> "Well," they say, "look at this function. It is two pages long! None
> of this stuff belongs in there! I don't know what half of these API
> calls are for."
>
> ...
>
> Back to that two page function. Yes, I know, it's just a simple
> function to display a window, but it has grown little hairs and stuff
> on it and nobody knows why. Well, I'll tell you why: those are bug
> fixes. One of them fixes that bug that Nancy had when she tried to
> install the thing on a computer that didn't have Internet Explorer.
> Another one fixes that bug that occurs in low memory conditions.
> Another one fixes that bug that occurred when the file is on a floppy
> disk and the user yanks out the disk in the middle. That LoadLibrary
> call is ugly but it makes the code work on old versions of Windows 95.
>
> Each of these bugs took weeks of real-world usage before they were
> found. The programmer might have spent a couple of days reproducing
> the bug in the lab and fixing it. If it's like a lot of bugs, the fix
> might be one line of code, or it might even be a couple of characters,
> but a lot of work and time went into those two characters.
>
> When you throw away code and start from scratch, you are throwing away
> all that knowledge. All those collected bug fixes. Years of
> programming work.
>
> ...
>
> Is there an alternative? The consensus seems to be that the old
> Netscape code base was really bad. Well, it might have been bad, but,
> you know what? It worked pretty darn well on an awful lot of real
> world computer systems.
>
> When programmers say that their code is a holy mess (as they always
> do), there are three kinds of things that are wrong with it.
>
>
>
> _______________________________________________
> rdiff-backup-users mailing list at address@hidden
> http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL:
> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
>