OnStartups

Warning:  This is likely going to be a series of somewhat lengthy articles, because the topic is complicated and needs to weave in a number of conceptual threads, some technical and others strategic.  It will also include a bit of history to set some of the context for my decision making.  Feel free to ignore these parts if you choose.

This article captures some of my thinking related to the choice of language/platform for startups.  The current discussion was sparked by the introduction of a new member to our development team.  This new member has had some positive experience with Python as a language (and has been doing work that is similar to some of the work we’ve been doing in my current startup, HubSpot).  The deeper I dug into the rabbit hole, the more interesting the discussion has gotten.  I thought I’d bring the discussion to the blogosphere as a way to both refine my thinking and solicit input from the OnStartups community of readers.

Working For A Software Company
 
Before we delve into the issues themselves, I’d like to share a personal anecdote.  In my first real job as a programmer, I was writing code for U.S. Steel.   At the time, I was still working on my undergraduate degree at Purdue (major:  Computer Science).  One thing I learned, relatively quickly at U.S. steel is that those working at the company that were not making steel, moving steel or selling steel were “overhead”.  The programming group was seen as being little different from accounting, finance or HR.  I quickly made the decision to leave the steel industry as I didn’t want to be “overhead”.  I further decided that the only place to go where I wouldn’t be overhead would be a software/technology company where the product being sold was software.  As such, I found my next job at a large software company.  I figured that I’d learn much more and be able to contribute much more value to the organization if their revenues were being generated primarily from software products.  I could not have been more right.  Most of my early training and some of my best lessons came from this first job as a real programmer at a real software company.

Lesson 1:  If you’re a “career programmer” and really passionate about software development,  I encourage you to go work for a software company.  You’ll learn a lot and won’t regret it.

At this new company, the product was a large financial application (written in COBOL).  I was hired on to work on some “next generation” technology to build a Windows front-end for the company’s large legacy application.  Before I was hired, the company had picked Easel (a RAD development platform that was specifically created to easily build front-ends for large, mainframe-based legacy applications).  Most of you will likely have never even heard of Easel, but it was reasonably popular at the time.  Now, at this company we had a brilliant individual who had been with the company since it’s inception and had acted as “chief software architect” ever since.  The flagship product was his brain-child.  We’ll call him Warren (because that’s his name).  He was the programmer’s programmer.  He got it.  He understood the tradeoffs and constraints, he understood the business and had successfully built an application that was the company’s competitive advantage in the early days.  Over the long haul, I am convinced that the company survived (and thrived) in the face of stiff competition, primarily because the software was designed for ease of change as customer needs got more complicated and the market shifted.  The design wasn’t perfect, but it was much better than the competition.  Of course, the application was still written in COBOL so there were limits to what they could do.  One of the issues was that Warren was so good with COBOL development that he could do almost anything within it.  I remember some great technical discussions when we were talking about OOP vs. structured programming and he did some really exceptional refactoring of the core COBOL code that was “inspired” by OOP.  But, the fact remains that for the kinds of things we now needed to do, COBOL just wasn’t a good choice.  The complexity of developing rich GUI applications almost mandated OOP (along with an MVC design pattern and other stuff).  Trying to replicate OOP inside COBOL (which the COBOL vendors were in the process of doing) just didn’t really ever get there.  

One thing I quickly learned about Easel (it wasn’t a hard language to learn) was that what it provided in terms of short-term productivity, it lacked in long-term viability.  After working in objected oriented languages at school, it also seemed archaic and limiting.  My favorite development language at school had been Turbo Pascal from Borland.  So, I did some research and tried to figure out how other smart companies were solving this problem.  I discovered that C++ was a widely used, general purpose programming language for desktop applications.  It had OOP, large third-party support and an entire ecosystem around it.  This was in stark contrast to Easel which was constrained on just about all fronts.  So, I pushed for us to abandon Easel and use C++ instead (I hadn’t written a line of C++ code at the time).  To prove my point, I took a laptop with me on vacation and decided to learn the language and build a new front-end product on my off-time.  The learning curve was a little steep, but not that steep.  

At the end of about 6 weeks, I had a semi-working application.  I had built it all in my spare time and demoed it to management.  They loved it.  They productized it.  They started selling it to customers.  That’s how C++ got introduced into the company.  Easel (both the company and the product) is now pretty much dead.  There’s nothing at the website, and I’d be very ,very surprised if it’s still around (a quick Google search doesn’t turn up anything useful).

Lesson 2:  Closed languages owned by a single company without the resources to build out an ecosystem can and do fail eventually.  Sometimes a lot.  Sometimes completely.  (But, open source is a different ball game.)

Fast forward about 9 more months.  I ultimately decided to leave the company and go off on my own and kick-off my first startup.  Not because I didn’t like the company (I did) or that I wasn’t learning enough (I was), but it just “felt right”.  I’ll spare you the details of this decision in this article since that’s not the focus.  I picked C++ as the primary language for my new startup.  The reasons were obvious:  I already knew it, it was an expressive enough language, and I still liked the growing support within the community.  Lots of people were doing interesting things with C++ so I thought the language was not likely to die anytime soon (I was right).  C++ continued to serve us well and my startup built several successful commercial products (web and desktop) and we ultimately sold the company last year.  It was a happy ending.  At the time of the acquisition, our choice of C++ easily removed what could have been one point of discussion and contention.  I think the fact that we had used a mainstream language and that the acquirer already had programmers that used that language (and understood it), helped.

Lesson 3:  If you’re a startup looking to be acquired someday, your best case scenario (when it comes to technical platform choice) is not to be able to convince the acquirer that you made a good language/platform choice.  Your best case scenario is not to have the discussion in the first place.  Also, it is unwise to assume that the acquirer has the same passion for technology that your startup does or the same willingness to “evolve” to your line of thinking.

In my most recent startup, I originally decided to use C++ (on Microsoft’s .Net platform).  I felt this would give me the most “flexibility” (as I could do just about anything I needed).  Within a few months, I switched over to C# because of all the merits of a “contemporary” language that had things like garbage collection, reflection and a clean component model that actually worked.  So far, I’ve been pretty happy with my choice.  But, am I missing something?  If I could do it all over again, should I have picked Python?  That’s what we’re going to get into next.

Current Concern #1:  When looking at the C# vs. Python question, I am trying to get a handle on whether by bias towards C# is driven by my familiarity (and success) with C++ or by the true merits (both technical and business) of the choice.  Further, if a given language/platform choice, even if it is less popular, provides bottom-line results to the company, isn’t that going to raise the value of the company much more than picking the “safe” choice?  I don’t know, we’ll take a look at this.

That’s it for this installment.  Next time, we’ll take a look at some of the arguments and counter-arguments on both sides.  I promise it will be more interesting than this article, which just established some context.