Does Python really follow its philosophy of "Readability counts"?

[Steven D'Aprano]

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 
intractable.


> 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.



-- 
Steven