Laws or laws can guide us and let us learn from the mistakes of our peers.
In this article, I will introduce the five laws that appear in my mind every time I design or implement software. Some of them are related to development, and some are related to system organization. They can help you become a qualified software engineer.
Murphy's Law
"Everything can go wrong, it must go wrong."
This law was derived from Edward Murphy, a space engineer's response to a failed rocket test in the early 1950s. The enlightenment of this law is that we always use defensive design in key places of the system, because there are always mistakes in some parts of the system!
This law is easy to introduce into the field of software engineering. When you expose the software to end users, they will creatively enter some unexpected content and make the system down. So you need to make your software robust enough to detect and warn of unexpected behavior.
When you run software on a machine, problems can occur anywhere-from the system on the hard drive to the power supply in the data center. So you must ensure that the architecture you design can handle failures at every level.
I have had the opportunity to experience Murphy's Law several times. For example, I used the string null to represent null values ​​in a batch processing framework. I did n’t think this was a problem until a user named Null submitted a transaction order, and our reporting process was interrupted by several Hours ... Another time, in another project. When everything is ready to be deployed to the production environment, a sudden failure of the Azure infrastructure causes our servers running automated scripts to go down.
The lessons in the real world remind me of the hardship of my life-"Everything can go wrong, it must go wrong". So, keep Murphy's laws in mind and design robust software.
Knuth's law
"In (at least most of) programming, premature optimization is the source of all evil."
This law is also one of Donald Knuth's classic quotes, it warns us not to optimize the code in the application prematurely, and then optimize when it must be optimized.
Indeed, simple and easy-to-read source code can meet 99% of the performance needs, and can improve the maintainability of the application. The use of simple solutions at the beginning also makes it easier to iterate and improve when later performance problems arise.
In programming languages ​​for automatic garbage collection, string concatenation is often an example of premature optimization. In Java or C #, String objects are immutable, and we learn to dynamically create strings using other structures, such as StringBuilder. But in fact, until you analyze an application, you don't know how many times the String object has been created and how much impact it has on performance. So first write the code as neat as possible, and then optimize it when necessary, it is often more meaningful to do so.
However, this rule should not prevent you from learning the performance trade-offs of programming languages ​​and the correct data structures. And, like all other performance issues, you have to measure overhead before optimizing.
North Law
"Every decision is a trade-off"
Well, I admit that this is taken from Dan North's speech Decisions, Decisions, it is currently not a recognized law. But this quote affects every decision I make, so I put it here.
In the day-to-day life of developers, we make countless decisions every day. From named variables to automated (manual) tasks, to defining platform architecture.
This quotation emphasizes that no matter what choice you make, you will always give up one or more options
But this is not the most important. The most important thing is to make informed decisions, understand other options, and understand why you did not choose them. You should always weigh and make decisions based on the information you currently have.
But if you later learn about the new information and discover that the previous decision was wrong, it does n’t matter. The key is to remember why you made that decision, and re-evaluate the new options before making a new rational decision.
Repeat
"Every decision is a trade-off"
So, make choices and be aware of all options.
Conway's law
"The architecture of the system design is limited to the production design, reflecting the communication structure of the company organization"
In the 1960s, an engineer named Melvin Conway noticed that the company's organizational structure affected the design of the systems they developed. He described this view in a paper and named it "Conway's Law".
This law is very applicable to the field of software development, even reflected on the code level. The organizational structure of each team that delivers software components directly affects the design of the components.
For example, a centralized team of developers will develop an overall application that couples components. On the other hand, distributed teams will develop separate (micro) services with clear separation of concerns in each part.
These designs are not good or bad, but they are all affected by the way the team communicates. There are a large number of open source projects for independent developers around the world, usually modular and reusable libraries, which is a very convincing example.
Today, it has become a trend to decouple large integrated applications into microservices. This is great because it speeds up delivery and use of projects. But you should also keep Conway's Law in mind and invest as much work as technology development in the organization of your company.
Trivial Law (Parkinson's Trivial Law)
"Organization members put a lot of effort into trivial matters."
The law argument is that the time spent in a meeting is inversely proportional to the value of things. Indeed, people prefer to focus their attention and opinions on things they are familiar with, rather than on complex issues.
Parkinson gave an example. During a meeting, members discussed two things: building a nuclear reactor for the company and building a carport for employees. Building a reactor is a huge and complex task, and no one can fully control the overall situation. They completely trusted process and system experts and quickly accepted the project.
On the other side, building carports is something that ordinary people can do, and everyone can have an opinion on color. In fact, every meeting member will express their opinions, making the decision to build a carport takes much longer than building a reactor.
This law is well-known in the software industry, and this story was later called the carport effect
For example, developers will spend more time discussing proper indentation or function naming rather than discussing class responsibilities or application architecture. This is because everyone can recognize the change of several characters, but the change of the project structure requires a huge cognitive load
Another example of the carport effect you can notice is the Scrum demo. Do n’t get me wrong, I like presentations, I think it ’s a great opportunity to face users and get feedback on the app. But usually the discussion during the Scrum presentation will turn to trivial issues instead of looking at the big picture. These discussions are also important, but you should pay attention to weighing more important and complex issues.
Once you understand this pattern, you will discover this behavior in meetings and communication. I'm not asking you to avoid "small" problems in every discussion. Raising your awareness can help you focus on real problems and prepare for these meetings.
in conclusion
These five laws are just some examples of lessons learned in our industry. As the experience of software development grows, we will learn more. Although some of these laws now seem to be common sense, I always believe that understanding these principles can help you identify and respond to these patterns.
Shenzhen Happybate Trading Co.,LTD , https://www.happybateprojectors.com