Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

One objection that I have often heard raised against Python that it is difficult to synchronize a team of many programmers on large Python project. Note: that synchronization is possible in such a project does not necessarily entail that it is practical, cheap or easy. There's still n*(n-1) communication channels between programmers, so communication cost grows more or less with square of number of programmers, on average.

One thing I liked in Java are interfaces. Sadly, both PEP 245 and even modified Guido's version on interfaces ( http://www.artima.com/forums/flat.jsp?forum=106&thread=87182 ) have not been implemented. I was thinking that duck-typing style limited interfaces (no types, just method names) might be very useful, emphatically not for sake of pychecker, faster code, or forcing (dumb) programmers to follow (smart) architect's design, but as means of easy synchronization between 2+ programmers.

So, apart from typical but not working very well suggestion of "more documentation" (nobody wants to write it really), what are your means of synchronization high-level design and conceptual integrity on such large, multi-person projects?

(in part I ask because large projects I have participated in never used Python)

I heard objections mentioned above in person: At least 3 times when talking to startups (2 Scala startups, so they have slant towards static typing) and at least once within corp when considering various programming languages for projects. On the web: can't remember this now, I have vague memory of reading it on some OO blogs and forums. Static typing guys (Java, Scala) seem to have had big on this point, even though typically static typing and interfaces are usually meant for other things (speed, IDE autocompletion).

Note I know TDD defense on this but the problem here is that it is defensive since typically it's one person that writes unit tests. Of course, one could envision 1+ programmers sitting down together and writing unit tests before coding as sort of indirect spec + test but have you seen it done? I haven't. I also feel that unit tests, even written by groups, are not quite (limited) design or spec. They are low level after all. There's a reason (good maybe?) that Java has interfaces in addition to and not instead of JUnit.

share|improve this question
    
could you please give example(s) where you've seen "objection" you mention? also per my recollection of Eckel's article Why I love Python, the solution for issues like that is considered not "more documentation" but rather more tests –  gnat Jan 24 '13 at 11:31
    
In person: At least 3 times when talking to startups (2 Scala startups, so they have slant towards static typing) and at least once within corp when considering various programming languages for projects. On the web: can't remember this now, I have vague memory of reading it on some OO blogs and forums. Static typing guys (Java, Scala) seem to have been big on this point in my experience (YMMV of course), even though typically static typing and interfaces are usually meant for other things (speed, IDE autocompletion). –  mrkafk Jan 24 '13 at 11:35
1  
Note that you can use interfaces in Python. zope.interface provides exactly that. The interfaces are not enforced but you can verify them in unit tests. I don't believe that the problem you talk about exists though. –  Martijn Pieters Jan 24 '13 at 12:35
4  
And if it is 'typically one person that writes unit tests' then you are doing it wrong. Every developer needs to write unit tests. –  Martijn Pieters Jan 24 '13 at 12:37
1  
gnat's link points to a Zip file with no filename. Just mv mv LovePython LovePython.zip to get to the zipped powerpoint presentation, which LibreOffice seems to display just fine. –  dotancohen Jan 24 '13 at 13:20
show 9 more comments

2 Answers

up vote 2 down vote accepted

I like GlenH7's answer, and I believe there is truth there.

However, my perspective is that the answer to your problems is Code Ownership.

If five large teams are re-using the same model classes, and want to pile on unnecessary crap into them, then the only way out is to say "Team X owns this code, if you want to change it talk to them". Or, "John owns this code, if you want to change it talk to him."

You still need communication, but the nature of it changes. The assumption is that your request for change will be shot down unless there is a very good reason to put it in. Also, this creates a decision making body with final say, rather than co-owned code being modified by a 'design committee' (which frequently leads to either chaos or analysis paralysis).

Consider this also: there is nothing magical about Java interfaces. They give some design hints from the (hopefully smart) architect, but they don't protect against someone who needs a quick hack from going in there and changing your interfaces anyway. The only thing that really protects from that is code control, code ownership, and some degree of personal responsibility.

So if you're facing "interface" madness, designate responsible people for it and allocate code ownership. Make sure these people do their jobs.

share|improve this answer
1  
Ownership without proper accountability and oversight is a good recipe for endless chaos. Eisenhower threatened to resign his command if the powers that were would not place the airborne and bombers under his command for the invasion of Europe. –  gahooa Jan 24 '13 at 20:16
    
@gahooa Well that's the idea. Once you own it, you are responsible for it. If everyone owns it, then everyone (no one?) is responsible. –  MrFox Jan 24 '13 at 20:19
    
@suslik: re changing Java interfaces - yeah that's what I wondered too, if somebody wants to mess with a class or even abstract class in Java, why not mess with interface too? :-) Technologically there is no barrier to do it: however, the way people TREAT interfaces is as if they were sort of holy cows: theoretically you could slaughter it, but... they feel sort of "sacred", put above mere classes where you work all the time. Interfaces in Java are treated - for purely psychological and cultural reasons I think - as sort of "medium level design". At least that's my experience. –  mrkafk Jan 25 '13 at 9:05
add comment

I think you're focusing too much on the language that you are using and not the real challenge that's facing you and your team. Remember that there aren't any silver bullets.

Ultimately, your problem is governance. As governance is really the only way to ensure conceptual integrity for any project.

The need for governance follows either a linear or exponential path correlated to the size of the team. When you add in geographic and cultural divides, you're simply piling on to the need for governance.

There are some simple ways to get started.

If no one wants to write a whole bunch of documentation, then make sure code is commented liberally and correctly. Avoid littering with your comments, but make sure others understand the contracts that each section of code is fulfilling.

If you don't want others accessing particular parts of code and you can't encapsulate it, then you should be putting comments around those areas to indicate what can and can't be used. Even if the language doesn't directly support it, you can still mock up interfaces and closed objects within the code. FWIW, I've written OO style code in C. It can be done.

One of the ways you enforce that encapsulation is code review. The tribal elders from each team needs to review all new code before it's allowed into the build. If you have an architect, then they need to be in constant communication with the tribal elders to make sure they understand the vision and that everyone is in agreement with how the project will be built.

Management has to back the architect and the elders at the first skirmish. Someone is going to break the rules and insist it goes in because you're behind the deadline. Don't do it. Politely slap the violator's wrist; force them to fix the code; then allow the commit. Management has to back missing the deadline to guarantee the integrity of the project. Yes, you missed a deadline but you have to focus on the long term goal.

As mentioned in the comments; everyone should be writing unit tests for their code. Assigning that task to a single person is setting the project up for failure. Use those tests to enforce the encapsulation and rules needed to stabilize your project. If new code doesn't have a unit test then don't allow the requirement to be marked complete.

Ensuring the integrity of a project is everyone's responsibility with each tier taking on differing aspects based upon their own job function.

share|improve this answer
    
@Glen7: I like your answer a lot actually but it is wider re good project management (it should be pinned up on pm stackexchange somewhere I think - is there a wiki here or smth?). Code ownership seems narrower issue here and it just happens to be particularly severe problem area for my team (more so than other areas from my POV) so I'm marking suslik's answer below. –  mrkafk Jan 25 '13 at 9:12
    
@mrkafk - thanks for the update. Always feel free to select the answer that best applies / fits to you. It's your question, so it's your choice for marking as answered. –  GlenH7 Jan 25 '13 at 17:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.