Hyper Productive Programming

A couple of years ago, I started a payments company with a (non technical) co founder. We teamed up just before the stock market tanked, and needless to say, had a hard time raising money. Eventually we did raise some VC, but not much. Anyway, we had to build the product and the company on a shoe string.

I started developing a philosophy, born of necessity, of hyper productivity. There has always been the myth of the super programmer (think of the evil geek from Jurassic Park). The dude who can do it all. Generally this falls under the category of Hubris, and yet... with todays technology (open source and cloud computing), it is in fact possible for one or two good engineers to build and run a fairly complex software enterprise.

Cloud computing allows a software engineer to let somebody else, such as Amazon, worry about the hardware. The cost of using a service of Amazon is so much cheaper than buying equipment and staffing an IT department that it's really the only way to go.

Google Apps provides an intranet in a box. Group Scheduling? Check. Email? Check. Shared Documents? Check. The free version is fine for a small organization.

Leveraging appropriate software engineering tools keeps things productive. We use a Java stack with Hudson and Ant for build automation, Ivy for a repository, Junit for test, Eclipse IDE, GIT for source control, and Jira for bug tracking. It's what you'd expect to find in any large organization. Except that, uh, it's just me.

It seems like a lot of infrastructure, and it has certainly taken time to put all the pieces in place. But I don't regret any of the time spent in building the infrastructure. It's all paid dividends. If an outside observer were to look at our software stack and engineering infrastructure, they would easily believe it was supporting a serious software organization. And it is. Just a very small one.