Laws of Software Engineering

A guide to the patterns that shape software systems, teams, and decisions, by @milan_milanovic.

[Dr Milan Milanović @milan_milanovic]

My book sold 1,258 copies in the first two months in 74 countries

I expected to be the story, but it turned out the map was

It reached 74 countries, with the US leading by a wide margin, then Germany, the UK, and the Netherlands. After that, the map scatters into places I have no tie to.

I sold one copy in Senegal, one in Cambodia, and one in Armenia. About a third of those copies are print (and 50%+ hardcover).

I'm grateful and a bit stunned by where it ended up.

If you have a copy, tell me where you're reading it from. I want to see how far it actually went.

Along with this, the Serbian version has already sold more than 350 copies in subscription (to be published at the end of the month).

[Laws of Software Engineering @SoftwareEngLaws]

More on Amdahl's Law, with diagrams and related laws:
https://t.co/3oH1dcLVTm

[Laws of Software Engineering @SoftwareEngLaws]

A law from 1967 explains why AI hasn't made you 10x faster.

Amdahl's Law: speedup from parallelization is capped by the fraction of work that can't be parallelized. 🧵👇

[Laws of Software Engineering @SoftwareEngLaws]

9/
Two engineers, same tools: one sees huge gains, one shrugs. The difference isn't the model. It's the size of s.

Shrink the part that runs alone before you scale the part that doesn't.

[Dr Milan Milanović @milan_milanovic]

I met many leaders who haven't read a book in years

They said they don't have time. But here is the problem with that.

They don't read, but they decide to add five people to a late project and make it later. Brooks wrote about it 50 years ago. Also, they decide to reorg the team and are surprised when software architecture is wrong afterwards. Conway saw this in 1968.

Here we cannot see anything new. Most of the mistakes we see in today's teams are already done many times. Some people learned about it and wrote it down. We just don't read it.

That bothered me a lot, so I spent more than two years writing "Laws of Software Engineering". Inside you can find 63+ laws and principles that explain why software teams and systems behave the way they do (and they will for many years to come). All of the laws include real-life use cases.

If you're interested to learn more, check my book 👇

[Laws of Software Engineering @SoftwareEngLaws]

More on Kernighan's Law, with diagrams and related laws:
https://t.co/JtkMnDkoP4

[Laws of Software Engineering @SoftwareEngLaws]

The cleverest code you ever wrote is the one you're least qualified to debug.

That's Kernighan's Law, and it's half a century old. 🧵👇

[Laws of Software Engineering @SoftwareEngLaws]

8/
Cleverness is an asset at write time.

And a liability at debug time.