Fullstack Radio Podcast Episode with DHH – shaping your technical patterns based on your organizational patterns

On the Fullstack Radio Podcast this week there is a great technical/design discussion with DHH about technical versus organizational patterns, Basecamp 3 and Ruby on Rails 5. Sadly there was not enough cowbell in the form of curse words (only around 5 🙂 ). I kid around about this but one of the great things about DHH is his opinionated and eminently pragmatic approach. He justifies his reasons really well and he stands his ground regardless of the sh*t storms that stir up around him.

Beyond all the technical choices and decisions for Basecamp 3 the discussion that caught my attention was the one about technical patterns versus organizational patterns (starting around 09:19 and ending around 18:45. Most outlets of technical information (whether high profile developers, companies, etc…) focus on architectural patterns and there’s never any talk about organizational patterns. In other words, does the architectural pattern that you choose fit your organizational pattern?

DHH discusses the intersection between organizational patterns and technical patterns. For a small team (like Basecamp’s) of 12 developer/designers a micro-services architecture would be disastrous in terms of implementation and maintenance. Whereas micro-services might be a perfect fit for an organization like AWS. In the case of Basecamp 3 the organizational pattern (i.e. very small dev team) causes the following choices in architectural patterns:

  • hybrid native apps (i.e. do as much on the server as possible with fast web views while doing native side optimizations for high fidelity features)
  • Basecamp 3 as a “majestic monolith” rather than a constellation of micro-service (11:08)

The point is that you have to fit your technical pattern to your organizational pattern, not the other way around. The question fundamentally is: “does this technical pattern fit our organizational shape?”

Best quote of the episode: “whatever Facebook is doing do the complete opposite of that and in many cases you’re closer to finding patterns to your organizational shape if you’re a company of 5, 10, or under 50” (13:50). Basically, trying to clone architectural patterns of companies with unlimited resources is a very bad approach.

Micro-services make complete sense for someone like Amazon (15:05). Amazon has lots of people and lots of business units. Amazon was an early adopter of service oriented architecture. Team sizes are what they are at Amazon but you need teams to collaborate, so micro-services fit this model.

The majestic monolith has wrongly been discarded because (second best quote) “people have been looking at giants for inspiration for ants” (17:42).

This is a very interesting approach. I never thought about it in this way always looking at the technical patterns. I’ve been at start-ups where the software architect is so focused and in love with technical patterns that s/he loses all perspective of anything else. In fact, I don’t recall any start-up where the organizational pattern shaped the decisions of the architectural pattern.

For RoR enthusiasts there are lots of Basecamp and RoR 5 information beyond the above section.

More DHH info can be found here:

Advertisement