Discussion with Fred George: Microservices and Home Automation, Being inventive and Programmer Anarchy…

Kris Howard recently caught up with Fred George while he was staying in northern California, before he flew out to Australia for the various YOW! events he’s leading in March and April.

Discover more about how you can join Fred when he’s in Australia:
Fred George Workshops  |  YOW! Nights with Fred George

Why Home Automation and Microservices?

After doing microservices for a decade, Fred wanted to start exploring new areas – “finding new things to play with!”  His two favourite new bits of tech to explore are home automation and virtual reality.

Home automation and the Internet of Things are a particularly good fit for his experience as they provide a practical example of microservices in action.

The challenge with IoT in the home is putting things together that don’t normally work together.  Fred has found that microservices are a great tool for connecting different elements because of the flexibility they provide. Microservices are particularly useful if you don’t know exactly what you want to do or what’s possible.  Flexibility in development is key and microservices provide that.

There are other reasons that asynchronous microservices work well for home automation: it’s a fuzzy domain; there’s nice isolation; the potential for really aggressive cycles for deployment (being able to push out new code 5-6 times per day on different services as necessary); the need for a self-policing environment (in other words, no acceptance tests per se).

While Fred is still playing around and exploring what is possible with home automation, he has connected 9 different Philips Hue light bulbs and 10 metres of Hue lightstrips around his flat along with a few motion detectors.

IoT does present privacy concerns, as each of these devices is usually transmitting information back to a home server. While information from things like light switches is less likely to be of interest to others, data from weight scales and other measurement devices is more personal and needs to be protected.  He stressed the importance of making sure this type of information is locked down in any environment that is set up, and the best way to do that is to write the code yourself.

He finds that using a tiered approach is best, trying to isolate pieces that are relatively stable. He’ll find some sample code with Javascript that talks to a device and then convert it to his current favourite programming language – Ruby. (His all-time favorite language is Smalltalk but he views Ruby as Smalltalk with a bash syntax.)

There are a few different ways to control the system other than via a mobile phone.  He is using Amazon Alexa, but Google Home and Apple TV offer good alternatives. At some point, he reckons, the ideal solution would be a lightweight Linux box or Raspberry Pi as a controller. Fred is really intrigued by the idea that we’ll all have digital agents in the future, working on our behalf.

Taking Other People’s Inventions

Hilariously, Fred commented that he doesn’t consider himself an inventor.  His skill is taking other people’s inventions and making something real and fun out of their good ideas.  He learned early on that “it’s possible to make a career out of repeating what smart people have been saying!”

Programmer Anarchy

As well as being known for his work in microservices, Fred is also credited as one of the creators of Programmer Anarchy. Though the term itself was a marketing invention, the way of working was pioneered by his team in London in 2006 and offered the business a real competitive edge against bigger players.

During that time he had a team of 100 programmers that were self-allocated into teams of a maximum of 5-6.  Priorities for work were set by the Managing Director based on his identification of the business needs.  The key to this arrangement was the free movement of programmers between different teams without lots of bureaucratic hurdles and sign-offs.

In terms of team leadership, the idea was to let peer pressure and social organization take care of itself rather than appoint specific people. In the beginning of a project the architect would usually take control and lead but then it would move to the programmers as they were the ones writing the code and delivering results.

As well as freedom of movement, there was also flexibility around languages and technologies.  They used whatever language best suited the problem at hand.  The team provided support for what they had built; they owned deployment, everything.

One suggested alternative to a formal “Manager” is a sort of “team concierge” role.  This person is responsible for doing whatever the programmers didn’t want to do, ranging from moving a team member that isn’t working out to getting computer repairs organised.  This servant/leader type of role isn’t a Manager, as they aren’t authorized to make decisions for the team. They’re purely there as support for the team.

Discover more about how you can join Fred when he’s in Australia:

Fred George Workshops  |  YOW! Nights with Fred George