Hacker laws you love, and some you need to know

Commentary: Sure, you've heard of Brooks' Law, but what about Hofstadter's? Check out this list of hacker laws.

Professional programmer working at developing programming and website working in a software develop company office, writing codes and typing data code

Image: Getty Images/iStockphoto

Most in the software world will have heard of Brooks' Law. You know, the idea that throwing bodies at an already late project will simply make it later. This "law" was first articulated in Fred Brooks' excellent book The Mythical Man-Month, and has wormed its way into countless software conversations since then. 

You may also be familiar with Conway's Law, which simply suggests that software will tend to be structured like the teams that build it. But if you're like me, there are a number of software development "laws" that are far less known, but probably should be more common in our discussions. Fortunately, Dave Kerr compiled a list of "Hacker Laws" and created a GitHub repository so you can submit pull requests to round out the list. 

Here are a few of the Hacker Laws that were new and interesting to me with the caveat that these all involve generalizations and so can't be taken too literally. 

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

It's pointy-haired bosses all the way down

While I've heard people articulate the Peter principle ("rise to the level of your incompetence"), I've never heard Putt's Law:

Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.

Anyone who has followed Dilbert will discern the "Pointy-haired Boss" in this quote, and most developers will have had some experience with a manager who seems out-of-his-depth on the complex engineering he manages. Putt's Law is often followed by Putt's Corollary:

Every technical hierarchy, in time, develops a competence inversion.

Fortunately, this means that the technically competent will keep writing code while the less technically competent will move "up" to writing rules. 

Keeping things simple

The next will warm the hearts of any developers who believe removing lines of code is as important (and often much more so) than writing code. It's called Kernighan's Law and comes from a book Brian Kernighan wrote with P. J. Plauger, The Elements of Programming Style.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Moral of this story? Keep code as simple as possible. It's a nice complement to Occam's Razor ("the simplest solution is likely the right one"). 

The never-ending story

Kerr rightly blends two other Hacker Laws that I find amusing: Parkinson's Law and Hofstadter's Law. They go together nicely because both have to do with our inability to forecast delivery dates with much precision. 

Parkinson's Law:

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

Hofstadter's Law:

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

As Kerr interprets Parkinson's Law, "the theory [is] that teams will be inefficient until deadlines near, then rush to complete work by the deadline, thus making the actual deadline somewhat arbitrary." When merged with Hofstadter's Law, it reads, "work will expand to fill the time available for its completion and still take longer than expected."

And on that cheery note, take a look at the different Hacker Laws that Kerr has collected to see if one of your favorites is missing. Go ahead. You have plenty of time. That project isn't due for weeks!

Disclosure: I work for AWS, but nothing herein relates directly or indirectly to my work there.

Also see