In software development, small is a big deal.
The idea of ‘keeping things small’ crops up on every level of software development. Small means simple and simple usually means fewer bugs. On a managerial level, smaller projects are easier to manage than large ones.
Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. Linus Torvalds
Small teams are easier to manage too. Although be careful about splitting teams up too much.
The principle of keeping things small appears in Extreme Programming, Clean Code, Agile and architecture patterns. A microservices architecture focuses on creating small, autonomously deployed services.
How can the ‘principle of small’ guide us when writing code?
For a start, it’s a good idea not to make big changes to code all at once. Small changes are better. Reviewing a pull request that changes hundreds of files is emotionally equivalent to doing a tax return.
When you write new code, it’s good practice to use the fewest number of elements as possible without sacrificing readability. Some programming languages and frameworks are better at encouraging you to do this than others. For example, you can write functions in a more compact way using a functional language than a procedural language.
If you’re following generic best practices, you should also be doing Test-Driven Development. Small applies here too. TDD is all about working in small incremental steps: write a test, get it to pass, and then refactor it.
‘Keeping it small’ crops up a lot in discussions on Clean Code. When it comes to object-oriented programming, this means using fewer classes and methods. These things should have only one reason to change (a single responsibility). In other words, keep them small.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Bob Martin
This approach, however, when taken to its logical extreme can lead to some very unreadable code. In this case, you end up with a very large number of small classes and methods. This isn’t a simple design.
The cognitive overload required to work with such over-engineered codebases has turned some developers away from OOP and towards more functional programming. This in itself isn't bad, but it is throwing the champagne out with the cork. OOP is very beneficial because it means developers can talk to domain experts and other stakeholders about the code in a language that both parties understand.
The moral of the story is two-fold: design principles shouldn’t override common sense and keep it small, stupid.