21 laws of Software Development

 

· AnyProgramOnce published, it means it is out of date.
· It is easier to adjust the needs according to the program than to make the program adjust as needed.
· If a program is useful, it will be changed.
· If a program is useless, it must be commented out.
· Only 10% of all programsCodeWill be executed.
· The software will expand infinitely to occupy all system resources.
· Any valuable program will contain at least one error.
· 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.
· A fatal error of a program will not be detected until it is released for at least half a year.
· Uncheckable errors are endless and exist in various forms. On the contrary, verifiable errors are theoretically limited.
· Over time, the effort required to correct an error increases exponentially.
· The complexity of a program continues to grow until it exceeds the ability of the programmer who maintains it.
· If you haven't read a piece of your own code for a few months, it's better to repeat it as a code written by someone else.
· In every small program, there will be a large piece of code to be broken out.
· The sooner you start writing code, the longer it will take.
· 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.
· Adding programmers to a project that lags behind the project will only make the project lag behind the project.
· A program can be completed between 90% and 95%.
· If you automate messy code, you will get a bunch of poorly automated code.
· Create a program that can be used by a dummies, and only one dummies want to use it.
· Users do not know what they really want until they use a program.