In software development, small is a big deal.
The idea of ‘keeping things small’ crops up in every area of software development. Small means simple and simple usually means less bugs. Small 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.
(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. A microservices architecture is all about 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. (Unless you use FreeAgent of course – it’s great!)
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. But 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 too. When it comes to object-oriented programming, this means use 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.
‘Uncle’ Bob Martin
Taken this approach to its logical extreme, however, can actually lead to unreadable read. You might end up with a huge number of small classes and methods. This isn’t a simple design. The cognitive overload required to work with this sort of codebase has turned some developers away from OOP and towards more functional programming. (Not necessarily a bad thing!)
This just goes to show that principles shouldn’t override common sense.
Happy coding! 🙂