Occam Razor Principle is one of the most powerful problem-solving principles, it can be applied to life and software development . It may be unknown and often misunderstood and underutilized.
Occam razor principle
Occam razor principle is defined in Chinese as: ", do not add entity if it is not necessary". It advocates: " When it comes to multiple competitive assumptions for the same prediction, one should choose the solution with the least hypotheses ". should prefer simple rather than complex before proving the assumptions.
Occam razor principle, that is, the simplest solution may often be the most correct and best solution. Do not waste more resources to do things that can be done with less resources.
In short, it means keeping things simple, and controlling complexity over simplicity, rather than artificially complicating things and seeking troubles.
Occam razor is widely used as a guiding principle in the fields of scientific research, management, investment, etc. In the absence of empirical evidence, it can be used as a means of rapid decision-making and establishing truth. In the field of artificial intelligence , in the process of machine learning , selecting mathematical models with lower complexity, the algorithm will often perform better. Although Occam razor is not applicable in all occasions, it is an inspiring guiding principle. The core significance of its is to not artificially complicate already complex problems , and simplifying the model is a relatively correct way.
Agile Software Development and Occam Razor Principles
"Agile Software Development" refers to the strategy of building and testing software in multiple iterations, because only a small part of the software is developed at a time. The main goal of agile is to quickly deliver workable software and try to be free of bugs.
Agile development
As the development continues, more new features are added during the development process, and unnecessary complexity will quietly enter the project. This leads to a huge quality assurance task, which is to review a huge and complex system at the end. If you apply the Occam razor principle to the process, this unnecessary complexity can be greatly reduced.
Agile software development can become complicated, especially after multiple iterations. The best way to reduce complications of this complexity is to apply the Occam razor principle to this process. Each software team should start with simplicity and only increase complexity after clearly identifying the need to add functionality.
In software design, the simplest code to implement the required functions is usually the best. Simple code is unlikely to have bugs, and the program usually runs faster.
The complexity of agile software development is to be added in small and frequent forms during the iteration process and eventually carefully evolve into the final product. This method achieves twice the result with half the effort, saves time and effort, and avoids unnecessary mistakes and corrections. The more complexity you add to your project, the more time it takes to encode implementation, test, and review new additions. Remember, the more complex the system, the higher the probability of failure.
Implementing this strategy can make the software easier to conceive, build and test. keeps things as simple as possible and also helps project-related people and end users, as they prefer to evaluate a simpler system than a complex one. By applying the Occam razor principle, the software development team will make faster progress and will be easier to apply corrections as the project continues.
software architecture design and Occam razor principle
Why is there a huge gap in working efficiency between programmers ? Research shows that the difference in productivity between two programmers with the same experience and education can easily differ by an order of magnitude (10 times), while the difference in debugging productivity may differ by 25 times.
Software Architecture
These very productive programmers can write simple, elegant, and easy-to-understand code and do a lot of things with very little code.
These "star" programmers gain these productivity in ways that most people cannot understand. That being said, ordinary programmers can also achieve the level of "star" programmers by doing something to improve their productivity.
To some extent, celebrity programmers do more by doing less. This is a bit counterintuitive, but if you consider that a programmer takes the time to write unnecessary code, or has to refactor the code consistently, it is just because his design can't simply deal with changing needs. Then they will have less time to write those "needed" code, thus reducing productivity. The effectiveness of these high outputs can be partially reflected by the Occam razor principle and the principle of making less.
Occam was a 14th century philosopher who knew nothing about software. However, he does understand the problem of complexity and the corresponding validity of simplicity in all things.
The principle behind Occam’s razor principle is that warns people to focus on simplicity, and achieve this by snatching anything that does not directly support the conclusion .
Modern Occam razor principle is often interpreted as: "'s easiest solution is almost always the best ". But modern explanations ignore the important point: is "simplest" to mean "the least assumption" . This principle is also often referred to as the "thrift principle": " adopts the simplest or most concise interpretation of ".
"The lady on the street is a witch--it was hers." This sentence is a very "simple" and unambiguous statement. It introduces very few entities and provides a simple explanation that initially looks a lot like that. But after careful analysis, this sentence is based on several very large assumptions. This sentence violates the Occam razor principle, and introduces unnecessary entities to support a conclusion:
1. The witch exists;
2. This lady is a witch;
3. She did it;
4. She was tasked with being a witch and whether she did it;
Actually, these factors have no connection with her so-called crime, but if we accept them without questioning their authenticity, it is likely to lead to a wrong conclusion-she is guilty. History has told us that many innocent people are sentenced to terrible deaths based on this plausible reasoning.
When it comes to software design, are you sure your reasoning has no similar flaws? Are you sure everything you do is really done to support the project goals? did you also unnecessarily introduce some elements, thinking that they were the results of your plan, but after careful examination, it was not the case?
Fortunately, one of the main advantages of agile software development is to focus on important things first and foremost . Specifically, it is reflected in: we pay less attention to technology, but more on providing value to end users.
Although there are various evaluations, it is generally believed that 80% of the functions in software applications have never or rarely used . Using agile software to develop can ensure that we continuously evaluate features and functions during the process and re-determine its priority .
Usually, when we approach the end of the project, we realize that most of the contents of initially in the requirements list are no longer relevant to , but because we delivered the highest value features early on, stakeholders are often satisfied early on development. Often they will decide that many of the initially required abilities are no longer applicable. A good development methodology focuses on providing value , which is very helpful to the principles advocated by Occam, but that is not enough.
As application requirements expand, the scale and complexity of software solutions are also increasing. Complexity introduces uncertainty, and uncertainty means risk; the greater the risk, the higher the probability of failure. To support a conclusion adds entities not just to increase complexity, but to double the complexity.
We illustrate this with this simple example: take a piece of white paper and a pencil, draw two dots on the paper, and connect the two dots with a straight line. Now add the third point and connect it to the other two points. You should have three points and three lines now. Now add the fourth point and connect it to the first three points. You should have four points and six lines now. Jump to 100 points and you will have 4950 lines or interconnected. Each time a new point is added, the number of lines connecting points increases dramatically. This is a very basic and simple mathematical problem.
The complexity here is not these points, but the number of lines linking these points will be increased for each additional point. If you think of entities in the software (classes, object instances, modules, components, databases, tables, etc.), you will also easily realize that as the number of entities increases, the complexity of the system is also increasing.
Although not all of these entities in the software have connections. But can you say with certainty that the changes of any entity will not have an impact on other entities? What happens if you have hundreds or even thousands of entities? That would be much more than anyone can actually understand, and then will you be sure you understand all the direct interactions?
What is the overall effect of all entities? What if the system does not perform the appropriate "concern isolation" and does not pass a good design like a well-named "self-interpreted documentation", resulting in the functionality of each entity not being so clear? "If" can be added infinitely, and they will increase with the number of entities you add. These "ifs" represent "hypothesis" in the Occam razor principle's view. The more assumptions, the more complex your system will be, so the higher the risk and the greater the probability of failure.
" assumption is masquerading as known unknown ", which represents a hidden, very real danger to system integrity and project success.
Assumption is an indispensable part of life. Suppose helps us pack the complexity of life into beautiful and neat little packages, helps us manage the vast amount of information that we have to process every minute of every day.
assumption is very useful, but incorrect assumptions can have catastrophic effects . Obviously, we cannot test every hypothesis, which is where experience cannot be replaced.
Obviously, the complexity of must be reduced, assuming that it must be challenged ! But how to do it? This is where art lies. If you look at the field of architecture, you will find that it has many similarities with the world of software. Both areas are very technical. Simplicity and elegance and the convenience of human interaction with outcomes are key factors in success in both areas, and in both areas there are many methods and forms that provide solutions, all of which are intended to meet the needs. Some of these solutions are obviously superior to others. In architecture, the results of “art” are often more obvious and very clearly visible because they are all manifested in appearance.
Inspiration, intuition or vision in great architecture is no less than inspiration, intuition and vision in great architecture. But it's not that obvious in software. The solution to one great software should be simple, elegant and pleasant to use . It is no coincidence that people who plan and design in both fields are called architects. In both areas, brilliant success requires unique talents.
Among many architects, their educational and working backgrounds are also diverse. But excellent architects all have one common feature: they will ask “why” without mercy! They question the key assumptions of the design and find solid reasons for the existence and function of the assumptions.
Excellent architectural architects and excellent software architects will have good reasons for everything in the design. The reason for each element will have good reason and can be explained simply.
If the existence of an entity and its functions cannot be explained simply, it is likely that your design may be affected by too many assumptions just as the woman at the end of the street is guilty of being inferred because of her assumption that she is a witch.
Many times, by asking "why" you will find that many requirements of are not displayed in the form of requirements, but are displayed in the form of solutions. can eliminate multi-layer assumptions by asking more "why" and let you find a real requirement, which is very different from what was originally stated. ( For example, customer needs are "faster", but they are shown with solutions like "carriage")
entities with clear purpose can often be well integrated in large designs, because no repetition helps to achieve simpler and more elegant designs. We need to use the Occam razor principle to ruthlessly remove unnecessary entities and develop simple, elegant, easy to explain and without assumptions.
Related principles
simplicity principle
, KISS: Keep it simple, stupid. keeps it simple and stupid.
KISS principle is one of the oldest principles in software design. KISS principle states that most systems of work best when keeping simple rather than complex ; therefore, simplicity should be a key goal of design and unnecessary complexity should be avoided. Software systems must be maintained by human developers with limited capabilities, so any increase in system complexity can also increase the difficulty of maintaining it.
, YAGNI: You Aren’t Gonna Need It. You won't need it.
This is a principle from extreme programming . This principle states that should not add functions unless it is really needed.
3, Last Responsible Moment: last response moment.
Make decisions as late as possible: Delay the decisions as much as possible until decisions can be made based on facts rather than uncertain assumptions and predictions.
4, Complex design
When the principle of simplicity is not followed, the software we obtained will have the following form of complexity:
4.1 Unnecessary features
Function creep (Feature Creep): In the process of continuously expanding or adding new functions to the product, the additional functions exceed the basic functions of the product, so it may lead to excessive complexity rather than simple design . Functional creep is especially common in software systems, where it is relatively easy to add new features that are not included in the original design. One of the results of this feature expansion is the well-known software bloat.
software bloat (Software Bloat): The subsequent version of computer program has significantly slowed down, using more memory or processing power, or having higher hardware requirements than the previous version, while only suspicious user-aware improvements have been made.
4.2 Over-engineering
designs products to be more robust or more complex than what their application requires . A classic example of overengineering is that there are too many layers of abstraction.
5. Oversimplified design
sees complex problems and problems much simpler than they actually are. Simple software design may focus only on current functional requirements, while ignoring certain non-functional requirements such as maintainability, scalability, and reusability.
related quotes
1, Everything should be made as simple as possible, but not simpler. – Albert Einstein
Everything should be as simple as possible, but not simpler. – Albert Einstein
Everything should be as simple as possible, but not simpler.
2, The business schools reward difficult complex behaviour more than simple behaviour, but simple behaviour is more effective. –Warren Buffett
Business schools reward difficult complex behaviour more than simple behaviour, but simple behaviour is more effective. –Warren Buffett
Business schools reward difficult complex behaviour more than simple behaviour, but simple behaviour is more effective. –Warren Buffett
Business schools reward difficult complex behaviour more than simple behaviour, but simple behaviour is more effective. –Warren Buffett
Business schools reward difficult complex behaviour more than simple behaviour, but simple behaviour is more effective. –Warren Buffett
Business schools reward difficult complex behaviour more than simple behaviour, but simple behaviour is more effective. –Warren Buffett
Business schools reward difficult complex beha
3, They say the world has become too complex for simple answers. They are wrong. – Ronald Reagan
They say the world has become too complex for simple answers. They were wrong.
4, Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple. - Steve Jobs
Simple may be harder than complex. You have to work hard to make your mind clean to make it simple.
5, There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. – C.A.R. Hoare
There are two ways of building software design. One way is to make it so simple that it is obviously flawless. Another way is to make it so complicated that there are no obvious flaws.
6, Always implement things when you actually need them, never when you just foresee that you need them. – Ron Jeffries
always implements the functions you really need, and never implements the functions you really need.
Reference:
https://naveenkumarmuguda.medium.com/occams-razor-in-software-development-56ee3e8b8ce8
https://www.cirdangroup.com/cirdan-blog/occams-razor-in-software-development
https://michaellant.com/2010/08/10/occams-razor-and-the-art-of-software-design/
https://effectivesoftwaredesign.com/2013/08/05/simplicity-in-software-design-kiss-yagni-and-occams-razor/
