Disclaimer: I totally disagree with the post below, and I’ve written a response to it here.

I’ve published two serious websites: helpd.org and cellarspot.com. Each has a similar success story (there isn’t one), and they were both developed in very different ways. The code we wrote for Cellarspot is super scalable and robust, and the code Eric Fisher wrote for helpd is inline. I wanted to share my thoughts on which engineering approach I think is better and why.

Helpd
The code written for helpd is all inline PHP – the same, single PHP file has SQL queries, HTML, and AJAX request logic. There aren’t any classes, and there are only a few functions to simplify SQL queries. All the engineers out there are probably saying to themselves, “What are these dudes thinking? Idiots.” No. Eric wrote all of helpd in 90 minutes, which let us very easily and quickly test the helpd idea to see if it would take off. It didn’t, so only 90 minutes were wasted (we’re going to try to rework the site, so those minutes weren’t actually wasted). Inline PHP allowed us to throw something up insanely fast to see if the idea would work. Eric and I are both students making websites in our free time, so we want to get things shipped as fast as possible to see who they’ll do.

Cellarspot
The code written for Cellarspot is exquisite and is written in JSP using Spring MVC and Hibernate. We have a data access layer, a business layer, a search framework, and an index framework, etc (see the end of this post for references). We pursued Cellarspot in a software engineering class at the UW, so it was our job to write robust code. We definitely succeeded, but it took five of us three months to complete the site. Five people working an average of about 10 hours a week for three months adds up to 36,000 minutes. That doesn’t even include the first version of Cellarspot I worked on and the newest version I’ve been working on.

So what are the lessons learned here? First, I don’t regret spending so much time on Cellarspot, and the reason why is because I learned a whole lot about software engineering, design patterns, and teamwork by pushing for awesome code. I’m super glad that I learned these skills. However, I’m also super bummed that I invested so much time in Cellarspot only to see it not do well. I’ve thought up two different cases and what I would do in those cases if I were you:

Personal Project Startups
If you’re spending your free time on a project, then your time is valuable. If you’re looking to learn about engineering, then spend time writing awesome code. If you’re looking to create a website that could potentially make you millions, then write something quick and don’t worry about the code. Keep in mind that if your project turns into a 300+ person company and you chose to write shitty code, then the chances of having to rewrite most of your code is high. I suppose there are worse problems, though, like spending hours upon hours on a project that doesn’t go anywhere ;). I think you should also consider your future when deciding on how you’re going to engineer your code. If you’re planning on being an engineer in the future, then spend the time to learn how to write awesome code. If you’re planning on being a PM or someone else more business oriented, then write inline code so you can get your product off the ground quickly.

I think that I should also touch on programming languages. Languages like PHP and Ruby on Rails are great for getting a site up and running quickly. Languages like JSP are great for learning about engineering, but that’s not to say that PHP and Rails can’t be used for good engineering practices.

Funded Startups
If there are more than a few programmers at a funded startup, then write good code. Your peers will appreciate it, and the programmers that will use your code in the future will appreciate it even more. If there are only a few programmers at a funder startup, then you can probably get away with writing bad code, but be prepared to improve it later. I think that if you’re getting paid, then there is no reason why you shouldn’t spend a little extra time to write good, robust code.

I’ve spoken to a few Redfin engineers, and most of them are insanely frustrated and annoyed with the terrible code that was written by some contractors back when Redfin was first started. We’ve had to refactor over and over again at Redfin because of that shit-ass code. I’ll save contractor work for another post, though.

I think that I approached helpd and Cellarspot in the right ways. My first project taught me great programming practices, and my second project made me realize that you shouldn’t always write good code. It’s up to you to decide how you want to engineer your startup.

Software Engineer Resources

• Coding Horror
• Joel on Software
• The Pragmatic Programmer
• Ship It

Update: I removed the “disgusting” adjective from Eric’s inline code. I suppose that I view all inline code as disgusting, even though his inline code was beautiful. The other advantage to writing inline code is that you can avoid dealing with multiple files.  Eric also wanted me to be more precise and say that inline code is great for prototyping, which is exactly what we did with helpd. Sorry about that, Eric!