Garrett Smith from CloudBees has been in software engineering for over twenty years. He got introduced to the Erlang programming language while evaluating CouchDB. Along with Visual Basic, Visual C++, and Erlang, Garrett also learned about Python.
It was Python that introduced him to the world of open source, and from there, as he learned more about open source and the dynamics of community-based development, he never looked back.
Garrett will be talking at OSCON 2014 about Erlang and building a massively scalable web server. You don’t need indepth knowledge of Erlang to get his talk about, what he says are, “some pretty amazing things about building software in general.”
Please tell us a bit about your background and career. When did you first cross paths with open source?
I’ve been writing software professionally for over twenty years and got my start in the Microsoft Windows 3.x era of programming, so Visual Basic and Visual C++ and even some VBA with Excel and Access. It sounds pedestrian now, but it was very exciting at the time. Businesses were spending money to build lots of software that ran on cheap PCs. Programmers were in short supply and it was a wide open arena to learn practical programming skills—and get money to buy beer.
When Java made its debut in 1994 out, I made a shift there. Apart from its affinity with the Web, Java’s cross platform support offered a path out of the Microsoft hegemony. I bought the GoF “Design Patterns” and made it my goal to use every pattern at least once in a project I was leading. It was like a cocaine bender—an initial feeling of euphoria followed by a crash that left me alone, bleeding in the gutter without friends and sense that I had let the Universe down, morally.
My experience with Java was an exercise in problem creation, not problem solving.
After seeing what I had done—and indeed what the Java culture encourages—I tried my hand at Python. Python embraces multiple platforms in a pragmatic and direct way and loses static typing. The whitespace thing didn’t bother me, and I enjoyed not having to think in multiple layers of abstraction. I also met amazing people in the Python community. This introduced me to “open source” (a loaded term then, less so today) and the dynamic of community-based software development. I never looked back.
I had been writing proprietary commercial software for about ten years at that point and sensed that industry was decaying and would eventually die. It might take a long time, but the future was not in selling software licenses, it was somewhere else. The problem, as I saw it, was that commercial software vendors were compelled to ship features to drive sales. The features they built, in many cases, were drummed up, internally, by product managers that needed something to announce and market. The features often had nothing to do with real user pain and ended up making the software worse. This cycle would continue, on and on, until the software ended up bloated, awful to use, and expensive to support.
When you’re not charging licensing fees you can focus on what is needed by users. Adoption is the key to success. Rather than shipping quarterly releases with speculative features that you hope justify your customer’s subscription plans, you can ship routinely with small improvements that are vetted with real world use. It’s a radically different program and so clearly superior, I don’t see commercial software surviving it. You’ll continue to see pockets of niche, vertical applications that remain successfully closed, but in time I think these will succumb to open processes.
In an attempt to find a business model that could fit harmoniously into the open source revolution, I shifted my career to enterprise software services, but quickly returned to software product development. I’m currently working in the “cloud” space, which is, in my estimation, a way to add value to data center hosting services (fundamentally selling electrical power, cooling, and backbone access). Whatever you call it (IaaS, PaaS, SaaS, and so on) building products and the services that run “out there somewhere” is a long running business model that programmers can safely commit to.
Erlang goes a long way back to 1986 and the Ericsson Computer Science Laboratory. When did you first learn about it? And what made you start using it?
I first learned about Erlang when evaluating CouchDB for a project. I had to install this language called “Erlang,” and I had never heard of it. Weird, how often does that happen? So I started playing around with it and bought Joe Armstrong’s “Programming Erlang” and was intrigued. I had often discussed with friends the short coming of languages that bolted distributed programming concepts on as an after thought. Here was a language that had distribution built into the core!
I kicked the tires, built the samples, and left it alone for a couple years. I then ran into a problem that I just could not solve using the in-house tools at hand—Python and Java. It was a fine grained monitoring problem that involved tens of thousands of independent monitoring states. The posix-thread based models were falling over in time with mysterious hangs and process crashes. As a monitoring program, this had to run reliably and had to deal with this hard concurrency problem. I knew we had a long haul in getting things right with Python or Java, and that opened up the option of using a new language like Erlang.
I took the hit to rewrite the program in Erlang. It took less time than I expected, and it worked extremely well. That experience convinced me of the merits of using Erlang—both as a superior model for handing concurrency (independent processes with message passing)—and also, surprisingly, as a functional language.
In using a functional language, I discovered that my programs were more coherent (i.e. easier to understand and think about) and more stable (fewer bugs). It prompted my gradual replacement of Python and Java for backend, long running programs. They were easier to write and easier to maintain.
This was a formative experience. Erlang is hands down my tool of choice for writing long running, unattended programs. I’m also now a strong proponent of functional languages in general.
What does a day at CloudBees look like for you?
We always look at open source software first at CloudBees. CloudBees is the company behind Jenkins—a hugely successful open source project. We realize that the quality of software reflects the quality of the community behind it. Notice I said “community” and not “development team.” In open source, there are certainly core contributors, but open source projects are living organisms that are continually shifting and evolving. A great open source project, like Jenkins, attracts brilliant contributors. Those contributors make the software better. Without community a technology will die. We understand that and look for tools and technology that are attracting and nurturing talented humans.
Internally, we use open source patterns of development. Individuals are encouraged to contribute to internal projects, submit pull requests, and in general solve problems directly by writing code. CloudBees loves code—we are skeptical of designs and plans. Designs and plans are great starters, but the programmers at CloudBees respect working code more than anything. We’re all very much sold on the open source way of building software. There’s no question that it results in higher quality, better fitting technology. It goes faster as well.
Your session at OSCON will have a clear goal, to teach the audience to develop a massively scalable HTTP server and learn all about Erlang.
What type of developers should attend?
People are interested in Erlang and the tutorial is a great way to see how working software is built in the language. The tutorial slot is of course too short to walk away with deep knowledge, but seeing how stuff is built in a live context where you can ask questions and interact with the teacher is invaluable. If you’re curious about Erlang, come to this session—it doesn’t matter what your specialty is. The focus will be on the Tao of Erlang—how it works and why it’s important.
I absolutely love to teach. Really, I think everyone does—it’s about sharing the things you’re passionate about and who doesn’t do this naturally? I try hard to keep the big picture front-and-center. E.g. knowing what pattern matching is in Erlang is one thing. But knowing how pattern matching changes the way you program and improves software quality—that is powerful. If I can get some brain bits to flip—get some “ahhh, that’s really cool” moments with folks, I’ll have my endorphin release for the day.
Any final thoughts you would like to share? A sneak preview into your talk?
Anyone attended either the session talk or the tutorial should be prepared to learn some pretty amazing things about building software in general. Erlang is a very unique language and the topics that differentiate it are important to programmers. Process isolation, system orientation, fault detection and recovery, distribution—these are central to Erlang’s identify. That’s not true of any other programming language that I’m aware of. Ironically, everyone’s talking about these topics *outside* the language tier—operating systems, VMs, containers, cloud, etc. Erlang had this 20 years ago inside the language. Even if you don’t pick up Erlang, knowing how it approaches the programming model will be useful in thinking about programs in other languages.
Of course, I hope people pick up Erlang as well.
Courtesy: Opensource Website