During my MSc degree in Computer Science, I decided to specialize in Software Engineering. I did several elective courses in software architecture, software requirements, and software quality. All those courses had a shared presentation of laws that can be applied to programming and software development. Let’s call them laws of programming.
When talking with friends and colleagues, if someone brought one of these laws of programming into the conversation, I noticed that some people were nodding their heads. Yet, it was evident that they had never heard about the laws and the minds behind them.
So I’ve decided to talk a bit about 5 of these laws. Of course, there are much more, but here’s a starting point.
Brook’s law
Adding manpower to a late software project makes it later.
Fred Brooks coined this law in The Mythical Man-Month. If a project is running late, simply adding more people will most likely not produce the intended result, and the project time would be longer rather than shorter. This is because an increase in people drives communication overhead. Plus, the time needed by new project members to understand the project must also be accounted for.
Linus’s law
Given enough eyeballs, all bugs are shallow.
Named after Linus Torvalds, the creator of Linux, this law means that the more widely available the code is for testing and experimentation, the more quickly all forms of bugs will be discovered.
Moore’s law
The number of transistors on an integrated circuit will double in about 18 months.
Besides this law, Gordon Moore, co-founder of Intel, predicted that computer processing power would double every two years. His predictions from 1965 were surprisingly accurate, although now it doubles every 1.5 years.
Conway’s law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
This law was named after Melvin Conway in 1967. In many organizations (probably yours as well), teams are divided into functional skills. This means, for example, that you’ll have teams of front-end, back-end, and database developers. This law means that it’s hard for someone to change something in the codebase if what they want to change is owned by someone else.
Ninety-ninety rule
The first 90% of code takes 10% of the time. The remaining 10% takes the other 90% of the time.
This law is ofter attributed to Tom Cargill or John Bentley. It means that the last 10% of the coding is often where more challenges appear when debugging, fixing more complex features, or simply giving the final touches on a project.
Did I miss your favorite law? Do you agree with each of these laws or not? Let me know! 