8 programming laws that every developer encounters

Author | Adam Hughes

Translator｜Hirakawa

Planning｜marsxxl

This article was originally published on Level Up Coding.

Over the years, I have observed some basic patterns and pitfalls that recur in the engineering process. Interestingly, they have nothing to do with the endless debate on engineering blogs. For example, I can’t recall a single time my team missed a deadline due to a poor understanding of SOLID principles. Occasionally, I come across a “law” that perfectly describes the problem I’m experiencing. It’s irritating that these handy engineering laws are often hidden in the corners of podcasts, audiobooks, and blogs. So I’ve put them together into a list of my 8 favorite programming rules that you’re sure to encounter in real life too.

1 Murphy’s second law

Murphy’s Law[1] is the most famous and well-known law on this list, and it is usually stated as:

“As long as everything can go wrong, it will go wrong.”

However, what really touches the pain point of all engineers is Murphy’s second law:

“Any solution has its own problems”

Or, nothing is as simple as it seems[2]. Murphy’s Second Law eloquently summarizes the following observation: As engineers, anything we touch increases the risk of the system, and therefore, the risk can be reduced by avoiding system changes.

How to use

As I grew into a full-fledged engineer, I spent less and less time programming. In fact, I’ve slowly come to think that writing new code is a systemic risk; it adds complexity, maintainability, and possibly bugs. Considering Murphy’s Law, I have the following suggestions:

1. Process changes and vendor software are preferred over homegrown solutions.

2. Avoid falling into the quick fix trap because you’ll have to go back and improve later. Do it right the first time.

3. test. test. test. The higher the test coverage, the better the application can adapt to the complex environment.

2 Conway’s Law

In 1967, Melvin Conway revealed such a truth[3]:

“The architecture of design systems is governed by the communication structures of the organizations that generate those designs.”

Or, more straightforwardly:

“If you have 4 teams developing compilers, you get 4 compilers.”

Conway’s Law has a big impact because software engineers often have to build systems with colleagues scattered around the world. For example, when I was working at a large custodian bank, I was involved in developing a transaction system with many services. All but two services communicate via an internal message bus. However, inexplicably, the two services communicate via a public API over the Internet.

Just as brain functions operate as subcomponents, so does any spatiotemporally dispersed workforce.

I went on to discover that the service that communicated over the Internet was the only place where the US team and the Indian team overlapped. The system architecture is basically two hemispheres: microservices in the US on the left and services in India on the right, with a minimal API between them. Fundamentally, this API is the Atlantic.

How to use

In all areas of technology, one of the best words to say about the remedy for Conway’s Law is the Inverse Conway Maneuver. In other words, the desired architecture is facilitated by improving the team and organizational structure [4]. In this regard, Amazon’s Double Pizza team is probably the most famous example, the story goes like this:

• In 2001, Amazon.com was a tightly coupled large monolith that was difficult to maintain [5].

• The website was rebuilt as multiple microservices, each supported by a dedicated team. As a result, the team was restructured along business lines (eg shopping cart, recommendations, advertising) rather than technical lines (eg database, QA, development).

• The T-team is kept small—the number of people is limited to two pizzas that can feed everyone on the team. The company and website went through a refactoring at the same time.

That’s fine, but you probably don’t have the ability to make a big company-wide organizational change. Don’t worry, there are several ways to get your organization, or at least your team, out of Conway’s Law:

1. The most important work should be done during times where time zones overlap. I’m not saying that West Coast colleagues have to rush to touchpoints at 6am every day, but the really critical meetings and pair development should be scheduled at times when most people on the team can attend.

2. Take this limiting factor into account in your recruiting and organizational efforts. While this is likely out of your control, you can try to communicate Conway’s Law to your managers.

3. accept it. If your organization is distributed, then perhaps your systems should be distributed too. Avoid system architectures that are not in harmony with the organizational structure.

3 Demonstration Laws

Also known as Murphy’s Law during presentations, it states that no matter how well you rehearse, no matter how many times you rehearse, you will always make mistakes while presenting! I won’t elaborate on why this happens here – see sources [9-11] for that.

