Liquid Labs – What's in Your Stack?

In this edition of What’s in Your Stack?, I ask the proprietor of Liquid Labs, Zane Rockenbaugh, how he runs his small, 3 person software development shop focused on client-driven project:

Who are you?

Liquid Labs is a small development and consulting company. Most of our business comes from soup-to-nuts, bespoke web development for small companies, start-ups, and individuals. Currently the company consists of myself and two part time contractors.

How would you describe your development process?

The most important step is to understand what the customer wants and needs. In terms of concrete process, we have high level boxes to tick, like “get the customer a proposal,” but forms and format are often dictated on a case-by-case basis.

In some cases, the customer gives us an idea and we run with it. We do agile-ish development, so the customer can follow along, but the process itself is a black box.

In other instances, the customer comes in with an existing product and/or process. In those cases, we may make suggestions, but part of our job is going to be to fit in with their existing infrastructure and process.

In broad strokes our process is definitely Agile-ish. We get something working fast. We always make sure testing is part of the equation. We engage the customer in on-going dialogue. Specifics, however, would vary from project to project. One might use JIRA, another might use note cards, another a spreadsheet.

What tools are you using?

Lots. On the web side, we’ve got active projects in:

• Classic AJAX (JavaScript+XML)/PHP/Apache/Postgres
• Java/JSP/Tomcat/Apache/Postgres
• Java/GWT/Tomcat Apache/MySQL

We’ve also got a number of desktops app written variously in Ruby, Bash, and Perl. My experience with frameworks is that they really come and go, so if anything, I’m leary of including frameworks in keystone positions.

My favorite tool is probably FireBug. JavaScript’s weakness has always been debugging and editing tools, but FireBug is probably the best runtime visualization and debugging tool I’ve seen.

For version control, it’s SVN. We’re going to migrate our opensource components to Github and are evaluating whether it’s whether or not we should migrate the private SVN repos.

We use many different IDEs and editors. Most have a lot of overlap while some are very useful in specific circumstances.

It’s a similar story with task management tools. We use lots of different bug/task/process management tools. Partially because of client demands, partially because I’ve never found one that hands down fits everything we need to do. Here, I feel like there could be a good solution for us, but either it hasn’t been built yet or we just haven’t found it.

Generic Linux is a common thread, but even here we’ve got projects on XEN/OpenSUSE, as well as EC2/Fedora. We also deal directly with physical infrastructure issues.

If we use a web server, it’s Apache. If we use a app server, it’s Tomcat.

Is it a problem keeping all this straight?

There’s some cost, yes. If we specialized on a rigid tool chain, we could get some efficiency gains, but it would also be limiting and I’m pretty well convinced that for us, the benefits of flexibility outweigh the gains of tool-level specialization.

This wouldn’t be true for everyone, so I’m not fighting the common wisdom so much as saying that Liquid Labs itself is in a different situation. When I look at two programming languages, I immediately think “These things are both 95% the same thing”. To me, they look like very closely related dialects of an arch-typical Turing machine interface. (Prolog would be the one exception of which I can think). Moving between PHP, Ruby, JavaScript, etc. feels to me like I’m changing accents more than changing “language”.

The benefit is we can customize the stack for each project to whatever works best. This is usually “whatever makes the customer happier”. Usually there’s some keystone components where technical considerations dominate. You may need EC2 for some reason, or you may find that the perfect library that does the hard work for you only exists in Java or whatever. But for the most part, it doesn’t make that big a difference technically, so we’ll fit the stack to the project.

Also, for more, check out this interview with Zane from 2007: