10 Software Engineering Laws Everybody Loves to Ignore
A Twitter 🧵
1. Conway's Law
Also known as: "You will ship your org chart."
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
You may _think_ you can avoid it via cross-functional standup meetings and stakeholder updates and decision matrices, but eventually and inevitably conflicting or diverging priorities will lead to equally conflicting or divergent processes and outcomes.
2. Brooks's Law
From The Mythical Man-Month:
"Adding manpower to a late software project makes it later."
When you realize you're not making the progress you thought you would and you're management tries to reallocate resources from another part of the org, you'll end up not only delaying the project, but you'll likely ship a more brittle, more complex product.
3. Zawinsky's Law
Adjusted for 2021:
"Every program attempts to expand until it includes a web server. Those programs which cannot so expand are replaced by ones which can."
For web services, Zawinsky's Law becomes "...until it requires a user account and collects all users' data"; for physical devices, "...until it includes an insecure wifi access point with a default password you can't change. And a web server".
4. Parkinson's Law
"Work expands so as to fill the time available for its completion."
If you don't set a deadline, then the project will never be completed. This is why iterating on a minimum viable product within fixed timelines is important.
5. Pareto's Fallacy
Pareto's Principle is easy to misinterpret, especially by management, often leading to Pareto's Fallacy:
"When you're 80% done, you think you only have 20% left."
The critical part that's overlooked here is that those 20% will require 80% of your time.
6. Sturgeon's Revelation
"90% of everything is crud."
Yes, that includes _your_ products.
7. The Peter Principle
"In a hierarchy, every employee tends to rise to their level of incompetence. Thus, in time, every post tends to be occupied by an employee who is incompetent to carry out its duties."
Dunning and Kruger send their regards...
8. Eagleson's Law
"Any code of your own that you haven't looked at for six or more months might as well have been written by someone else."
6 months is rather optimistic.
One caveat to Eagleson's Law is the "Yo Momma Corollary": only the author is allowed to criticize the code; any other negative feedback is dismissed.
This can be generalized to the Universal NIH-Rule: "any custom developed system contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of the industry standard you refused to adopt".
10. The Iceberg Fallacy
"The cost of development of a new software product is the only ~25% of the total cost of ownership management sees and budgets for."
7 battles #infosec has lost but we keep wasting efforts on trying to fight again and again nonetheless:
1) Users will always click on links in emails.
Stop trying to teach them to distinguish "bad" and "good" links. Instead, focus on ensuring their computer cannot be compromised by visiting a website and phished credentials are time-limited or otherwise useless to the attacker.
2) Users will pick bad passwords that they then reuse.
You can get _some_ users to use a password manager, but you can't enforce good passwords and practices. The only real solution is multi-factor auth, preferably via FIDO U2F and/or biometrics.
A brief Twitter r̶a̶n̶t̶ 🧵 on responsible ticket management, born out of years of frustration:
There's few things as frustrating in a large organization as diligently filing a ticket or reporting a problem only for it to sit there without anybody looking at it until it's closed by some automated job marking it as stale because it hasn't seen any updates in a year.
If you have a product that warrants a ticket queue, then you owe it to your users to manage it just as you owe it to your team to manage their workload.
Proper ticket management helps you set expectations, drive metrics, gain insights, and allow others to rely on you.
Encrypting even only first hop DNS traffic: cool.
Authenticating at least the resolver: cool.
Forcing ISPs to rethink how they use DNS data: very cool.
But still, there's a number of things that bother me about DoH:
(1) DoH only focuses on communications between client and resolver. This only solves a small part of the larger problem and offers no meaningful way to protect the communications between e.g., resolver and authoritatives.
(2) It only focuses on web applications (primarily browsers). No protections are offered to other apps. This divides the host configuration and the client threat model, adds complexity, and reinforces a "the web is the entire internet now" mindset.