Planning is governed by some important principles that everyone involved should be aware of. But there are some other programming principles that may prove to be even more beneficial than the first.
These principles try to teach you how to be smarter with your code, some are weird and some are humorous. But they are all equally practical and important…
The beginning of Bloat
The principle has so many variations that it is difficult to choose one as the main one. Perhaps the most "official" version is Zawinski's law, which was named after Jamie Zawinski and refers to The Art of UNIX Programming:
“Every program tries to expand until it reads messages. Programs that cannot be extended are replaced by those that can.”
It speaks to the tendency of programs to attract more and more features over time and inevitably lead to a greatly increasing complexity. The continuing acccase new features that have nothing to do with the main purpose of the program, leads to a "bloat" of the application, which is often undesirable.
This also applies to software performance:
“Software expands to consume them all availableresources.”
In the 90s, hard drives, CPUs, and RAM were very limiting for developers, who had to package their code within certain limits. Today with bigger disks, faster CPUs and more RAM, we still push code within limits. Everything grows with time.
The "Worst is better" mentality
His mentality Worse Is Better, was invented by Richard P. Gabriel in an essay he wrote about software quality:
"Software that is limited but simple to use may be more attractive to the user and the marketer than vice versa."
In other words, if your software aims to do one thing and does it well, keep it that way. Keep it simple. The more you grow it, the more unused it will become and the more unwanted by them users.
Peter's software authority states:
"An overly complex project will eventually become too complex to be understood even by its developers."
The Eagleson principle
"Any code of yours that you haven't looked at in six months or more could also have been written by someone else."
This seemingly derogatory principle is actually something you should take very seriously. The point is, no one is perfect.
You may think you are a genius programmer today, but tomorrow there will always be something more you can learn. If you look at your old code again, you can evolve it more because you have evolved too.
The beginning of the least surprise
"If a necessary feature comes as a big surprise, you may need to redesign it."
It was first published in the IBM Systems Journal in 1984, but this principle is still surprisingly relevant today (perhaps more than ever).
It essentially deals with the delicate balance between innovation and familiarity: if a software is very different from others of its kind and does not meet the expectations of users, then they will probably not adopt it.
It is better to seek improvements that are large enough to be impressive but also small enough to remain familiar.
The principle of Entomology
"There is always another bug."
It is often referred to as Lubarsky's law, but it is not clear who this Lubarsky is.
However, the principle applies to all developers: no matter how clean the code you write, and how much you try it: there will always be another error.
The Kernighan principle
"Debugging is twice as difficult as writing code. So if you write the code as smartly as you can, by definition you will not be as smart about debugging. ”
Brian Kernighan, worked with the C programming language, and became famous for this insightful law. The essence of this principle is this: write good code, write readable code, write plain code, write anything as long as it is not smart code.
Trying to surprise with the complexity of your code will have the exact opposite effect. The code you write may be smarter, maybe even smarter than you if you outperform yourself, but who will debug? The harder it is to understand the code, the harder it will be to debug errors in the debug.
The beginning of the Ninety Ninety
"The first 90 percent of the code corresponds to the first 90 percent of the development time. The remaining 10% of the code represents the remaining 90% of development time. "
This confusing principle belongs to Tom Cargill. Let's see why it is very basic.
Planning can be very frustrating: no matter how close you think you are to the end of a project. You are far from your best estimates. When you think you're done, you're only halfway there.
The Parkinson's principle
"The work is being expanded to fill the time available for completion."
This principle belongs to Cyril Northcote Parkinson. It is a broader principle that applies perfectly to planning and goes hand in hand with the above principle of ninety ninety: the longer you have to complete a project, the more time you will need. In software development, "ending early" is more or less a myth.
Parkinson's law is why modern professional developers often recommend flexible project management principles and management tools such as Asana.
The beginning of Brook
"Adding human resources to a project that was delayed will delay it further."
The next time you delay a project, remember that adding encoders will not finish it faster.
In fact, it may take even longer to complete. Not only will you have to explain to the new developer what is going on, but it may also come into conflict with existing developers.
Do you know other weird programming principles we haven't mentioned?
Very interesting laws, although most show that developers are not the most optimistic people (and one law says that is certainly not the case)