Apply Murphy’s Law in Information Technology

Tram Ho

Murphy's law, or so-called butter cake's law, says: " Anything can go wrong, it will happen " (English: Anything that can go wrong, will go wrong .)

This law was tested by dropping a piece of butter bread from above and somehow the number of times the butter-stick touched the ground was always higher. That is why this law is also known as the butter cake law . A very sweet name for one of life's most bitter laws .

The truth is that the buttery stick is always heavier than the other. This has reflected on the impact of gravity causing the heavier wheel to always fall to the ground and it will not always fall on the opposite side for the same reason. Anyway, of course, the buttery stick is always heavier than the other side.

And in life, bad and negative things always make me worse. So if there are two good technology solutions, then you must choose the best of the best solutions ( According to Murphy 5's law: "If anything cannot be wrong, it will still be wrong" ).

On the basis of Murphy's law, in 2003, the Nobel Prize in Mechanics once again honored Edward A. Murphy and two other late scientists – John Paul Stapp and George Nichols – who helped him prove Murphy's Law. It wasn't until 54 years after it was announced that Murphy's Law was recognized.

Solutions against Murphy's Law in Software Engineering will help to understand why radical and safety measures are needed in software development. A field which is a part of human knowledge and civilization through each period from the time when there was no human species to the present time and in the future.

1. Background was born

This law was laid down by Edward Murphy , an aerospace engineer, in response to a failed missile test in the early 50s.

In 1949, at Edward Air Force Base in California (USA), officers were doing an experiment of Project MX981 to determine the last time the ratio of the acceleration of gravity (symbol G: G ravitational acceleration) that an How much can you bear when the plane crashes. They hope that their research will be applied in future aircraft designs.

To simulate the impact of an aircraft collision, they used a rocket ship called the Gee Whiz. The ship flew at more than 200 miles per hour under a half-mile long journey, then suddenly stopped in less than a second. The problem is, instead of just finding the rate of acceleration that a person can withstand, they need a real person to test it. Colonel John Paul Stapp – a specialist in physics for the air force – at that time volunteered to be a tester. During those few months of physical exhaustion flights, Stapp was seriously injured. He suffered fractures, concussions and broken blood vessels in his eye, all for the sake of science.

This is a picture of Colonel John Paul Stapp testing the Gee Whiz missile ship at Edward Air Base (USA).

Murphy had an idea: Put a sensor on Professor Stapp's immobilizer on the rocket ship. These sensors have the effect of accurately measuring the data of the gravitational acceleration force when the rocket ship is stopped suddenly, so the data will be somewhat clearer.

There were some rumors surrounding the events that happened that day, about who contributed what to the creation of Murphy's law. And the end result is almost approximate.

On the first attempt, after Murphy mounted the sensors to the fixings, they did not get any results. All sensors are not installed properly. Each set has 2 installation lines and both are misplaced.

As Murphy investigated the cause, he muttered that it was technicians. " If there are two ways to do something, one of which leads to bad consequences," he said, "he would do it that way ."

This is the reason why we should FOCUS or die . And in programming, there is best practices for function building where each function is responsible for only one way when there is modification of the system, there is only one way of modification.

Not long after, Murphy returned to Wright Airport School where he was stationed. But Stapp , a humorous man with his lucid intelligence, recognized the commonality of Murphy's statement. During a press conference, he said that all the exact safety data the team got were based on the understanding of Murphy's law, which meant: “ If something went wrong then it will go on like that . "

2. Interpret Murphy's law

Murphy's Law shows us the view of life is not as a dream and a real reality, very real but bad and very bad but real

Murphy's law is essentially supported by an authentic natural law that is the disorder of the system

This law is used frequently in thermodynamic research to explain why energy is transformed from one form to another. It proves that in our universe, systems often come to an end of disorder and chaos.

In software engineering there is also a commonly applied entropy law based on the law of entropy in thermodynamics. It is about software systems that when updated and modified, the turbulence in the system increases, And that's called software entropy. So in the software development field, writing simple, easy-to-read code that meets 99% of the system's performance and upgrading the system will save time and significantly improve software maintenance. . Starting with a simple solution will also make it easy to iterate, optimize, and improve when performance problems arise.

Murphy's Law also reminds engineers, computer programmers, and scientists of one obvious fact: Systems fail. In some cases, the failure of the system signals that the test will be repeated a lot or will cost a lot of investment.

3. Apply Murphy's law in software engineering

When users use the software, they find creative ways to enter something into the input that is not in the plan of testing and disrupting the system. So you need to make your software powerful enough to detect and warn unwanted behavior.

When the software runs on the machine, anything can go wrong. From the drives that support the operating system, the operating system failure, the RAM, the CPU, the storage hard drive, the motherboard to the server's power supply, the data center and the risks of force majeure. Therefore, it is important to ensure that you have a good design of the defensive system and a good design for failure at every level of the system architecture.

For example:

  • Setting the default null for the string in the framework is a disadvantage for the trading system when someone whose name is Null or the real name containing the word Null has access to the system and cause confusion. in the report there is a visitor but the language identifies as having a string with nothing ( null )

  • In the cloud project everything seems ready to be deployed to the automated production environment until the Azure server has an infrastructure problem that causes the server to be used to run the scripts itself. Mobility in the cloud is hindered.

4. Respond to Murphy's Law in software engineering

To take measures against this rule, there are some software techniques applied such as defensive programming , version control , preparation of doom scenarios for the attacks of Zombie server , TDD, MDD, … . are against the law of best practices is certainly room not stick bug.

As programmers, we learn a lot of knowledge. We collect, organize, store and harness knowledge from a wide variety of disciplines to analyze and design systems. But knowledge is changing from day to day. You learned a new technology today but may be outdated tomorrow. Or the nuclear techniques may be sublime, but the changing economic, social, human context still becomes obsolete. So only need to master the basic knowledge.

Knowledge is constantly changing over time and so does a country's IT legislation. Knowledge changes very quickly. Your understanding of a requirement may change after meeting with the client. The government changed a regulation and some business logic became obsolete. And it is possible that the algorithm chosen to solve the problem may no longer be suitable in the future. These uncertainties help us to draw some experience that we will spend most of our time maintaining the system, upgrading the system, testing the system, reorganizing the system, always improving the code ( to code for the simplest way), and reflect the knowledge inside our system .

Most people assume that maintenance starts when an application is released, that maintenance means bug fixes and functionality enhancement. We think these people are wrong.

Programmers are constantly in maintenance mode. For the reason, our understanding changes from day to day. New requirements emerge when we are designing systems or writing code. Perhaps the environment is constantly changing. Whatever the reason, maintenance is not a discrete activity, but a regular part of the entire development process.

When doing maintenance, we must find and change the knowledge representations and code within the application. The problem is that it is easy to duplicate knowledge in the specifications, processes, and programs we develop. And if there is a problem that is not clear, according to Murphy's law, it will inevitably lead to too false.

There are many reasons to write code so that in a while you look back to open the source code of the system to maintain, upgrade will see easy to understand, easy to test, easy to edit to be maintainable and upgradeable. the system . If not, the system's code will confuse you and lead to errors.

The only way to reliably develop software and make your software development process understandable and maintainable is by following the DRY (Don't Repeat Yourself) principle.

Have the same thing shown in one or more places. If you change one, you have to remember to change the others. If you forget, the whole program will crash.

Most of the duplication in the code is one of the following:

  • Duplicate imposed
  • Duplicate code by accident
  • Duplication due to impatience
  • The overlap between developers

5. References

Share the news now

Source : Viblo