Best practice- How to team-split a django project while still allowing code reusal

Question

I know this sounds kind of vague, but please let me explain- I'm starting work on a brand new project, it will have two main components: "ACME PRODUCT" (think Gmail, Meebo, etc), and "THE SITE" (help, information, marketing stuff, promotional landing pages, etc lots of marketing-induced cruft).

So basically the url /acme/* will load stuff in the uber cool ajaxy application, and every other URI will load stuff in the other site.

Problem: "THE SITE" component is out of my hands, and will be handled by a consultants team that will work closely with marketing, And I and my team will work solely on the ACME PRODUCT.

Question: How to set up the django project in such a way that we can have:

• Seperate releases. (They can push new marketing pages and functionality without having to worry about the state of our code. Maybe even separate Subversion "projects")
• Minimize impact (on our product) of whatever flying-unicorns-hocus-pocus the other team codes into the site.
• Still allow some code reusal.

My main concern is that the ACME product needs to be rock solid, and therefore needs to be somewhat isolated of whatever mistakes/code bloopers the consultants make in their marketing side of the site.

How have you handled this? Any ideas? Thanks!

Answer 1

Django's componentization of apps means that you can have independent teams working on the various apps, with template tags and filters (and of course, normal Python functions) used for cross-app coupling.

Answer 2

I doubt the amount of code reuse you can get between the two projects, given your organizational situation, is worth the headaches, organizational risks, and delay risks that it would entail -- after all your team can never rely on the other, since

the ACME product needs to be rock solid, and therefore needs to be somewhat isolated of whatever mistakes/code bloopers the consultants make in their marketing side of the site.

This being the case, I would, at most, have the ACME team sometimes release a few little underlying libraries for the other team's use... but even that is fraught, unless used with wildly severe constraints, since one of the bloopers the consultants may make is to code with dependencies on the library's implementation, so ACME basically cannot keep maintaining the library after releasing it for the consultants' use (ACME might think that keeping APIs constraints would be fine, but they can't deal with the other team's reuse-bloopers).

Although one would need to know many specific details, it doesn't appear that the deep underlying commonality between the two teams' projects, at application layer, is all that much anyway (third party stable open-source projects providing common application-independent functionality can of course be used by either or both teams), so the costs of encouraging reuse would not correspond to commensurate returns anyway, from what we can judge looking from "out here".