On Fri, 23 Jan 2009 20:09:48 +0000, Mark Wooding wrote: > Steven D'Aprano <st...@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 -- http://mail.python.org/mailman/listinfo/python-list
