When I started SimplyBox with a few other guys, I was the only engineer on the team.  My experience at Yahoo! and prior to that iKorb, benefited me immensely in the early days of getting that all too critical development set up needed for a smoothly oiled machine when things begin to get really busy.  I’ve found that it isn’t so much how to set things up that’s difficult, it’s knowing where to get started, and what pieces are really needed when you begin to bring on other people.

1.  Development Machine

Likely you already have a laptop or a box at home.  You most likely have set up some IDE, or you are using something like Emacs, or VIM, BBEdit, or Eclipse.  Perfect.  To take it further, though, you need to install a web server on your local box.  As well as PHP and MySQL (assuming those are what you are developing with).  Yes, you can use Dreamhost or MediaTemple and just keep uploading to them ( Coda from Panic is designed for that development flow specifically ).  However, unless you plan to use that server as a development machine and NEVER a production machine, that flow will work.  The day you begin to use your production machine as your primary development platform, you will begin walking down a dangerous path that will lead you to one day say “CRAP! I have looped something I shouldn’t have and it’s eating up the cycles! I have to restart apache or the box itself!” It is at that moment you will remember you read this and begin to cry the tears of the damned.  Save yourself early, take the time to get your development environment on your local machine.  It’ll save you all that upload time, and a little engineering angel will get it’s glasses. 

2.  Versioning Control System

All too often I hear from other webdevs that a version control system (like CVS, Perforce, or  Subversion), are not really necessary.  I laugh a hearty laugh, slap them on the back, and thank them for improving my health.  A version control system is critical even if you are the only developer.  Why?  For starters:

• It’s a lot cleaner than having to make “backup 1, backup 2, backup 3″ folders on your computer (or worse on the remote machine)
• It allows you to create branches of code at different development points to go back too when things go bad
• You can regress individual changes on specific files
• When you do get more developers (and I imagine if your startup goes anywhere, you will), you can make sure Fernando doesn’t overwrite changes you’ve made, causing you to lose last nights moment of genius
• You can tie it into bug tracking apps (more on this later), to associate specific file changes with a specific fix.  This is remarkably helpful when you need to refer back to bugs that “you swore you fixed”.
• If you host your versioning system somewhere else, you have an additional backup of your code
• You can easily set up new development machines
• You can buy witty t-shirts and baffle your enlarged-foreheaded friends

3.  Bug Tracking

This one fewer devs toss aside like the Version Control system.  Most people recognize the value of a bug tracker, but very often people forget to consider it when they are setting up their environment.  This is usually because if you’ve worked at a large company, someone else did it for you and you didn’t have to go through all the necessary work to get it up and running.  It’s worth it though.  Bug trackers like Mantis or Bugzilla provide excellent integration with Version Control systems, and can organize the development process extremely well, simplifying the planning and releases.  They also are an excellent way to sanity check your progress and to manage expectations with the rest of the team.  In short, they should be considered required from day one.  The biggest challenge you will face, though, is not the set up, but having people enter intelligent bugs.  All to often you, or others, may be tempted to lump a bunch of issues into one bug.  Those are unresolvable behemoths that will quickly degrade the value of the tracker, and convert you slowly to the dark side.  Yoda once said, “Poor bug entries lead to anger, anger leads to hatred of the reporter, and hatred of the reporter leads to a suffering product.  And leukemia.”

4.   Group Calendar ( or Groupware, in general )

Without a doubt, you will be involved in meetings that someone scheduled, completely oblivious to the 10am – 4am work schedule you are on.  In your Mountain Dew induced haze, you will get a phone call asking if you are going to attend the meeting or not.  To which your response should not be “when did you set this up?  I kill you now.”  rather it should be “of course I’m attending, and I’m gonna rock your socks with my genius input.”  This only happens if you are aware of, and ready for, yet another meeting.  They are important, as your input is valued (which is a good thing), to steer the company.  Having a group calendar is essential to this coordination.  Most public applications like YCal, Google Calendar, or more sophisticated eGroupWare apps work fine for this, as long as everyone uses them. 

5.    Mailing Lists

This is an interesting one, and often overlooked.  Having some form of a mailing list enables you to set up help, feedback, bug reports, and other necessary customer -> you inputs.  Setting up internal lists also saves you a lot of repeat email address typings when sending out messages to the group.  Mailman is one that I personally like for this, as it’s simple, pretty full featured, and private.

6.   Wiki 

While you may not need this right away, it’s a good idea to start one as early as possible.  Inevitably you will encounter a scenario where you need to explain how to do something to someone else on your team.  The old adage of “if you have to do it twice, it’s worth automating it” in the world of Unix still applies.  In this case, though, you aren’t automating, but you are documenting.  It’s hard to pull yourself away from development, but it’ll reward you with far far less “I told you how to do this already” moments.  It also lets you post your awesome sense of humor for all to enjoy.  I like phpWiki for it’s maturity and feature set.

7.  Documentation  

I don’t think I have to explain why.  It’s that little angel that sits on your shoulder every time you look at your own code.  You ignore it, but it just keeps talking to you.  Eventually you go to the doctor because the voices become so loud.  But then one day you forget your medication and you hear it again, only this time it’s a bit more angry and tells you how everyone knows you don’t document your code, and how your neighbor watches you while you sleep.  Best thing you can do…. start documenting.  Document while you code, while it’s still fresh.  A good friend of mine makes it a habit to write the documentation first, as sort of very light pseudocode to nail down the API, before fleshing everything out.  I admire my friend for that, as I, too, forget my medication from time to time.  To ease the pain and frustration of documentation, I can not more highly recommend Natural Docs .  Not only do they generate beautiful documentation, with very simple code comments (far more simple than the old JavaDoc style), but they also have slick features like search, lists, and a very easily extendable platform for languages (they currently support 19 languages) that may be somewhat proprietary (like good ol’ Konfabulator syntax). 

Conclusion 

I know that 7 suggestions is an odd number (“ha ha… it’s funny because it is an odd number, and it is also means strange amount!”) to provide as a list.  However I have found that this combination is very effective at getting a solid set up for development both now and in the future, when more people join the team.  Of course, you can do less than what I’ve listed, but then again, you can also do your graphics with Microsoft Paint (your welcome).  The applications on this list come from plenty of experience of the downsides to not having them.  In any middle to large size software development company most, if not all, are already provided.  They learned the hard way why that is, as they like to waste money far less than you like to waste time.