Simplify, Then Add Lightness

The Virtues of Being Small

Colin Chapman's famous quote is applicable to software development as it is to performance cars. In Clean Code, Uncle Bob dishes out the following sage advice:

• The first rule of functions is that they should be small
• The second rule of functions is that they should be smaller than that

The story is the same in the chapter about classes; small is good. Small means the class has few (ideally one) responsibilities. This gives each class far more potential to be re-used. Small classes give a chance for a system to be organised more logically. It's crystal clear:

Only good things come from having small classes

So methods benefit from being small, and classes benefit from being small - why stop there?

At my current workplace, we've been having problems with excessively-long CI build times. A little bit of investigation showed that there was one core library that was constantly being rebuilt due to upstream changes, and would cause an avalanche of dependent builds to be queued up when it finished building. Combined with the fact that the time-to-build of the project itself had blown out from 5-ish to 10-ish minutes, it was a disaster.

You can guess where I'm going with this. The library was too big. It tried to do too much, and thus was depended upon by myriad downstream projects. Ponder the consequences of refactoring it into vertical slices that are still operating at the same "layer", but address fewer needs:

• The smaller slices depend on fewer upstream projects and hence get pointlessly-rebuilt less often
• The smaller slices take less time to build
• The smaller slices bring along less JAR file "baggage", reducing the eventual deliverable size
• Downstream projects can pick and choose from the slices they actually need. The number of pointlessly-run dependent builds drops
• There's a closer correlation between Java package name and the project it belongs to

This is all good too. So I'm hereby adding a new pseudo-Clean Code mantra to my mental map:

• The first rule of projects is that they should be small