Lauers Law – why less code is better
Lauers Law – why less code is better as a very solid idea. Just remind Yourself about all those DTOs that could be a simpler one with a mapper or a dedicated if-else-tree somewhere around data transformation. It challenges developers to prioritize efficiency and elegance in their coding practices, ultimately leading to cleaner, easier to understand and more maintainable systems.
The Essence of Lauer’s Law
At its core, Lauer’s Law emphasizes that reducing the amount of code can lead to better outcomes. The principle suggests that if developers had twice as much time, they could create a system with half the code while maintaining or improving its quality.
The idea behind is similar to such as Occam’s Razor and the principle of simplicity in design.
Easier said then done. Obstacles to writing less code
Those are my biggest issues, as always very similar as to why all those rules, principles and other laws are falling short in real world.
- Knowing the data – It is very hard to know the exact constraints on the data we work with. How often You recall having multiple models just to find our that those 2-3 fields out of 15 could be optional and everything packed in one class to rule them all ? Another thing is validating the data…. error handling… exponential rising of issues we may or may not have to take care of.
- Smaller code classes is better then big class code but when does more small classes get worse then one big class ?
- YAGNI – You ain`t gonna need it so just write as it is, plain simple You can always get back and refactor right ? 🙂 Oh yeah… and then on the review we will be discussing why didn’t You take this and that under consideration … how many steps ahead do You have to think ? Do You have to do business work ?
- Refactor – sorry but we do not have time for that. Bye bye goes all the technical stuff You would like to do. Don`t we all know it already by heart ? I can call upon another law that we all know we can easily implement. You ain’t gonna refactor it and in the end nobody will care. If they will have to they will refactor it during some future iteration.
Why Less Code Matters
- Improved maintainability: Smaller codebases are easier to understand, debug, and update. After all we read code a lot more then we write code. Writing is easy, understanding …. that sucks. When there’s less code to sift through, developers can focus on fixing issues or adding features without getting bogged down by unnecessary complexity
- Reduced risk of bugs: Every additional line of code introduces potential points of failure. By writing less code, developers minimize the likelihood of bugs and errors creeping into the system
- Enhanced performance: Streamlined code often performs better because it avoids redundant operations and unnecessary overhead. The question is can we simplify the business logic to minimum.
- Lower technical debt: Excessive or overly complex code can accumulate technical debt, making future changes costly and time-consuming. Adhering to Lauer’s Law helps mitigate this risk. Easier said then done, usually (yagni) we never write code we do not need or use… so in theory by default we adhere to the Lauers Law. I even prefer to write more code but simpler to understand then some fancy iterations or streaming that people doesn`t know what is what and what is happening.
How to write less (better ?) code
To try and embrace Lauer’s Law effectively, developers can try to adopt several best practices:
- Follow Coding Standards: Adhering to established guidelines like SOLID principles ensures that your code is both concise and scalable
- Refactor Regularly: Continuously review and refine your code to eliminate redundancies and improve clarity
- Leverage Design Patterns: Using proven design patterns can reduce boilerplate code while maintaining functionality
- Prioritize Reusability: Write modular components that can be reused across different parts of your application instead of duplicating logic
- Test Thoroughly: Automated testing ensures that minimalistic code still meets all functional requirements without introducing errors
Simplicity vs functionality
Summary Table: Lauer’s Law vs. Other Coding Principles
| Principle | Description | Application in Law/Coding |
|---|---|---|
| Lauer’s Law | Less code is better code | Write concise, maintainable code |
| Occam’s Razor | Simplest solution is best | Avoid overengineering automation |
| Zen of Python | Simple is better than complex | Favor clarity in legal tech tools |
While less code is generally better, simplicity should never come at the expense of functionality, business logic or correctness. Developers must strike a balance( as all things should be) between reducing complexity and ensuring that their systems meet all requirements effectively. As Butler Lampson’s Law reminds us: „Get it right. Neither abstraction nor simplicity is a substitute for getting it right”
Conclusion
Lauer’s Law serves as a guiding principle for developers striving to write clean, efficient, and maintainable code. By focusing on simplicity and reducing unnecessary complexity, at least as much as You can write it that way and negotatiate the implementatio after code review. After all, in software engineering, less is truly more. Lauer’s Law asserting that „less code is better code,” is definitly a nice rule to start development.
