Hofstadter's law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
You better keep in mind that all of your estimates may be wrong to some extends.
Avoid spending too much time to refine those estimate again and again, don't take them for granted.
Linus' law
given enough eyeballs, all bugs are shallow.
This one invites you to maximise the amount of peoples checking code through methods like pair programming, code reviews, etc.
The more time you spend to write and to refactor some code samples, the more you're biased on its behavior, and your vision of it become narrower.
Murphy's law
Anything that can go wrong will go wrong.
This one is well known, but easy to miss too.
Maximise your testing efforts through unit tests, integration tests, try to use TDD for guidance.
Try to test as close as possible to the runtime conditions. For example uses TestContainers instead of H2 for database integration test, this way you'll be able to test against the target stack the soonest in your pipeline.
If you use a database migration tool like Flyway or Liquibase, with TestContainers it can be part of your test too.
Postel's law, or the robustness principle
be conservative in what you do, be liberal in what you accept from others.
This law suggests that the network may contains malevolent entities which could send anything unexpected to your application.
It invites you to never trust the input, and to be strict regarding the data you send.
Top comments (0)