If this happens to world class engineer Elon Musk, it will happen to you too (https://ift.tt/b9oUxhV)

How to use

Accept the fact that demos often don’t go well, and take precautions:

1. Minimal presentations – Minimal presentations as long as the idea/application/functionality can be conveyed.

2. The actual demo process will take longer than you might expect.

3. Arrive at least 20 minutes early, open the online meeting, and have your PPT ready. There’s nothing more disgusting than a roomful of engineers arguing over how to open an online meeting.

4. Prepare a backup demo. Imagine you’re about to present a new website, and 5 minutes before the presentation, AWS goes down. Can you run several pages on your local machine? Is there a low-profile environment deployed in a different region, etc… Be prepared for the worst.

5. Little Yellow Duck Debugging: Since demos never quite go as planned, you can actually use this to your advantage. If something doesn’t work properly, like your IDE has a problem, you can’t reproduce a bug, and so on. Well, you can use the law of presentation and try to show it to a friend. Often, when talking about the problem, you find a solution, or the problem magically disappears.

4 Gresham’s Law

Gresham’s Law comes from 19th century economics and states:

“Bad money drives out good money” [6], or more colloquially, “bad money drives out good money”.

The application of Gresham’s Law to software engineering is well described by Ben Hosking in [7], which I boil down simply to:

Cheap software is actually very expensive [8].

You want all three, but really should focus on quality (Godd) (https://ift.tt/jIQsice)

How to use

In an ideal world, every project would be fast, cheap, and well done. However, in reality, we can only pursue 2 of 3, choose wisely. In some cases, we had to rush work, but according to Gresham’s Law, “cheap” is a lie. That’s technical debt. You should always aim to get things done.

5 Planning Fallacy

In Daniel Kahneman’s book Thinking, Fast and Slow [13], the estimation fallacy refers to the fact that humans exhibit considerable optimistic bias in planning ahead, resulting in an underestimation of the time required to complete a task. You may encounter this situation frequently. For example, have you had a recent errand that took half a day instead of an hour? In fact, with any task estimate, the general recommendation is to double or even triple the initial estimate before you have a rough idea of ​​how long it will actually take to complete.

A wonderful depiction of the planning fallacy (https://ift.tt/DX2nuWe)

Here are a few practical examples of the planning fallacy [14]:

• The Sydney Opera House was originally planned to be completed in 1963. But the truth is that a scaled-down version of it didn’t open until 1973, a decade later. The original cost was estimated at $7 million, but the cost increased to $102 million because of delays.

• The “Great Tunnel” project under Boston’s Central Avenue was completed seven years later than planned, with a budget of $2.8 billion (1988) and an actual cost of $8.08 billion.

• California’s high-speed rail is still under construction and is expected to overrun by tens of billions of dollars, and connections to major cities have been delayed until the rural sections are complete.

How to use

1. Be skeptical of anything deemed “should be quick/easy”.

2. Always be careful to respond with probing questions whenever a deadline is given. For example, “If the QA team hit a bug in the first round, how would the timeline change?” Fundamental questions like these can help us uncover pitfalls and blind spots that are obvious in hindsight.

3. When in doubt, double the estimate. When making an estimate at the request of others, at least double the original estimate. Sometimes, I’ll press triple, and then double down under the persuasion of the other party.

6 Hiram’s Law

This law was only recently proposed and can be traced back to the blog of a Googler [12]. The law states:

When an API has enough users,

It doesn’t matter what you promise in the contract:

All visible behavior in the system

Someone will depend on…‍

XKCD comics are the best example:

https://xkcd.com/1172/

How to use

Similar to Murphy’s Law, you have to be aware that people will use the system in ways you don’t expect. Therefore, its scope must be minimized. Build an API that lets users do the same thing in two similar ways? Will this confuse users? Try to make the interface clear, opinionated, and easy to use so that kindergarteners can use it.

Recently, while designing an API, I encountered a situation described by Hiram’s Law. For simplicity, let’s say it fetches a list of users: fetchUsers() -> {Allan Apple, Bill Banana, Chris Carrot …} Notice that the users are ordered? The sorting process is implicit because it is done in the database and there is no ordering guarantee in the API contract. However, given Hiram’s Law, I realize that eventually someone will depend on this order. So I built it with this as a default parameter fetchUsers(sort=True) of the API contract.

7 Pareto’s Law

The Pareto Law, also known as the Law of Diminishing Returns, or the 80/20 Principle, has a wide range of applications. For example, according to 1989 estimates, the richest 20% of the world’s citizens own 80% of the world’s wealth (how strange). Or, 20% of workplace hazards are responsible for 80% of injuries. In software, this manifests in several ways, and I’ll quote Wikipedia directly because it says it well:

In computer science, the Pareto principle can be applied to optimization work. For example, Microsoft states that fixing 20% ​​of the most-reported bugs can eliminate 80% of related bugs and crashes in a given system. According to Lowell Arthur, “20% of the code contains 80% of the bugs. Find them, fix them!” It has also been found that, on average, 80% of a piece of software can be written in 20% of the total time allocated. Conversely, the hardest 20% of the code takes 80% of the time. Typically, this factor is part of the COCOMO estimation in software coding.

How to use

To take advantage of the Pareto Law, you can do the following:

• Solve the problem first. It’s important to expose the toughest engineering challenges early on. 80% of jobs may be lurking here.

• Avoid gold plating, i.e. overdesign. A great way to do this is to take on more responsibility, which will allow you to focus on the most important challenges instead of the details.

I’m not saying you should multitask, it’s often inefficient. I mean, don’t spend more than a week on any one task. Of course, not all tasks can be completed in a week, and that’s the crux of the matter. If you’re given unlimited time, you’ll find work to do, which often results in gold plating. However, if you know you’re going to hand it off to a teammate, then you have to decide what’s most important – maybe just create a REST API with CRUD methods, or just set up the build pipeline. By engaging and exiting quickly, you’ll be 80% complete across multiple projects. When your coworkers spend a whole month doing one thing 100%, you’ll get four things done 80%, and in a sense, you’re about 3 times more productive. I can tell you that when I became a senior developer, I contributed to many projects and it was more valuable than doing one thing from start to finish in my previous job; in my opinion, width > Depth.

8 Tesler’s Law

Image source: https://ift.tt/oiWaNjC

Also known as the Law of Conservation of Complexity, the idea is that every system has an inherent irreducible complexity, and if it is to be dealt with, either the system becomes more complex, or it is left to the user. Larry Tesler believes that it’s better to spend some engineering time improving the system than expecting users to do so. This makes sense – if your app has a million users, even if an engineer spends a month taking a few clicks off an action, it can save millions of clicks for a million users .

In my own life, this happens every day. When I say to Google Home, turn on the lights and change their color. I had to give it two separate commands:

Hey Google, turn the lights on to 50%…(wait 5 seconds)…Hey Google, turn the lights on to white.

Of course, supporting compound commands in AI is difficult, so users absorb this complexity.

How to use

• Avoid solutions that burden users; observe how users use the system and try to spot deficiencies.

• Always choose to spend more time on the “right way” than the “quick way”, which is Gresham’s Law.

• Think like a user – are you willing to use the functionality you’re building?

9 Buy 8 Get 1 Free – The XY Problem

It’s not a law in itself, but it feels like it should be included. When a solution (Y) is proposed without adequate consideration of the context of the actual problem (X), it leads to a better solution (Z) being overlooked and wasted effort. Consider such an example:

Boss: “Please increase the font size on this page.” (suggested solution Y)

Engineer: “Okay.”

Boss (2nd day): “Can you change it back? User says it’s too big.”

Engineer: “Okay – why did we change it in the first place?”

Boss: “One of our users is using an old version of IE and has a problem with font rendering.” (Real Question X) Engineer: “Can’t he use Chrome?” (Alternative Z)

How to use

In the above example, as long as the engineer asks a few clarifying questions, wasted effort can be avoided. The boss’s obsession with solution (Y) blinds him to a potentially better solution (Z).

In real life, XY problems often start with something that sounds suspicious. A request like “please make the font larger” is not a problem statement, but a solution statement. The real problem is “this page doesn’t display properly on older IE browsers”. Unfortunately, engineers are sometimes required to extract contextual information, as requirements and work orders are often missing. But the good news is that it’s usually not that hard – just say “let’s rewind – what is the problem we’re trying to solve” and you’ll be successful 99% of the time.

what are you thinking? Am I missing something important? Am I understanding something wrong? Comments are welcome so I can revise this post.

The text and pictures in this article are from InfoQ Architecture Headlines