We often maintain and deploy projects as a single HEAD version in a Subversion repository. We don’t, generally, tend to do a lot of forking. This is good, as forking can be undisciplined, but sometimes you might want to be able to add or change features and not have to worry about adding broken code to a project.
It turns out that Flickr does the same sort of thing. Their solution: flags and flippers. Interesting read.
Innova has tried a few things in the past to keep our projects organized. We have an internal Wiki that we use for sharing data, fileservers every five feet for document sharing, an inter-office Jabber server that keeps our IMs going. We use FogBugz to track bugs, Harvest to track time, and emails and sporadic meetings to tie everything together.
On larger projects that span more than three people, this tends to break down a bit. The individual tools are awesome, but emails and occasional face-to-faces just weren’t getting the job done. We just couldn’t keep everything organized amongst everyone with such an ad-hoc system.
If you’ll excuse me for a few minutes, I’m gong to be a language missionary. I could apparently be a better programmer if I avoided this, but we all have our parts to play, and I like mine.
At Innova, our default language is PHP. We make this decision by default, it’s assumed that a new project is going to be done in PHP, because that’s what we use for everything else. And it’s certainly the lowest-common-denominator amongst our crew: Eddie enjoys C#, and Keith is in love with Python and Ruby, but we can all work and be productive (for varying levels of productive) in PHP.
Sometimes, a tool emerges that’s simply better. It maps 1:1 to your domain. For Innova, that’s writing kickass web apps, and the tool in question makes PHP look like an amateur rig. Imagine a major metropolitan newspaper that’s got a fleet of Xerox machines cranking out the Sunday edition, vs. the industrial printing machine they’ve actually got. That’s the difference. You can make some damn awesome things with PHP, for certain, but that doesn’t mean that you should overlook better tools when starting new projects.
Now, what do you do if you have an existing project that could benefit from ten tons of awesome framework, but you can’t just freeze the current codebase and begin porting? Do what I do: every time you’re spending time writing code to fix something that’s a non-issue if you’d only switch tools, mention it. Don’t get in anyone’s face, don’t do a victory dance, just point out that if you were using X, you’d be busy fixing real problems and not wrestling around with solved problems.
Then write blog posts with no less than five subtle links. Subliminal messaging is powerful stuff.
Being a missionary has its time and place, of course. Similarly, it goes without saying that there’s definitely a cost in switching languages and frameworks, and that sometimes that cost is too steep. But that doesn’t mean you shouldn’t be taking every opportunity to point out places where improvement can be had. I care about the company I work for, and I want us to produce the best possible work we can. Suggesting fixes for common development problems we’ve experienced is part of that caring.