The absurd laws of the software world

Have you ever wondered why smart people like software developers screw it up so often? There are people who did. In this post we review some of the unwritten laws that describe the behavior of professionals of computing.

My first computer was a Commodore 64. Almost 30 kb of RAM was for the system, leaving 32 kb for word processing, gaming, family business accounting, and just about everything I do with the 6 gb computer I own. now. That leaves the question open Does today's equipment respond to the needs of software or does the software use more hardware resources because they are available?

In fairness, the games are not the same, the graphics are not the same quality, and it would have been impossible to watch movies and listen to music. However, one cannot help but think that there are programs that release versions and consume more and more resources without really contributing anything new.

Here are the causes.

Zawinsky's Law

Netscape developer Jamie Zawinsky argued that Every program incorporates features until it is able to read emails. If he does not succeed, he is replaced by another who is capable of doing so.

When he said it, the joke was that he was referring to programs that were not originally intended as email clients. It stopped being funny when it was discovered that many apps on Google Play were asking for permission to access phone components and user data that they didn't need to do their job.

Some interpreted this as part of attempts to spy on users. But it's probably human nature to do something simply because it can be done.

Peter's principle applied to software

Lawrence Peter became famous for stating that in a hierarchy, a person works his way up to a position for which he is grossly incompetent. But he also had time to say something about complex projects:

"A complex project will become too complex to be understood even by its own developers."

Principle of least astonishment

Published in the IBM Systems Journal in 1984, this principle states that:

"If a required feature causes a big surprise, the feature may need to be redesigned."

In other words, if part or all of the software is very different from what the user was used to, the best is a redesign. Ideally, strive to achieve incremental improvements that are big enough to be impressive, but small enough to remain familiar for the user.

Too bad Shuttleworth didn't take it into account when it launched Unity.

Cybernetic Entomology Law

The first bug in computer history was real. A moth flew into one of the relays on a MARK II computer causing a malfunction.

Continuing with the metaphor, the law of cybernetic entomology holds that there will always be one more bug.

That is something that all computer users know. No matter how much an operating system is tested, there is always a fault that is discovered when it is too late.

Kernighan's Law

Linux Adictos has a plugin installed to ensure that we authors write in a search engine friendly manner. I hated it from day one. Any attempt to write with a bit of literary flight is immediately denounced with a red circle. As time went by I got used to it and I rarely have to make touch-ups.

The same thing happens to programmers, many times they are more interested in demonstrating their ability to code than in writing a simpler code that is easier to understand and maintain.

Hence Kernighan's law holds that:

Debugging is twice as difficult as writing the code in the first place. So if you write the code as smartly as possible, you're not, by definition, smart enough to debug it. '

The 90/90 rule

Anyone who has started a for-profit project in real life knows that every project is going to take twice as long and cost twice as much as budgeted, to make half the expected profit.

The computer world has its variants of this law. For example, one Tom Cargill said:

“The first 90 percent of the code represents the first 90 percent of the development time. The remaining 10 percent of the code represents the other 90 percent of development time.

Wasn't it clear? Perhaps Hofstadter's law will help:

"It always takes longer than you expect, even with Hofstadter's law in mind."

I guess Ubuntu and Fedora developers must know. Or at least remember it every 6 months.

Brook's Law

Open source software projects often have two problems; financing and lack of collaborators. Unless the second is not a problem. According to Brook:

"Adding labor to a software project that is behind schedule will delay it further."

Understandably, you don't just have to update the new encoders. More will have to be documented, it will take more bureaucracy to keep everyone in sync, and there will probably be fights.

And of course we cannot forget about friend Parkinson's and his claim that It doesn't matter how much empty space you start with. You will always need more. He was referring to office space, but the same goes for RAM and disk space.