Lesson: Agile Development with Ian McFarland

Step #4 Tools: Pick the right tool for the team and the job that you are going to do

It really is a question, in all these cases, a question of using the right tool for the team and for the job that you're trying to do. And people tend to forget how important thinking about what the team's skills are. There isn't a correct language to use, there isn't a correct tool to use. Every language has different attributes. And so, for me, languages like Ruby or Python, are really good languages for, they're very object-oriented, and they're very dynamic, which let's us do a lot of things in testing, that makes them really attractive as languages to write certain kinds of code in.

There are other languages, like, we're going to end up using Javascript a lot, because that's the only thing that runs in the browser. It's the only thing that you can run as an interpreted language and not an iOS application. It's inevitable that we will use Javascript. So, treating it as a real language is important. If you're building a high throughput message management system, using something in the functional space, like using Scala, or using Erlang, or using the right tool for the job, is a really important consideration.

The problem isn't usually the engineering team doesn't know what the right tool for the job is. The problem is that the engineering team doesn't have the rigor to ask themselves, "Is this the right tool for this job?" So, in some sense it's really an engineering team maturity question. There are always fads in software. There was the noSQL movement and noSQL is great for a whole bunch of problem sets. But, it doesn't mean, "It's the new hotness so I should go build something using it." That's fine to do as an experiment. But it doesn't mean, "I heard this new thing is awesome. Let's go try using it."

I mean understand what it does, noSQL is really good for complex object graphs. It's really good for low latency storage. Regular SQL is really good for certain kinds of querying and being able to put together a certain kind of structure in your data. So, having the rigor to sort of look at the tool is one part, figuring out, "I think this is something where using a functional programming language is appropriate."

Then, of course I have to go back to that team question, "Does my team know how to use Erlang? No, they don't know how to use Erlang. Well, we have a bunch of Ruby developers. Maybe we should look at Elixir." Elixir is this sort of ruby style language front-end that sort of compiles down to Erlang code. Maybe I want to do stuff on a Java Run Time but I'm a Ruby-ist, so I'll use JRuby. So these are considerations.

The team ultimately still has to be able to work with the code base. If you only have a bunch of PHP developers, then you stay doing PHP. None of this stuff happens in a vacuum. So, on some level when people ask for advice from me sometimes they just want the simple answer. If you just want the simple answer, it doesn't matter that much, is the simple answer. Do whatever was working for you. But, if something is not working for you, think through what's not working about it. Maybe another tool would be better.

Well, it's interesting because, when you're looking at the new hotness, you want to tease apart the new appropriateness, not the new hotness. Right? So there was a huge fad, and it continues to be a big fad, but fads don't happen in a vacuum, either. There's a reason why NoSQL got really big. There's a reason why Ruby got really big. The reason Ruby got really big was that it was a really high performance language for developers to write code in. It's funny because every time there is a new language people complain about it being too slow. I remember when Java came out, everyone thought "Java's a really interesting toy language, but Java's too slow. You can't use it for anything." And now it's fast. In fact, by many arguments it's the fastest language you can use to do web stuff from a run time perspective.

But really, when we're in a startup the thing we care about most is developer productivity. The run time performance is an issue when you're at scale. But the scaling problem that most startups face is not how to get enough throughput on our machines. It's how do we get enough people to care about our application so that we have a throughput problem. Most web sites never face the problem of how to handle all the traffic coming in. They always face the problem of how to get enough value onto a web page so that somebody can actually engage with it and so there is meaning in us doing this start up.

So, I think it's interesting. The Ruby fad in investing, you're right, that you shouldn't just take it at face value. There was value in highly productive teams using an Agile development approach and using Ruby as a language. But if someone was doing something else, it's kind of incumbent on the VC to say "Oh, tell me about that." And it's fair to say "Why aren't you doing things the way everyone else is doing them." It's a great question. And if you ask somebody, "Why did you make the language choice that you did?" Most people don't have an answer. So that's very interesting if you're an investor trying to understand how they're going to respond to change.

Did they think through their language choice? Did they think through their platform choice? Are they using the right text stack? If they have really thought it through and there are compelling reasons for why they chose what they chose, and especially if they show some flexibility in terms of what-if stuff. If something changes, what would your response be? If they have an articulated thought-through answer, it's perfectly reasonable to say "Actually, the language choice doesn't matter much in this case. We liked this language. Our team is capable in this language. So that was the choice we made. If there is a performance issue, we have a plan to do this."

The classic example is Twitter. Twitter had a bunch of performance issues around their core message bus, because they're pumping huge amounts of traffic through it. They did some stuff in Ruby at first but ultimately they moved to Scala. So you never know what the problem is that you're going to end up solving at the beginning of a startup. There's more that you don't know than that you do know at any point in a startup, so it's more important how you think through your platform choice. Your thought process around how you evaluate whether you're doing the right thing, that's the more important thing.