Related link: http://www.cdbaby.com
There are two projects about to start at the same time: CD Baby and Filmbaby.
Both are almost identical. One sells CDs by indie musicians. One sells DVDs by indie filmmakers.
For Filmbaby, though, I was going to stay out of it, and let another programmer do it all. I’ve got enough on my plate. I figured I’d just let him use anything from my CD Baby code, to make Filmbaby.
But right now the CD Baby code is a mess. I’m just about to re-write it from scratch. (Timeline: I could start any day now, and probably finish in 2 months.)
If he were to start now, and borrow code from the existing CD Baby, then he would be borrowing messy code about to die anyway. (Or have less to borrow because it’s so messy, and un-borrowable.)
So I’m trying to decide what’s the best way for him and I to make these two projects, since they will be almost the same, and almost at the same time.
APPROACH #1 : I START CD BABY ALONE, FILMBABY STARTS NEXT MONTH
I start coding CD Baby now, by myself, setting up the basics the way I think it would be best. In a month, he starts Filmbaby alone, borrowing whatever he needs from my CD Baby coding.
APPROACH #2 : HE STARTS FILMBABY NOW, I START CD BABY WHENEVER
He starts coding Filmbaby now, however he thinks it’s best. I start rewriting CD Baby later, and we probably borrow bits and pieces from eachother’s stuff.
APPROACH #3: WE BOTH SIT DOWN AND WRITE A SHARED BASE
We both write this together : a new codebase that will work for CD Baby and Filmbaby together. Leaving most things generic until the end when we fork it off into the stuff that is just for CD Baby, and just for Filmbaby.
APPROACH #4: I START WRITING A SHARED BASE, HE JOINS IN LATER
I could start writing that shared base myself, from my experience with what’s needed. In my mind, I’d actually be writing the generics of the new CD Baby, but keeping it non-specific to CDs, so that the same stuff could be used for Filmbaby.
shared code whereever possible
Avoiding code duplication is probably the way to go. Create a shared codebase, either together or on your own, and use that as the basis for both projects.
Or maybe even better, find enough common ground that only the user interface (JSP, ASP, whatever) need be different and the entire backend generic?
Code it together ....
... you don't want him bitching at you when you get it wrong.
A problem shared is a problem you can blame someone else for.
Code it together ....
I'm being ficicious of course.
Designing/coding together with someone else can be fun, informative, and, most importantly, can lead to a better system.
Way old fashion idea
I am from the DESIGN DOZEN, CODE ONCE school! As a system DESIGNER for 15 years, I have seen TOO many project flounder because of lack of DESIGN!!!! PLEASE, BOTH of you sit down with a good OO Designer FIRST. Spec it out on TP paper but spec it out.... I know, as a coder also myself, I want to jump into the code and make it work BUT as a TRAINED and EXPERIENCED SYSTEM DESIGNER I know better and have eaten it way to many times....
Find an OO Designer. Pay 'em whatever for about two to six weeks while you are holed up with all your programmers AND a GURU USER and a NEWBIE but smart user. Story board it. Patterns will emerge and those patterns are your code MODULES. The GREAT thing about OO is the black box approach. You can assign coding modules out to people and if the deign is there for inputs and outputs (parms), they can be tested independently and all can be coded in PARALLEL. Just add more worker-bees.....this is the outsourcing model, but THAT'S another story...
shared code whereever possible
I agree with poster which says agree on a design,
down to the details of concrete APIs.
Walk through the whole appl on paper (can be
at a pretty high/abstract level) and
then implement. U cant go wrong.