TL; DR;
This book gets right to the point of the common aspects required for building great software and is too valuable for any software development professional not to read; and it contains just 172 pages! 😃
Read this book.
Plan Before Implementing
Proper and properly named abstractions to match problem domain and purpose. Thoroughly documented and well-understood behavioral interactions among all accessible components and at minimum a solid high level understanding of all dependencies; know when not to re-invent the wheel and instead utilize a proven 3rd party or open source tool.
Keep it Small
YAGNI ("You ain't gonna need it") is a very real thing. Development teams should focus on working prototypes that can be ironed out for production vs. forever "ideal" implementations that never make it to an actual user's screen.
Write Clearly
Treat a rough draft as a rough draft by encouraging code reviews and frequent minor refactoring to achieve code clarity for the next developers who will inevitably read (and need to understand in order to change or extend) your logic in the future.
Prevent Bugs
Meticulously control scope and member access and understand all ramifications of behavioral code points within the application. Every area of variation/mutation/state change should be covered by tests that are both named and implemented to clearly demonstrate the function/class/behavior being tested.
All tests are important for confidence/assurance in ongoing development but TDD (writing tests before the implementation a la Kent Beck) is not a replacement for good, cohesive design. That being said, I think the TDD backwards approach can help start great design discussion among developers when the design is somewhat unclear (tests, particularly broken tests will expose the innards that most warrant discussing).
Make the Program Robust
Utilize agreed-upon code formatting and pattern implementation standards and non-antagonistic code reviews to ensure these standards are being followed.
Utilize information hiding and useful categorization and encapsulation that extends but does not lend itself to potential client issues.
Do not try/catch everything and log everything unless necessary for compliance or a particuliar initiative being monitored. Make Exceptions very visible (but exit the program gracefully if the exception is not "handleable") and integrate tests to prevent the same (preventable) issues from recurring. Instead use try/finally and let exceptions bubble up to the surface application code.
Exceptions that are allowed to be handled and logged hide problems in the code that need immediate attention.
Use solid CI/CD and automated testing that tests for easily definable application behaviors.
Prevent Excess Coupling
Favor atomic initialization: Initialize everything all at once versus incremental composition.
Discourage unnecessary extensibility points and instead expose what needs to be exposed with as little information sharing as possible.
Strive for immutable members wherever possible.
Cohesive, self-evident abstractions are of utmost importance.
SUMMARY
The concepts so succinctly covered in Timeless Laws of Software Development apply to all types of code (imperative or declarative) and all languages.
While I've read many great software books and all have helped me become a better developer, no text has struck me as so plainly obvious and concise at explaining good software design concepts in such an easy-to-grok manner.
For a worthwhile read, check out Timeless Laws of Software Development by Jerry Fitzpatrick
