Does Python really follow its philosophy of "Readability counts"?
steve at REMOVE-THIS-cybersource.com.au
Sat Jan 24 00:37:57 CET 2009
On Fri, 23 Jan 2009 20:09:48 +0000, Mark Wooding wrote:
> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
>> On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote:
>>> Why on earth couldn't I change the code of another member of my team
>>> if that code needs changes ? The code is the whole team's ownership.
>> That's a model that works well when you have a small team of, say, a
>> dozen people. It's not a model that works when you have hundreds of
>> developers working on the project. The last thing I want in my projects
>> is cowboys who ride all over other people's code, changing internals of
>> parts they barely know at the drop of a hat, causing who knows what
>> side- effects.
> Why are you assuming that Bruno would make his change in such an
> irresponsible manner?
I did? Where did I make that assumption?
What I said was that the model "The code is the whole team's ownership"
doesn't work well for large projects. *One* reason it doesn't work for
large projects is that you will invariably have cowboys who, given half a
chance, will code irresponsibly *if you let them* by encouraging the
attitude that, sure, that class written by the database backend team
belongs to everyone, never mind that you're in the UI team, go right
ahead and use whatever internals you like. There are other reasons -- do
I need to elaborate on them?
Even in a project as small as Python there is sense of *individual*
(rather than collective) code ownership, in the sense of responsibility
for specific portions of the code base. Scale up the project by a factor
of ten, and the problems caused by collective responsibility are simply
> Such things need discussing, with some
> appropriate level of formality, with the people most involved with the
> relevant code -- which might be anything between a quick chat with the
> bloke across the room or an agenda item on the next team meeting to a
> written proposal.
Yes, and when you have hundreds of developers working on the project, the
chances are quite good that there will be twenty such agenda items every
week, and then the project will bog down on arguments about what needs to
be private and what doesn't, until the project manager just makes a
blanket ruling No Access To Internals Full Stop.
And then, you know what, the project still manages to go forward. Instead
of spending 15 minutes hacking the existing Foo class to do what they
want, and then 15 hours dealing with the cascading bugs when the class
changes, people simply spend 7 hours subclassing Foo to get what they
want, and it's all good and not the end of the world.
> Given your apparent readiness to assume the worst of programmers at
> every opportunity (e.g., your above assumption that Bruno would change
> code unilaterally and secretly, assumptions elsewhere that programmers
> treat any exposed wiring as being published interface), I can only
> assume that you really need to get some better cow-orkers.
Now you're just being naive. The solution to these sorts of problems
isn't "get better programmers" because even the best programmers make
mistakes (errors, and errors of judgement). Communication breaks down --
Fred is sure Barney said "Yes" while Barney is equally positive he said
"No". Or somebody has a demo to the CEO in two hours and needs to hack
something up Right Now and the guy he has to chat to is home sick with
the phone turned off, and by the time he comes back to work the little
hack is forgotten. Or whatever. There's a *bazillion* number of things
that can go wrong in big projects, and "getting better programmers" only
reduces that to something like a hundred million. It's a credit to
*everybody*, including the cowboys and the cow-orkers, that any project
of any significant size makes any progress at all.
Besides, "better programmers" are in short supply. Sometimes you have to
use who you've got, because Guido and the timbot are working somewhere
else and you can't afford them. That's why we have languages like Python:
so that *ordinary* programmers can be as productive as genius programmers
in languages like C.
More information about the Python-list