Fred George Interview

Fred George is a developer and co-founder of Outspace system. He is a principle consultant at Fred George Consulting. Fred coined the term microservices. He coaches teams in Advance Agile concepts and in microservice architecture. Fred is one of the early adopters of Agile and OO. He has used over 70 programming languages and have worked across the globe. He started ThoughtWorks University in Bangalore, India, based on a training program he developed in the 90’s.

His specialities includes Software development; programmer anarchy; agile; lean; change agent; XP; software architecture; Ruby; Web HTML and CSS; Sinatra; Rails; 70+ languages

His contributions to the Agile community is remarkable and he continues to make an impact through his experience and domain expertise. 

Fred George

Here is an excerpt from the conversations we had with him.

1. What does it take to be an early adopter of any new language or technology?

Two thing: awareness and a bit of luck. First of all, you need to be aware of what new stuff is coming. There are an awful lot of blogs and announcements every day, so I find this channel useless. I tend to use conferences to expose myself to the latest thinking. And with so many conferences producing videos, a survey of the conference program and a few minutes of video can give you hints of what new is coming. Lately, MicroServices (which just had a dedicated conference in Berlin) and Docker seem hot.

The second thing is a bit of luck: Is this new idea worthy of attention, or is it one of the thousands of ideas that is seriously flawed? Fortunately, you can make your own luck. Find a handful of respected names in the industry that seem to be on top of the latest things, and watch what they do. Martin Fowler, (Pragmatic) Dave Thomas, and Neil Ford are some of my favorite guys to watch. They each have excellent track records of moving to better languages and technology platforms.

2. What is your advice to a novice polyglot programmer?

By polyglot, we are talking about a programmer who knows several different languages. My advice is to keep learning them, and strive for diversity of styles. Ruby and Python are very close; better to learn Clojure or Elixir if you already know Ruby. You should be trying to pick up at least one new language a year.

Everyone has their own style of learning. I am “hands-on”; I need to write a real program in the new language to really understand it. I know others that read a book and come away skilled (that’s just not me). So know your learning style. For me, I take some standard exercises (or code kata’s), and implement it in a language I know and a new language. What seems hard? Go look that up online.

3. Out of the 70, do you have any favourites programming languages? Why?

I think I had two profound languages that changed my programming style. The first was PL/C, an internal IBM language similar to C. Before that I was using assembly language, and I didn’t trust a program to write code better than I could. I was wrong. The early compilers didn’t get register assignments confused. I converted.

The second profound language was Smalltalk, a true object-oriented language. I read the book in 1987. It made great sense. I then started to write code, and realized I had no idea where to start: complete brain freeze. It took most of the next five years to understand it, and another five before I was really more productive.

So the short answer is Smalltalk because of how it helped me decompose real problems. I currently favor Ruby which is very close to Smalltalk in programming style.

4. These days microservices has become a buzzword. Personally I heard about microservices from you first in 2011 time frame. Tell us a bit about what created the need for a microservice architecture?

I coined the term originally to describe the ridiculously tiny programs I was writing at a client in 2005-6. As I was learning service-oriented architectures, I constantly hounded my colleagues to help me understand the appropriate granularity of services. I finally tried making them as small as possible, but still do something (an OO design technique). The idea of microservices really took off when we used the technique at a London startup in 2008.

Microservices is a natural result of simply going faster, measured from requirement through delivery. It has been facilitated by widely available cloud computing, better languages and platforms (Ruby, Python, Node.js), and high bandwidth communication between services (there is a 50GB backplane on high-end server racks). I know of at least 3 places that have independently arrived at the same design (microservices) for the same reasons.

In London, we were deploying new code into production every 3-4 minutes. That also drove organizational changes.

5. What are the advantages of microservice architecture?

There are two real business benefits: The ability to try ideas out efficiently without large time and resource expenditures, and robustness of systems that can detect and restore failures so quickly. I strive to design systems that survive failures, something much easier with microservices.

There is also an organizational benefit: Happier developers. We want to write and deliver code, and being able to do that everyday is very satisfying. Most of us exposed to the rapid processes that support microservices would not go back to the old processes.

6. Many companies are finding it hard to decide how micro should a microservice be. What is your advice to them?

First, realize there is a lot of diverse opinions on what microservices are. There are variations in size (from a few dozen lines of code to a few thousand) and interaction design (chains of service invoked via RESTful interfaces, or loosely couples, bus-attached services). So we (as an industry) are still exploring the possibilities.

Regardless, some of the early steps are the same: Break the single, cohesive database fiction most enterprises hold dear. One recent successful CTO cited his first step as “killing the JOINs” as a means of breaking the database down.

There are several representative projects to model yourself after. Netflix (which tends toward larger services) has open source most of their infrastructure, and other major companies are picking that up with great success. On the smaller side, the rewrite of uSwitch (of London) is a great example, as is the recent rewrite of Wunderlist (of Berlin); both are talked about publicly.

I’m hoping that we can have a much deeper discussion on this during my workshop at Agile India 2015 Conference. Join us, if you are interested in being part of the discussion.

This workshop has limited seats. Book early to avoid disappointments: