Why thinking small helps create software that lasts.

Last year I attended the Dublin Web Summit, among some of the excellent talks were two by Chad Fowler and Fred George. I wanted to share them here and talk about why they are important.

Fred George on Micro-Service Architecture

This video is from Baruco in 2012, but the content is pretty much identical to what was at the conference I attended.

In this talk Fred walks us through his learnings and thought process over many years as he attempted to implement Micro-Service architectures at various companies.

If you are not sure what a Micro-Service is don't worry, the video explains it very well, but if you want to read up a bit more on it I can recommend this post.

One of the conclusions was that around 100 lines is enough for most services, at this size rewrites become trivial and testing loses priority. There is only so much damage you can do in 100 lines of code.

One of the other conclusions was that if you have an architecture of potentially hundreds of tiny services is that integration testing starts to lose priority, a better solution is to monitor business metrics. If sales start to drop of a particular product it might be an indication that something isn't performing as it should be.

Having such small services allows for developers to more easily pick the correct tool for the job, the services are decoupled so you could easily write one thing in Ruby and another in Node.

Chad Fowler on Disposable Components

Just like Fred's talk, this video isn't from the conference I attended but is a recording of an almost identical talk by Chad. This video is from Rails Israel in 2013.

The first portion of this talk by Chad explores why long lasting systems (think Unix and tools of that ilk) last and concludes that it is because they have small replaceable parts.

Chad draws similarities between the likes of classic cars and the human body, individual parts (cells) can be replaced constantly, but the sum of those parts remains.

The second portion goes into some rules that he has introduced at this company, for their detail watch the video but I will summarise their headlines here;

1. Comments are a design smell
2. (Unit) Tests are a design smell
3. The System is heterogeneous by default.
4. Code has to be "this" big.
5. Nodes (servers) are disposable.
6. Never upgrade software on an existing node.
7. After you deploy a system, throw away the keys to it.
8. Always be deploying.
9. Assume failure.
10. Monitor everything.
11. Experience your worst case scenario so you don't have to fear it.
12. Data should be as small as possible.

I want to quote from the talk;

If your services are so small that you can read them in one go, you probably don't need a test.

I think this is very powerful. If you start to refactor things to make them so small that you can understand their function in one read, you are surely testing the underlying language more than business logic.