In software development, a key principle is to deliberately look for constraints and restrictions.
- Naming conventions: MyClass myClass = getMyClass()
- Coding standards: indentation style, class members ordering
- Convention over configuration
- Idiomatic style, for example Java Idioms
The obvious advantage is making communication between team members easier: shorter, faster, less error-prone.
- Encapsulation: constraint visibility “I must not see that”
- Low coupling: discipline of not knowing. “I don’t want to know about that component”, in particular layered architectures prevent many dependencies
- Depend on abstraction: “I don’t care the implementation”
Not knowing (or knowing as little as possible) enables scaling (growing) and helps to do changes with limited impact.
Other deliberate constraints
- Language keywords: const, final, restrictive default (override)
- Static typing and generics: restrict what you can do
- Frameworks as rigid application skeletons
Often the goal is to restrict and ask the tools to enforce that restriction in order to catch our mistakes, because as human we are subject to error. In the case of framework it is assumed that the rigid skeleton brings advantages (reuse) that well exceed the limitations.
This post is not very informative, but I felt like expressing this idea that more constraint can often be better, which is something every creative people knows quite well. I used to post about this overall feeling I had when I first noticed that: coding is not as creative as it used to be.