In discussions around software development, it is almost inevitable that people will casually quote one or two principles.
You’ve probably heard people say, “This doesn’t work because of the ‘Law of X’!” ”。 Or “Don’t you know the ‘Y principle’?” “What type of software developer are you?”
There are many laws and principles to be cited, most of which are based on truth. However, blindly using absolute statements like the above to apply them can certainly lead to conceit and failure.
This article lists some of the most popular rules and principles that can be applied to software development. For each law, we’ll quickly discuss its main content and then explore how to apply it to software development (and perhaps when it shouldn’t).
content
Pareto’s Law states that usually 80% of the results come from 20% of the causes. The numbers 80 and 20 are not precise in any way, but the general idea of the principle is that results are often unevenly distributed.
We can see that many areas of life follow this rule, such as:
The richest 20% of the world’s people generate 80% of the world’s income.
80% of crimes are committed by 20% of offenders (since 2020).
We know that 80% of the virus spreads from 20% of infected people.
How to apply in software development?
The main benefit we can get from Pareto’s law is concentration. It helps us focus on the things that are important (20%) instead of wasting time and effort on the things that are not important (the other 80%). The unimportant things are often important to us because there are always too many (and seemingly urgent) things like this. But the best outcomes are often achieved by focusing on the important few.
In software development, we can use it to focus on building the right functionality, such as:
Focus on achieving 80% of the product value of the product features of the 20% product.
Focus on the 20% errors that cause 80% of users to use exceptions.
Focus on the 20% total build time required to achieve 80% of the product functionality
……
Just ask “What’s the most important thing right now?” “It can help build the next most important thing, not the next most urgent thing.”
By the way, modern development methods like Agile and DevOps help to get that attention! Rapid iterations with regular user feedback allow for data-driven decisions on what’s important. Practices such as backbone-based development with functional markers can help software teams achieve this.
content
Broken windows cause damage, so soon all windows are broken.
In general: chaos leads to more chaos.
If our environment is primitive, we will have the incentive to remain that state. The more chaos in the environment, the lower the threshold for us to add chaos. After all, it’s already chaotic… Who cares if we add a little more?
The main benefit we can get from this rule is that we should be aware of the chaos around us. If it has reached the point where people are accustomed to no longer caring about it, then it is better to bring some order to the chaos.
How to apply in software development?
In software development, we can apply this to code quality: every code smell we introduce into the code base lowers the threshold for us to add more code odor. We should [[Start Clean]] and keep the codebase clean to avoid this. The reason many code bases are so difficult to understand and maintain is that broken windows have quietly emerged and haven’t been fixed quickly enough.
We can also apply this principle to test coverage: once a certain amount of code goes into the uncovered code base, more uncovered code is added. This is an argument for maintaining 100% code coverage (for the code that should be covered), so we can see cracks before the window breaks.
content
The philosophical razor is a principle that helps explain something by eliminating (or “cutting out”) impossible assumptions. Occam’s razor says that if there are multiple hypotheses, we should choose the one with the fewest assumptions (which is likely to be the simplest to explain).
How to apply in software development?
We can apply the Occam’s razor in event analysis. You may have encountered a situation where a user reports a problem with your application, but you don’t know the cause of the problem. So, you’re searching logs and metrics, trying to find the root cause.
The next time a user reports an error, maintain the incident investigation documentation. Write down your assumptions about what caused the problem. Then, for each hypothesis, list the facts and conjectures. If the hypothesis proves to be correct, mark it as a fact. If a hypothesis proves to be wrong, remove it from the document or mark it as an error. At any given time, you can now focus your time on the most likely assumptions instead of wasting time diverting attention.
content
The Dunning-Kruger effect shows that inexperienced people tend to overestimate their abilities, while experienced people tend to underestimate their abilities.
You’re not good at something, but you’ll think you’re good at it. If you’re good at something, you think you’re not good at it – this can lead to imposter syndrome, which makes you doubt your abilities so much that you feel uncomfortable among other people with similar skills (fear that others will think you’re saying it is incorrect).
How to apply in software development?
Realizing this cognitive bias is already a good step in the right direction. It will help you better assess your skills so that you can ask for help, or overcome self-doubt and act on your own.
One practice that helps eliminate the Dunning-Kruger effect and imposter syndrome is pairing or group programming. Instead of working alone, immersed in self-doubt or a sense of superiority, you work closely with others, exchanging ideas, learning and teaching as you work.
However, this only applies to safe environments. In an environment where individualism is glorified, pairing or group programming leads to more self-doubt or more delusions of superiority.
content
Peter’s Principle states that as long as you excel at work, you get promoted until you get promoted to a job that you don’t do. Since you are no longer successful, you will no longer be promoted, which means that you will be living in a job that will not bring you satisfaction or success, usually for the rest of your life. The outlook is bleak!
How to apply in software development?
In software development, the Peter principle usually applies when you transition your role from a developer career to a management career. However, being a good developer doesn’t necessarily mean you’re a good manager. Or, you might be a good manager, but don’t get the satisfaction of a manager’s job on a developer’s job, which means you’re not going all out (that’s my case). In any case, you are miserable and do not see any future development on the career path in front of you. In this case, take a step back and think about what you want your career to look like. Then, switch roles (or companies, if needed) to get the roles you want.
content
Parkinson’s Law states that work always fills the time allocated to it. If your project has a due date within two weeks, the project will not be completed before then. It may take longer, yes, but in no way less than the time we allocate for it, because we are filling in the time with unnecessary work or delays.
How to apply in software development?
The main drivers of Parkinson’s Law are:
Procrastination (“The deadline is too far away, so I don’t need to rush now…”)
Range sprawl (“Of course, we can add this little feature, it won’t take us much time…”)
To combat procrastination, we can set deadlines in days instead of weeks or months. For example, what do you need to do in the next 2-3 days to move towards your goal? One (healthy!) Deadlines can give us enough motivation not to fall into the trough of procrastination. To prevent the scope from spreading, we should have a very clear understanding of what we are trying to achieve through the project. What are the measures of success? Will this new feature increase these metrics? Then if everyone understands that this work will take longer, we should add it. If the new feature doesn’t match the mission statement, ditch it.
content
Hofstadt’s law states that “it is always longer than you expect, even if you take into account Hofstadt’s law”. Even if you understand this law and increase the time allocation of the project, it will still take longer than you expect. This is closely related to Parkinson’s law, which states that work always fills up the time allocated to it. It’s just that Hofstadi’s law says it fills in longer than it is allocated.
This law is supported by psychology. We tend to make the so-called “planning fallacy,” where we usually don’t consider all available information when estimating workload, even when we think we’ve thought about it. Our estimates are almost always subjective and rarely correct.
How to apply in software development?
In software development (and any other project-based work, really), our human optimism prevails. Estimates are almost always overly optimistic. To reduce the influence of Hofstaat’s law, we can try to make estimates as objectively as possible. Write down a list of assumptions and facts about the project. Mark each manifest element as a hypothesis or fact to make data quality visible and manage expectations. Don’t rely on intuition, because everyone feels differently. Write down estimates and get your brain thinking about them. Compare them to other people’s estimates and then discuss the differences.
Even so, it is still only an estimate and most likely does not reflect reality. If the estimate is not based on statistics or other historical data, then its value is very low, so it’s always good to manage expectations with the people who ask you to estimate – and that’s always going to go wrong. If you make it as objective as possible, it reduces errors.
content
Conway’s Law states that any system created by an organization will resemble the organization’s team and communication structure. If you have 10 teams working on one system, you’re likely to get 10 subsystems that communicate with each other.
How to apply in software development?
We can apply what is called reverse Conway maneuvering: creating an organizational structure that best supports the architecture of the system we want to build. There is no fixed team structure, but there is enough flexibility to create and disband the team, which is best for the current state of the system.
content
Murphy’s Law says that anything that can go wrong will go wrong. It is often referenced after an accident has occurred.
How to apply in software development?
Software development is a career that can be easily made wrong. The main source of error is a bug. There is no software that is free of errors or events that challenge the user’s patience. We can fend off Murphy’s Law by developing the habit of reducing the effects of errors in our daily software development practices. We can’t avoid errors completely, but we can and should reduce their impact on users. The most useful way to combat Murphy’s Law is feature marking.
If we use a feature tagging platform like LaunchDarkly, we can deploy changes to production after the feature tag. We can then use targeted releases to activate the flags of internal dogfooding, then publish them to a small number of friendly beta users, and finally publish them to all users. In this way, we can get feedback on changes from an increasingly critical user base. If a change goes wrong (and at some point), the impact is minimal because only a small percentage of the user group is affected by it. Moreover, the flag can be turned off quickly.
content
In the classic book “The Myth of the Human Moon”, Fred Brook famously said that adding manpower to a late project makes the project later. Although this book is about software projects, it is applicable to most types of projects, even those outside of software development. The reason that adding people doesn’t speed up a project is because the project’s communication overhead grows exponentially with everyone who is added to the project. 2 people have 1 communication path, 5 people already have 120 possible communication paths. It takes time for new people to settle in and determine the communication path they need, which is why when you add a new person to a project, the project is later to be late.
How to apply in software development?
Very simple. Change the due date instead of adding people to projects that are already late. The expectation of adding new people to a software project should be realistic. Adding people to a project may increase speed at some point, but not always, and certainly not immediately. People and teams need time to adapt to day-to-day work, and at some point, the work can’t be sufficiently parallelized, so adding more people doesn’t make sense. Think carefully about what tasks a new person should accomplish and what you would expect when adding that person to the project.
content
Postel’s Law, also known as the principle of robustness, states that you should be “conservative about what you do and open up to what you accept from others.” In other words, you can accept many different forms of data to make your software as flexible as possible, but you should be very careful when dealing with this data so as not to compromise your software with invalid or malicious data.
How to apply in software development?
This law stems from software development and is therefore very directly applicable. The interface between your software and other software or developers should allow different forms of input for robustness:
For backward compatibility, the new version of the interface should accept data from both the old version and the new version
For a better user experience, forms in the UI should accept data in different formats so that users don’t have to worry about formatting.
However, if we are willing to accept data in different formats, we must be conservative in our handling of this data. We have to review invalid values and make sure that we don’t compromise the security of the system by allowing too many different formats. SQL injection is a possible attack that is caused by being too lenient with user input.
content
Kerchkhoff’s principles state that an encryption system should be secure, even if its encryption methods are public. Only the key you use to decrypt something needs to be private.
How to apply in software development?
It’s simple, really. Never believe that an encryption system that requires its encryption method is private. This is known as “obscure security.” Systems like this are inherently insecure. Once this encryption method is exposed to the public, it is vulnerable to attack.
content
In his book Cathedral and the Bazaar on Linux kernel development, Eric Raymond writes, “With enough eyes, all problems can come to mind.” He called this “Linus’s Law” in honor of Linus Torvalds. This means that if many people look at the code than few people look at the code it can be easier to expose errors in the code.
How to apply in software development?
If you want to get rid of the error, please let someone else see your code. A common practice that originates from the open source community is to have a developer make a pull request that contains code changes, and then have other developers review the pull request before merging it into the master branch.
This approach also goes into closed-source development, but according to Linus’s Law, pull requests don’t do as well in closed-source environments (where only a few people look at it) as in open source environments (where many contributors may be looking at it). Other ways to add more eyes to the code are pair programming and group programming. At least in an off-source environment, these are more effective than pull request reviews in terms of avoiding errors, because everyone is involved in the initial stages of the code, which gives everyone a better context to understand the code and potential errors.
content
Voss’s Law states that software slows down faster than hardware gets faster.
How to apply in software development?
Don’t rely on powerful hardware to run poor-performing code. Instead, write code that is optimized to perform well. This must be balanced with the maxim (Software Development Law: Knus’s Optimization Principle), which says that “premature optimization is the source of all evil”. Don’t spend more effort on making your code run faster than it would take to build new features for your users. Usually, this is a balancing act.
content
Donald Knuth wrote in one of his books that “premature optimization is the source of all evil,” which is often taken out of context and used as an excuse to not care about optimizing code at all.
How to apply in software development?
According to Knuth’s law, we shouldn’t waste our energy optimizing our code too early. However, according to Voss’s Law, we should also not rely on hardware fast enough to execute poorly optimized code. Finally, here’s what I draw from these principles: optimizing code that can be done easily doesn’t require much effort: for example, write a few extra lines of code to avoid going through loops that can contain a lot of projects. Optimize business-critical code that has been executing. Other than that, don’t put too much effort into optimizing your code unless you’ve identified a performance bottleneck.
Laws and principles are good. This allows us to assess certain situations from a certain perspective, without which we would not be able to understand the reasoning behind them. However, blindly applying laws and principles to every situation will not work. There will be subtle changes in each case, which may mean that a principle cannot or should not apply. Be suspicious of the principles and laws you encounter. The world is not black and white.
Past Recommendations:
With a budget of 1 million, Unicom paid for the failure of the bidding for the replacement of the domestic database
Alibaba Technical | “Does writing code lose competitiveness?”
Pass the cold to everyone, and ruin a large area of the offer
Current status, construction methods and development trends of cloud-native observability
Long press QR code to follow
Based on the idea of distributed design, architecture and system, it also discusses the bits and pieces related to R&D, not limited to code, quality system and R&D management.