SRP is one of the more important concept in OO design. It’s also one of the simpler concepts to understand and adhere to. Yet oddly, SRP is often the most abused class design principle.
When you see commented-out code, delete it!
If the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code!
An estimate is not a number. An estimate is a distribution.
The perfect kind of architecture decision is the one which never has to be made.
The fundamental assumption underlying all software projects is that software is easy to change. If you violate this assumption by creating inflexible structures, then you undercut the economic model that the entire industry is based on. In.
Another problem with service-level decoupling is that it is expensive, both in development time and in system resources. Dealing with service boundaries where none are needed is a waste of effort, memory, and cycles. And, yes, I know that the last two are cheap – but the first is not.
Good software systems begin with clean code. On the one hand, if the bricks aren’t well made, the architecture of the building doesn’t matter much. On the other hand, you can make a substantial mess with well-made bricks. This is where the SOLID principles come in.
Science does not work by proving statements true, but rather by proving statements false.
Architecting for the enterprise, when all you really need is a cute little desktop tool, is a recipe for failure.
Code, without tests, is not clean. No matter how elegant it is, no matter how readable and accessible, if it hath not tests, it be unclean. Dave.
Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns.
Honesty in small things is not a small thing.
It is a myth that we can get systems “right the first time.” Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level.
Error handling is important, but if it obscures logic, it’s wrong.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
1. “First make it work.” You are out of business if it doesn’t work. 2. “Then make it right.” Refactor the code so that you and others can understand it and evolve it as needs change or are better understood. 3. “Then make it fast.” Refactor the code for “needed” performance.
Building a project should be a single trivial operation.
Just as the Hare was overconfident in its speed, so the developers are overconfident in their ability to remain productive.
The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute.