21 "rules" of computer programming"

21 "rules" of computer programming"

Source: http://www.devtopics.com/21-laws-of-computer-programming/

Introduction

Every experienced programmer knows that there are some rules in software development. However, if these rules are broken, they will not be punished. On the contrary, there will be some rewards.

1. Once a program is released, it means it is outdated.
2. It is easier to adjust the needs according to the program than to make the program adjust as needed.
3. If a program is useful, it will be changed.
4. If a program is useless, it must be commented out.
5. In any program, only 10% of the code is executed.
6. The software will expand infinitely to occupy all system resources.
7. Any valuable program will contain at least one error.
8. The chances of a demo program being flawless are inversely proportional to the number of people paying attention to it. The amount of money that will eventually be spent is the square of the original number.
9. A fatal error of a program will not be detected until it is released for at least half a year.
10. Uncheckable errors are endless and exist in various forms. On the contrary, verifiable errors are theoretically limited.
11. Over time, the effort required to correct an error increases exponentially.
12. The complexity of the program continues to grow until it exceeds the ability of the programmer who maintains it.
13. If you have not read a piece of code that you have written for a few months, it is better to repeat it as a code written by someone else.
14. In every small program, there will be a large piece of code to crack the shell.
15. The sooner you start writing code, the longer it takes.
16. If a project is not carefully planned, it will take two times more time than expected to complete it. On the contrary, if the project is carefully planned, it only takes one more time.
17. Adding programmers to a project that lags behind the project will only make the project lag behind the project.
18. A program can be completed between 90% and 95%.
19. If you automate messy code, you will get a bunch of poorly automated code.
20. Create a program that can be used by a dummies, and only one dummies want to use it.
21. Users do not know what they really want until they use a program.