I began building BigOven.com, the social network about food that makes you a better cook, in late 2002. The recipe software went to beta in 2003 and the site went live in early 2004.
What started as a solo effort is now a nicely-growing, cash-positive “virtual business” that has 575,000 registered users at this writing and serves between 2 and 4 million unique users per month.
Looking back on the project, there are four things that I wish I’d done sooner:
- Get the software hosted on Subversion
- Bring in Professional Design Sooner
- Add an auto-emailing function whenever a site error occurs
- Adopt an inbound support ticketing solution
I thought I’d share these lessons with startup developers… and also remind my future-self if I ever do this again!
1. Host Your Code on Subversion (or Some Version-Control System)
Believe it or not, I think the single most leveraged thing I’ve done over the past five years is to get all the code hosted in a version control repository. Specifically, it’s now hosted in the open-source platform Subversion, using the excellent VisualSVN server to host the code.
After four years of solo-hosting, I finally got the code hosted in a version control system a year or so ago. I had dabbled with Visual SourceSafe off and on, and found the “exclusive locking” model really, really cumbersome. Half the time I wanted some code, it was “checked out” on another machine somewhere, and it just became a bear.
Over the past five years, a different and much better model of version control has emerged. Subversion (SVN) uses a non-exclusive file checkout/check-in model that makes it much, much simpler to work with on a daily basis. It took a morning to get it configured, and it’s not as scary as it sounds at first to the one-time solo developer. It allows instant scaling up of the development team. More imporant, it allows you to hire talent from anywhere – and code can be worked on around the clock. You can configure it so that the entire development team is emailed when check-ins are made, keeping everyone in synch.
When I started out, I was simply hosting the code on my development machines in the Lakefront Software labs here, and letting developers/designers contribute “offline”, and then one of us (usually me) would then integrate their contributions myself. This made me a huge and painful bottleneck in the process. Now that the code is hosted in an Internet-aware version control system, I can bring on developers and designers nearly instantly, and apply focused expertise to areas of the code. Work is proceeding with higher quality and quicker than ever before.
There are other benefits to version-control, such as logging history, backtracking to prior revisions, etc. But by far, the most valuable to me is that it allows a software engineering team to truly scale-up.
2. Design Matters. Hire Professionals as Soon as You Can.
This may be preaching to the choir for many of you, but while I always knew that design mattered, I postponed great design a little too long.
My “programmer art” is better than average, I think, but one need only look at the old logo and new logo to see that design matters:
| Before | After |
We worked with the fine folks at Pixelube to come up with a great redesign for BigOven about one year ago. It wasn’t inexpensive, but the benefits are significant and far-reaching, and I couldn’t be happier with the outcome. (This major site redesign did cause our search engine presence to take a bit of a hit, but it’s returning to pre-design levels nicely.)
3. Make Sure All Site Errors Are Emailed To Development
If you’re developing a website, make sure your site automatically notifies someone whenever an unhandled exception occurs. It’s not quite enough just to log these errors – you want to reduce the time between when the error happens and when someone knows about it.
There’s a temptation to assume that a site will work as flawlessly as it appears to run in the test labs.
ASP.NET makes this kind of notification trivial. Here’s the code that does it for BigOven:
In “global.asax.cs”:
protected void Application_Error(Object sender, EventArgs e)
{
// get the exception details
Exception ex = Server.GetLastError( );
if (ex.InnerException != null) ex = ex.InnerException;
// GET THE CURRENT DATE AND TIMEif (DisregardError( ex.Message )) // you can ignore certain errors if you wish
{
return;
}string dateTime = DateTime.Now.ToLongDateString( ) + ", at " + DateTime.Now.ToShortTimeString( );
// build the error message
string errorMessage = "Exception generated on " + dateTime;
System.Web.HttpContext context = System.Web.HttpContext.Current;if (context.Request.IsLocal)
{
return; // don't send emails for local (development) errors
}
if (context.User.Identity.IsAuthenticated)
{
errorMessage += "\n\nUser: " + context.User.Identity.Name;
}
else
{
errorMessage += "\n\nUser - not logged in";
}
errorMessage += "\n\nPage location: " + context.Request.RawUrl;
errorMessage += "\n\nIs local:" + context.Request.IsLocal.ToString();
errorMessage += "\n\\nUrlReferrer.AbsoluteUri: " + context.Request.UrlReferrer.AbsoluteUri;
errorMessage += "\n\nMessage: " + ex.Message;
errorMessage += "\n\nSource: " + ex.Source;
errorMessage += "\n\nMethod: "+ex.TargetSite;
errorMessage += "\n\nStack Trace: " + ex.StackTrace;// email the message
try
{
utils.SendFromChefMail( errorMessage, "Site Error");
}
catch (Exception /*myex*/)
{
// catch the errors here
}}
4. Adopt an Inbound Support Ticketing Solution
If you have your support inquiries coming to a single alias, one of the best ways to ease your workload is to adopt a support-ticketing system.
There are many great solutions for this; BigOven chose to deploy Zendesk. This fine product lets users submit support requests, and we can now scale out our support team, measure timeliness of response, and much more. It’s definitely taken the professionalism of the experience to the next level.
Interesting article, thanks.
I am appalled when I hear about developers *not* using a code/config/version control system, such as Subversion. Even if you are a solo developer (like me) I can't think of any reason why you wouldn't use one. Once you have a VCS you'll never want to go back to not having one.
Posted by: Andy Brice | September 25, 2009 at 02:42 PM
Hey Steve, who are you using for hosted subversion?
Posted by: Marcelo Calbucci | October 02, 2009 at 07:13 AM
Hi Marcelo, I probably shouldn't have used the word "host" -- my SVN repositories are hosted locally here in the labs.
Posted by: Steve Murch | October 02, 2009 at 07:38 AM