Bits, Bytes, and Bylaws: Timeless Computing Laws (Part-1)

From Whimsical to Principled: The Laws of the Computing Realm

In this article, we dive into the computing world, not through the usual lens of code and algorithms, but by examining its underlying principles – the unseen 'laws' that govern this digital universe. Much like physicists who unraveled the mysteries of the universe, computer scientists have endeavored to formalize the seemingly chaotic universe of computing.

Have you ever wondered why making small changes to structure can break code behavior? Or why, no matter how much we plan and estimate, we still bite more than we can chew. While those were my personal experiences, these areas are very well-researched. Let’s explore some laws I have come to deeply appreciate over the years as a software developer and manager.

Hyrum's Law (Hyrum Wright)

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody

I read it as, “If you build it, they will come... and rely on the quirks!”

Take JUnit, for example. It tells developers the test execution order isn't guaranteed, yet many write tests as if they're set in stone. If JUnit ever changes this order, it's not just the tests that break; it's developer hearts, too.

Hyrum's Law really comes into play, much like the theory of relativity – it's always true, but you only really notice its effects when your API or library speeds up to a large user base.

Hofstadter's Law (Douglas Hofstadter)

It always takes longer than you expect, even when you take into account Hofstadter's Law.

You know the drill if you've ever been in a Scrum team chasing a 15-day sprint. You add a buffer for the unexpected 'just in case' tasks, but somehow, your stories still end up like uninvited guests in the next sprint's party. That's Hofstadter's Law in action.

How do you minimize the impact?

Opt for even shorter estimation cycles. While estimating a 15-day sprint is a leap forward from a 6-month waterfall plan, breaking it down to even shorter estimates (think Kanban) is where you really decrease the uncertainty impact. It's about fine-tuning your focus: shorter horizon estimates allow for rapid adjustments and a clearer understanding of immediate priorities, significantly reducing the surprises.

Parkinson’s law

Work expands so as to fill the time available for its completion.

Ever noticed how a 15-day deadline means a 15-day hustle, but give yourself 90 days, and it'll take every bit of those 90? When time stretches, so does our tendency to over-engineer, over-design, and “over” everything.

This phenomenon isn't just about deadlines; it's about the creative and efficient use of constraints. Frederick P. Brooks puts it aptly

The worst buildings are those whose budget was too great for the purposes to be served. Bach's creative output hardly seems to have been squelched by the necessity of producing a limited-form cantata each week. I am sure that the Stretch computer would have had a better architecture had it been more tightly constrained;

Brooks Jr., Frederick P.. Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition (p. 61). Pearson Education. Kindle Edition.

And if you need a real-life parallel, look no further than Indian weddings. They're the perfect embodiment of Parkinson's Law: the grandeur and scale expand to consume every bit of available budget and time, often spectacularly so!

Peter Principle

In a hierarchy, every employee tends to rise to his level of incompetence.

It's a real head-scratcher for organizations. It suggests that being great at your job can lead to a promotion... into a job you're not great at.

The Peter Principle is a nudge for companies to rethink promotions – because sometimes, the best way to climb the ladder might be to just add more rungs where you are.

Let’s have a look into a few more such laws in part two of the article