Today I bring you the first in what I hope will be an entire series interviewing startup developers on the technical speedbumps they faced in bringing a web based software product from conception to production.  Today’s interview is with Ian Lotinksy, one of the two founders of SandwichBoard a web based CMS targeted at restaurants.

If you are interested in participating in an interview and getting some free publicity for your product, or know someone who might be, please use this form to let me know.

The interview is after the jump

In September you and Patrick Joyce decided to build SandwichBoard.  Were you already Ruby on Rails developers?

We were not doing that for work, at work we were dealing primarily with ASP.NET version 2.0.  We started with ASP.NET 1.1 and upgraded some sites to 2.0.   We were also doing some development in J2EE and were doing client side languages and so on.

Had either of you played with Ruby on Rails before or was this an extra step you took to learn this?

It was an extra step for me.  Patrick had been dealing with Ruby on Rails for I believe an entire year prior to our departure.  He had built an invitation *web app* called easily invited which was supposed to be an improvement on eVite.  I don’t believe it is hosted right now but I think he has plans to re-host it.  He was initially hosting it on Amazon’s EC2 but he wasn’t getting the traffic he needed to justify the cost of hosting of about $75 a month I believe it was costing him to keep the website running.  He decided he wanted to switch it to something else, but I don’t think he’s had time to do that recently.

So, he had experience, I didn’t. I had been following it from an onlookers standpoint.  I was reading about it. Reading blog posts about it, absorbing some of it.  But it really wasn’t until May that I just went out and bought the Agile Web Development with Ruby on Rails Development, the Pickaxe book, Chad Fowler’s Rails Recipes Book & started building a toy application.

So were you already used to Agile Development?  Because you did Agile / Extreme Programing on top of Ruby. Was that new to you as well?

As a formal practice yes.  At Lockheed Martin we’d used the waterfall method to develop our applications.  With our last big project at Lockheed, Patrick and I were on the same team.  We weren’t able to convince management to let us do it in an agile way.  But we ended up doing it in an agile way in that we took the requirements that were known and take a stab at implementing them.  We’d then present it to either the customer that was paying for the project or the user that would be using the project and then do the changes.  So we would do these small iterations.  I wouldn’t call them Agile iterations because they were a little bit longer than a week or two, But it was a break from traditional waterfall method.  It was a bit of a relief for us, at least in our environment.

You chose to develop on a Mac, is that something you’d done before? 

Patrick had been using a Mac.  He had purchased both a Mac Mini & a Powerbook and had been using them for a little over a year as well.  He really liked the integration of Unix and because a lot of the material that was already out there on Rails assumed you were using a Mac and because of the power that Patrick saw in Mac OS.  He basically made the decision that we were going to use this.  So he gave me the Mac Mini to use during the project. I’ve been using it as my primary machine.  So, I had to learn that with a little help from Patrick.  Whenever I got stuck I had to rely on just Googling stuff.  There are several white papers that IBM has on UNIX so I read those to get familiar with all the different commands.

You had to do a lot of learning, especially relative to your partner.  How did that work for you guys?

The good news is that Patrick had lots of experience.  When I was at Lockheed I developed a habit of being able to learn stuff quickly.  Usually what that looked like was not trying to understand everything about the particular technology but to get at  the main point of each technology?  What are the main features? What’s the power behind it?  What’s the strength that it has?  I focused on the core competencies of each language and framework.  Once I learned that if I needed to look up something that was more obscure or hard to understand I could do the research to find it.  I figured out I could do just as well focusing on the core of the technology.  That sort of mentality lent itself to learning Ruby on Rails as well.

What’s nice about Ruby on Rails as well is that it’s a very opinionated framework. Typically, there’s a best way of doing things and that really helped me.  It wasn’t that there was 2 or 3 ways of doing things.  Rails is opinionated and it chooses this one way of doing things.  If you want to take a different route you could, but it’s difficult and most of the decisions that they’ve made is stuff that I would agree with naturally.

Also having books and blogs that I was visiting helped.  Railscast is a blog by Ryan Bates of 2 to 5 minute videos you can watch.  He just does little tasks in Rails and teaches you different aspects of it.  Watching those consistently and using a lot of plugins and open-source helped as well.  The Rails Community has a lot of developers who are a little bit more mature than your average ASP.Net developer, so you know the code your looking at, while not perfect, is likely better than your regular ASP.Net web application.  We had the ability to look at some really nice Rails code that gave us the ability to learn that way.

About how early in the process did you bring in your beta testers.

We brought them in in late August / early September.  We had been doing development for over a month and had the basics of our web app done.  That’s when we started talking with them and getting them started.  One of them was running off our stuff in October.  We’ve just been staying in touch with them periodically and watching their sites pretty closely just to see how they’re using it and how things are performing.  Just to make sure that it is running the way they expect it to run and that they’re using all the features that are there.

We’re about to push our latest and last revisions to the code-base before going to public beta.  Once we get that pushed out, we can really push hard at the marketing end to really get people signed up and using it and giving us a lot more feedback.

How much feedback did you actually have with your beta testers?

It’s largely been over telephone, a little bit over email. What it’s looked like is just calling them up or sending emails saying “How’s SandwichBoard functioning for you?  Is there anything you’re running into that’s a problem?  Are there any features that should be added?”

So far we haven’t gotten many comments about things that haven’t worked or worked well.  The best comment we’ve gotten wasn’t from one of the beta testers but was instead from one of the beta testers girlfriend who was upset that her boyfriend was up til 3 AM working on his restaurant’s site because he was having too much fun.

Looking back, are you happy with some of the decisions you’ve made?  Are there things you would have done differently?

No, I think one of the strengths of what we’re doing and our team is really Patrick’s ability to evaluate the scope of our project as well as direct the architecture of what we’re building.  In “Mythical Man Month”, Fred Brooks talks about having an architect on the team.  The architect may not be the only one with ideas, but he’s the one responsible for the overall architecture for the system. He’s the one who chooses what goes in and what goes out and how things are implemented.  We discussed early on before we started coding just how we were going to work and I suggested he take that role because of his technical aptitude, his prior experience with Rails and Mac OSX and his ability to learn things quickly.  I thought “he needs to be the architect of this” and so far that’s worked well.

Any final remarks?

Making the commitment to leave secure jobs to go do this, although assumes some risk, has been quite enjoyable.  We’ve learned a lot doing this so that even if this fails miserably, we will have taken away a lot from the experience.  From the frameworks we’ve used, the open-source code that we’ve seen and the architecture that we’ve been able to piece together has made us stronger developers.  Even if this only means a four or five months hiatus from being part of a larger organization it will have paid off in making us better developers.

About Ian Lotinksy

Ian Lotinsky (ianlotinsky.com) is a cofounder of SandwichBoard, located just outside Washington, D.C. If he’s not helping restaurants with their online branding, he’s probably spending time with his family, his friends, or his Lord.

• No Related Post