In discussions surrounding software development, it is almost inevitable that one or two principles will be thrown around.
You’ve probably heard people say, “This won’t work because of the rule OF X!” . “Or” Don’t you know the ‘Principle Y’?” What type of software developer are you? .
There are many laws and principles to cite, most of which are based on truth. However, applying them blindly with absolute statements like the one above is a sure way to lead to ego 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 it can be applied to software development (and perhaps when it shouldn’t).
Pareto Principle (80/20 Rule)
content
The Pareto principle states that usually 80% of the effects come from 20% of the causes. The numbers 80 and 20 are not exact by any means, but the general idea is that the results are usually unevenly distributed.
We can see many areas of life that follow this rule, for example:
- The richest 20 percent of the world’s people generate 80 percent of the world’s income.
- 80% of crimes are committed by 20% of criminals (since 2020).
- We know that 80% of virus transmission comes from 20% of infected people.
How to apply in software development?
The main benefit we can derive from the Pareto principle is focus. It helps us focus on what’s important (20%) instead of wasting time and energy on what’s not important (the other 80%). The unimportant things are important to us because there are so many of them (and they seem urgent). But the best results are often achieved by focusing on the important few.
In software development, we can use it to focus on building the right features, for example:
- Focus on the 20 percent of product features that achieve 80 percent of product value.
- Focus on the 20% of errors that cause 80% of users to use exceptions.
- Focus on the 20% of total build time needed to implement 80% of the product’s functionality
- …
Just ask, “What’s the most important thing right now?” You 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 get that attention! Rapid iterations with regular user feedback allow data-driven decisions on important issues. Practices such as mainframe-based development with feature tags can help software teams achieve this goal.
Broken Windows theorem
content
Broken Windows cause damage, so soon all the Windows are broken.
As a general rule: chaos begets more chaos.
If our environment is primitive, we have an incentive to keep it that way. The more clutter there is in the environment, the lower the threshold for us to add clutter. After all, it’s already chaos… Who cares if we add a little more?
The main benefit we can derive from this rule is that we should be aware of the chaos around us. If it gets to the point where people get used to not caring about it, then it’s better to bring some order into the chaos.
How to apply in software development?
In software development, we can apply this to code quality: each code smell we introduce into our code base lowers the threshold for adding more code smells. We should [[Start Clean]] and keep the code base Clean to avoid this. The reason many code bases are so hard to understand and maintain is that broken Windows creep in and don’t get fixed fast enough.
We can also apply this principle to test coverage: once a certain amount of code enters a code base that is not covered by tests, more code is added that is not covered by tests. This is an argument for maintaining 100% code coverage (code that should be covered), so we can see the cracks before the window breaks.
Occam’s razor
content
A philosophical razor is a principle that helps explain something by eliminating (or “pruning”) unlikely 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 easiest to explain).
How to apply in software development?
We can use Occam’s razor in event analysis. You may have had a situation where a user reported a problem with your application, but you didn’t know what was causing the problem. Therefore, you are searching logs and metrics to try to find the root cause.
The next time a user reports an error, maintain the incident investigation document. Write down your hypothesis about what caused the problem. Then, for each hypothesis, list the facts and guesses. If the hypothesis proves to be true, mark it as fact. If an assumption turns out to be false, remove it from the document or mark it as false. At any point, you can now focus your time on the most likely hypothesis, rather than wasting time diverting attention.
The Dunning-Kruger effect
content
The Dunning-Kruger effect shows that inexperienced people tend to overestimate their abilities, while experienced people tend to underestimate them.
If you’re not good at something, you think you’re good at it. If you’re good at something and you think you’re not good at it – this can lead to imposter syndrome, which makes you doubt your abilities to the point that you feel uncomfortable among other people with similar skills (fear of others thinking you’re not correct).
How to apply in software development?
Being aware of this cognitive bias is already a good step in the right direction. It will help you better assess your skills so you can ask for help or overcome self-doubt and act on your own.
One practice that can help eliminate the Dunning-Kruger effect and impostor syndrome is pair or group programming. Instead of working alone, wallowing in self-doubt or superiority, you collaborate closely with others, exchanging ideas, learning and teaching as you work.
However, this only works in a safe environment. In environments where individualism is glorified, pair or group programming can lead to more self-doubt or more delusions of superiority.
Peter principle
content
The Peter principle states that as long as you are good at your job, you will be promoted until you are promoted to a job for which you are not qualified. Since you are no longer successful, you will no longer be promoted, which means you will live in a job that will not give 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 from a developer career to a management career. However, being a good developer doesn’t necessarily mean you’re a good manager. Alternatively, you can be a good manager, but don’t get the satisfaction of being a manager in a developer’s job, which means you’re not putting your best foot forward (which was my case). In either case, you’re miserable and don’t see any future development in the career path you have in front of you. In that 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 role you want.
Parkinson’s law
content
Parkinson’s Law states that work will always fill its allotted time with perfect scores. If your project has a deadline within two weeks, it will not be completed by then. It may take longer, yes, but no less than the time we allocate to it, because we are filling the time with unnecessary work or procrastination.
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 right now…” )
- Scope creep (” Sure, we can add this little feature, it won’t take us too much time……” )
To combat procrastination, we can set deadlines in days rather than weeks or months. What do you need to do in the next 2-3 days to move towards your goal? A (healthy one!) Deadlines can give us enough motivation not to sink into the trough of procrastination. To prevent scope creep, we should be very clear about what we are trying to achieve with the project. What is the measure of success? Will this new feature add to those metrics? Then if everyone understands that the work will take longer, we should add it. If the new feature doesn’t match the mission statement, ditch it.
Hofstadter’s law
content
Hofstadter’s law states that “it will always take longer than you expect, even if you take Hofstadter’s law into account”. Even if you understand this law and increase the amount of time allocated to your project, it will still take longer than you expected. This is closely related to Parkinson’s Law, which states that work will always be allocated its time with perfect scores. It’s just hofstadter’s law says it takes more time to fill than it takes to allocate. This law is supported by psychology. We’re prone to what’s called the “planning fallacy,” which is that when estimating work, we often don’t consider all the available information, even if we think we’ve already considered 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 too optimistic. To reduce the effects of Hofstadter’s law, we can try to estimate as objectively as possible. Write a list of assumptions and facts about the project. Mark each list 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 the estimates and let your brain think about them. Compare them with other people’s estimates and discuss the differences. Even so, it is still an estimate and probably does not reflect reality. If an estimate isn’t based on statistics or other historical data, it’s worth very little, so it’s always good to manage expectations with someone who’s asking you to estimate — it’s always going to go wrong. If you make it as objective as possible, it reduces errors.
Conway’s law
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 a system, you are likely to have 10 subsystems that communicate with each other.
How to apply in software development?
We can apply what’s called the inverse Conway maneuver: create the organizational structure that best supports the system architecture we want to build. There is no fixed team structure, but enough flexibility to create and disband teams that is best for the current state of the system.
Murphy’s law
content
Murphy’s Law says that anything that can go wrong, will go wrong. It is often cited after an accident.
How to apply in software development?
Software development is an error-prone profession. The chief source of error is error. There is no software that doesn’t have bugs or events that challenge the user’s patience. We can resist Murphy’s Law by adopting habits that reduce the impact of errors in our daily software development practices. We can’t completely avoid errors, but we can and should reduce their impact on users. The most useful counter to Murphy’s Law is feature labeling. If we use a feature tagging platform like LaunchDarkly, we can deploy changes into production after feature tagging. We could then activate the internal Dogfooding flag with a targeted release, then release it to a small number of friendly Beta users, and finally release it to all users. This way, we can get feedback on changes from an increasingly critical user base. If the change goes wrong (and some of the time it does), the impact is small because only a small percentage of the user group is affected by it. Also, the flag can be quickly turned off.
Brooke’s law
content
In his classic “The Myth of the Man-month,” Fred Brook famously said that adding people to a late project makes it even later. Although this book is about software projects, it applies to most types of projects, even outside of software development. The reason that adding people does not speed up a project is that the project’s communication overhead grows exponentially with each person added to the project. Two people have one communication path, and five 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 new people are added to projects, late projects are even later.
How to apply in software development?
Very simple. Change deadlines instead of adding people to projects that are already late. Be realistic about your expectations for adding new people to a software project. Adding people to a project may speed things up at some point, but not always, and certainly not immediately. It takes time for people and teams to get used to the 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 a new person should accomplish and what you expect when you add that person to the project.
Post’s law
content
Postel’s Law, also known as the conservatism principle, states that you should be “conservative in what you do and open in 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 how you handle this data so that your software is not compromised by invalid or malicious data.
How to apply in software development?
This law comes from software development and is therefore very directly applicable. Interfaces between your software and other software or developers should allow different forms of input to achieve robustness:
- For backward compatibility, the new version of the interface should accept the old version and the new version of the data
- 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.
But if we’re willing to accept data in different formats, we have to be conservative in how we deal with that data. We have to review invalid values and make sure we don’t compromise the security of the system by allowing too many different formats. SQL injection is a possible attack by being too lax with user input.
Kirchhoff’s principle
content
Kerchkhoff’s principle states 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 easy, really. Never trust an encryption system that requires its encryption methods to be private. This is called “security in obscurity”. A system like this is inherently insecure. Once the encryption method is exposed to the public, it is vulnerable to attack.
Linus’s law
content
In His book Cathedrals and Bazaars, about Linux kernel development, Eric Raymond writes that “enough eyes can make all the problems emerge.” He called it Linus’s Law, in honor of Linus Torvalds. This means it’s easier to expose errors in code if many people look at it than if few people look at it.
How to apply in software development?
If you want to get rid of errors, let someone else look at your code. A common practice originating in the open source community is to have developers make pull requests that contain code changes, and then have other developers review the pull requests before merging them into the main branch. This goes into closed source development as well, but according to Linus’ law, pull requests don’t work as well in closed source environments (where only a few people look at it) as in open source environments (where many contributors may look at it). Other ways to add more eyes to your code are pair programming and group programming. At least in closed source environments, these are more effective at avoiding errors than pull request reviews because everyone participates in the initial stages of the code, which provides a better context for everyone to understand the code and potential errors.
The laws of voss
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 poorly performing code. Instead, write code that is optimized to perform well. This must be balanced against the maxim (Law of Software Development: Knuth’s Optimization Principle) that “premature optimization is the root of all evil.” Don’t put more effort into making your code run faster than you put into building new functionality for your users. Usually, it’s a balancing act.
Knuth’s principle of optimization
content
Donald Knuth wrote in one of his books that “premature optimization is the root of all evil,” which is often taken out of context and used as an excuse for not caring about optimizing code at all.
How to apply in software development?
According to Knuth’s Law, we should not waste energy optimizing code prematurely. However, by Voth’s Law, we should not rely on hardware to be fast enough to execute poorly optimized code either. In the end, this is what I conclude 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 a loop that might contain a large number of projects. Optimize the business-critical code that has been executing. Beyond that, don’t put too much effort into optimizing your code unless you’ve identified a performance bottleneck.
Keep the suspect
Laws and principles are good. This allows us to evaluate situations from a point of view that we would not otherwise know. However, blindly applying laws and principles to every situation will not work. In each case there are subtle variations that may mean that a principle cannot or should not apply. Be skeptical of principles and laws you encounter. The world is not black and white.
Motoring. IO/laws-and-PR…