Most useful programs have state. As the program scales you need to break it up into parts (or 'modules') with clear interfaces. Usually these parts own state.

Most useful programs have state. As the program scales you need to break it up into parts (or 'modules') with clear interfaces. Usually these parts own state. The problem with OOP is that it assumes you need lots of these parts. Whereas really, you might have a few or possibly a handful. Use, class-like constructs to represent these, and use normal functions within these, with ideally some kind of polymorphism that also doesn't require classes. For small programs, don't even bother with this. Just use pure functions for key logic, and unit test those, and delay testing anything with state for as long as possible. When you do need to, leverage interfaces and stubs/fakes (not mocks) to test them. That's what I do now anyway.