Hackers and Painters (Re: RFC: Removal of KAutoConfig / KAutoConfigDialog)

[Navindra Umanee]

Benjamin Meyer <ben at meyerhome.net> wrote:
> At the time that it happend it didn't really matter if the solution
> was technically better or not, a good chunk of code I had touched in
> the last six months was modified and that code had obviously been
> put there by me.  Wouldn't it tick you off just a little bit if that
> was done to you without even an e-mail of heads up?  In some
> companies if you even correct comments

This is a very good point.  A little communication would have probably
gone a long way here.  Incidentally, this whole KAutoConfig vs KConfig
XT issue reminds me of an awesome article on Hackers vs Painters:

http://www.paulgraham.com/hp.html

One quote pertaining to this issue would be:

"Because painters leave a trail of work behind them, you can watch
them learn by doing. If you look at the work of a painter in
chronological order, you'll find that each painting builds on things
that have been learned in previous ones. When there's something in a
painting that works very well, you can usually find version 1 of it in
a smaller form in some earlier painting.

I think most makers work this way. Writers and architects seem to as
well. Maybe it would be good for hackers to act more like painters,
and regularly start over from scratch, instead of continuing to work
for years on one project, and trying to incorporate all their later
ideas as revisions."

In this case of course, the revision was very fast but I think all
agree it is for the best since KConfig XT is a nice step forward and
builds on top of KAutoConfig code.

(An opposite situation where this didn't work out so well is Krita:
http://www.koffice.org/developer/krita/ and of course we all know the
Mozilla story.)

The second quote is:

"As far as I know, when painters worked together on a painting, they
never worked on the same parts. It was common for the master to paint
the principal figures and for assistants to paint the others and the
background. But you never had one guy painting over the work of
another.

I think this is the right model for collaboration in software
too. Don't push it too far. When a piece of code is being hacked by
three or four different people, no one of whom really owns it, it will
end up being like a common-room.  It will tend to feel bleak and
abandoned, and accumulate cruft. The right way to collaborate, I
think, is to divide projects into sharply defined modules, each with a
definite owner, and with interfaces between them that are as carefully
designed and, if possible, as articulated as programming languages."

Obviously we see here exactly the problem of multiple people working
on the same thing.  Although the situation probably couldn't have been
avoided, communication becomes all the more important -- one painter
does not simply paint over the work of another.  

I think we have often seen conflicts in the KDE project that more or
less end up in unnecessary disaster because of such situations.

Anyway, these are two very small quotes from a very cool article on
hacking.  Recommended reading, if you haven't already.

Cheers,
Navin.