Farmers turn of translation | yards
In the world of software development, as in any other field, there are some interesting and well-known laws that developers, managers, and architects often mention in meetings and chitchat, and a lot of times we just nod along, Lest anyone know they have never heard of Brooks, Moore or Conway.
Here, I sort out these laws and share them with you.
Probably the most well-known of all, because it doesn’t just apply to software development.
Anything that can go wrong will go wrong.
Law of Derivation: Swearing is the only language programmers can speak fluently.
Corollary: The computer works the way you write it, not the way you imagine it.
Defensive programming, version control, test-driven development, model-driven development, and so on are all good ways to prevent Murphy’s Law.
Most developers will experience Brooks’s Law:
Adding staff to a delayed project only makes it delayed even more
If a project falls behind, simply adding more people is likely to be disastrous.
Conversely, improving the efficiency of programming and examining the soundness of software development methods and technical architectures will almost always yield better results than adding more people. If not, it could mean that Hofstadter’s law is at work.
Hofstadter’s law was proposed and named after Douglas Hofstadter.
Not to be confused with Leonard Hofstadter from The Big Bang Theory. Even though his words may be useful to some of you.
The law goes like this:
Things always take longer than you think, even when you take Hofstadter’s law into account.
The recursion of this law reflects that even with your best efforts, it is very difficult to estimate a task accurately, knowing that it is complex, so leave a buffer for the estimate.
Any part of the software reflects the organizational structure that created it
Or to be clearer:
The organizational form is equivalent to the system architecture it designs
Many organizations divide teams based on their skills. So there will be teams of front-end development, back-end development, and database development. This makes it difficult for someone to modify something that is not their domain.
It is best to plan teams according to bounded contexts, and more and more organizers are doing just that. Architectures like microservices organize their teams around service boundaries rather than isolated technology systems.
The concrete practical advice from Conway’s Law is that you can get more bang for your buck by building the kind of team you want for your system design.
Also called the Robustness principle
Be conservative when sending and generous when receiving
Jon Postel initially thought that this principle was what made TCP implementations robust. Some people think this is why HTML is so successful, and some people think this is why HTML fails so badly. (Because HTML can be written less rigorously, but browsers can still parse it)
Also known as The 80/20 rule
For many phenomena, 80% of the consequences are caused by 20% of the causes.
In software development, 80% of the errors in code are caused by 20% of the code.
In addition, 80% of the company’s work is done by 20% of its employees. The problem is you don’t always know who the 20 percent are.
This principle can be devastating, especially if you happen to be experiencing it.
In a hierarchy, every employee tends to rise to the level of his incompetence
In organizations, employees tend to be promoted to a position of incompetence because of the habit of promoting those who are competent at a certain level.
Once a considerable part of the personnel in the organization is pushed to its incompetent level, it will cause the organization overstaffed, low efficiency, leading to the mediocre rise to the top, development stagnation.
In cryptography, a system should be secure even if everything in it is public (except the key).
This is the main principle of asymmetric encryption.
Named after Linus Torvalds, the father of Linux, the law states:
Under the eyes of the public, all the bugs can be seen
This law comes from the famous collection Cathedral and Bazaar, which compares two different models of open source software development.
-
Cathedral model, each software release comes with source code, but only for software developers.
-
Marketplace model, Internet as the medium, code development process completely exposed to the public view.
The more code that is publicly reviewed and tested, the faster bugs of all kinds are found.
The amount of computer power a dollar buys will double every 24 months.
The most popular versions are:
The number of components that can be accommodated on an integrated circuit doubles about every 18 months.
or
The processing power of computers doubles every two years.
The first 90% of the code takes 10% of development time, and the remaining 10% takes another 90% of development time.
So real. Would anyone disagree?
Immature optimization is the root of all evil.
Write the code first, locate the bottleneck, and then optimize it.
Once the company’s market share exceeds 50%, it cannot double.
These are the “laws” THAT I like. They all have their own stories and backgrounds. As a software developer you have to be familiar with them.
You may agree or disagree with one of these laws, or have had an interesting experience with any of them, leave a comment below!
About old Liu and code farmer turn over
I’m a thread
I’m a Java Class
Object-oriented Bible
TCP/IP daming postman
CPU forrest gump
Principle of load balancing
A story over HTTPs
The pinnacle of programming languages
Java: The Birth of an Empire
JavaScript: A loser’s counterattack
C language: When I returned home for the Spring Festival, I found that I was the only one without a date
