
‘Laws’ of Software Development - btimil
http://www.exceptionnotfound.net/fundamental-laws-of-software-development/
======
nostrademons
Missing some big ones:

Gall's Law: "A complex system that works is invariably found to have evolved
from a simple system that worked. A complex system designed from scratch never
works and cannot be patched up to make it work. You have to start over with a
working simple system."

[https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...](https://en.wikipedia.org/wiki/John_Gall_\(author\)#Gall.27s_law)

Conway's Law: "organizations which design systems ... are constrained to
produce designs which are copies of the communication structures of these
organizations"

[https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

Cunningam's Law: "the best way to get the right answer on the Internet is not
to ask a question, it's to post the wrong answer"

[https://meta.wikimedia.org/wiki/Cunningham%27s_Law](https://meta.wikimedia.org/wiki/Cunningham%27s_Law)

~~~
auntienomen
Also, Kernighan's Law: "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."

~~~
enriquto
Notice that this can be interpreted in two ways. The hacker's interpretation
is that, if you want to improve your smarts then you have to code as cleverly
as possible, otherwise you cannot learn anything when debugging! This is
called kernighan's lever: [http://www.linusakesson.net/programming/kernighans-
lever/](http://www.linusakesson.net/programming/kernighans-lever/)

~~~
TeMPOraL
This is perfect! I've never heard of that interpretation before. Thanks for
sharing!

------
gorpomon
The 15 laws succinctly:

Do what is simplest, and remember, everyone is attacking you with stupidity.
Most of your simple work will be done quickly, a small amount will be done in
the time remaining. You will think you are better at doing all this than you
are. To wit, seek the help of others to talk you down-- accept things from
others. You'll need it because eventually you become a stranger even to
yourself. And from there you'll rise to the level of stupidity you detested
not too long ago. Or maybe some unwise fool will intercede on your behalf,
dragging you up to their level of idiocy. This will all take longer than you
think, because all along the way you underestimated your skills, but don't
worry there'll be plenty of work to fill the time. Most of it will be petty,
and you'll fight over the least essential things, but that's because you chose
to work in a field full of smart people who continually underestimate their
abilities.

~~~
burtmacklin
Love this. Though isn't this more about _over_ estimating our skills?

Seems to make more sense given "we think we are better at doing this than we
are".

------
VMG
Careful with Postel's Law: it brought us a lot the mess we have with web
standards.

Quoting wikipedia
[https://en.wikipedia.org/wiki/Robustness_principle](https://en.wikipedia.org/wiki/Robustness_principle):

> In RFC 3117, Marshall Rose characterized several deployment problems when
> applying Postel's principle in the design of a new application protocol.[3]
> For example, a defective implementation that sends non-conforming messages
> might be used only with implementations that tolerate those deviations from
> the specification until, possibly several years later, it is connected with
> a less tolerant application that rejects its messages. In such a situation,
> identifying the problem is often difficult, and deploying a solution can be
> costly. Rose therefore recommended "explicit consistency checks in a
> protocol ... even if they impose implementation overhead".

~~~
pdkl95
Being liberal in what you accept is fine, iff strictly define the variations
in the grammar.

Meredith and Sergey's outstanding talk about properly parsing all input
discusses this update to how Postel's Law should be interpreted.

[https://media.ccc.de/v/28c3-4763-en-
the_science_of_insecurit](https://media.ccc.de/v/28c3-4763-en-
the_science_of_insecurit)

~~~
quanticle
I would argue that if you're strictly defining the accepted variations in the
grammar, then all you've done is define a new grammar that you're
conservatively adhering to. And that's fine! There's no rule that says that
standards cannot evolve to match new use cases. However, I would argue that
having a strictly defined (yet evolving) standard is much different than the
common interpretation of Postel's Law, which is that undefined behavior should
"do the right thing", with the specific interpretation of "the right thing"
being left to the implementers. Predictably, different implementers interpret
that in different ways, which leads to security holes. But if the
specification defines what the right thing to do is, then the behavior is no
longer undefined, and therefore Postel's Law no longer applies.

------
mparr4
The Gervais Principle is worth reading about:

[http://www.ribbonfarm.com/2009/10/07/the-gervais-
principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-
the-office-according-to-the-office/)

Related to the Peter & Dilbert Principles, but darker and told through the
lens of the Office.

~~~
jk4930
It took me two days to read it, so I'll provide a summary:

In a corporate hierarchy are the losers (bottom), clueless (middle), and
sociopaths (top).

Losers: Economic losers in that they prefer a fixed monthly paycheck over
their fair share for their contribution. Risk-averse. They know they made a
bad deal and don't do more than expected. They play social validation games
with each other to feel better in order to stand their fate.

Clueless: They believe in the corporate story and work more than they're payed
for. They're promoted into middle management where they serve as a buffer
between the top management (sociopaths) and the workers (losers). They execute
all ideas from top management, from the stupid over the risky to the good. If
something succeeds, the sociopaths take the credit. If something fails, the
clueless take the blame.

Sociopaths: Nihilists who emotionally broke under the realization that no true
values exist in this universe, so they're free to make values and goals up as
they like. Those stories are given to the clueless to believe in. In every
corporate life cycle exist different sociopaths. In the beginning they're the
risk-takers with a vision and the willpower to push something new through. In
established companies they kill off new and threatening ideas to protect the
successful products. During decline they milk the company for the remaining
values, then leave the sinking ship and hand responsibility over to the
clueless to let them take the blame.

One important part are the different languages of the three classes. Losers
have "game language", the social games they play to validate each other, but
the talk and the content are unrelated to reality and don't advance them in
the hierarchy. The clueless try to speak like the sociopaths but don't realize
that one has to have stakes in the game (i.e. something to lose or something
valuable to offer) in order to be taken seriously, so their language is full
of empty phrases and threats. The sociopaths' "power talk" is full of hints
(without commitments) that are only understood by equals and when they talk
about something they have to lose or gain something -- it's about the real
things, not the empty phrases the clueless use.

------
jazzyk
One of my favorite quotes -ever-:

Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction.

E. F. Schumacher

~~~
kps
_It seems that perfection is attained, not when there is nothing more to add,
but when there is nothing more to take away._ — Antoine de Saint Exupéry

------
junke
Don't forget Wiio's laws ("Communication usually fails, except by accident").
See
[https://www.cs.tut.fi/~jkorpela/wiio.html](https://www.cs.tut.fi/~jkorpela/wiio.html)

~~~
jpt4
Though I had adopted the maxim s contained within as worthy of remembrance, I
had searched in vain to find this page again after my first encounter with it
several years ago; thank you for restoring it to my bookmarks list.

------
kodis
I'd be tempted to add Brooks' law, that adding staff to a project that's
already late just serves to make it even later.

~~~
fh973
My favorite one from him is: "How does a project get one year late? One day at
a time." as it captures the priority decisions that you make consciously or
unconsciously all the time.

------
saltvedt
Brooks' Law: "Adding manpower to a late software project makes it later."

[https://en.wikipedia.org/wiki/Brooks%E2%80%99_law](https://en.wikipedia.org/wiki/Brooks%E2%80%99_law)

------
edtechdev
Over on the education side of things, we have a lot of problems with
Campbell's law. Once people focus on a quantitative indicator to evaluate
things of any importance, it essentially gets corrupted. Like test scores,
university rankings... On the software side of things, there might be things
ranging from website hits, ad clicks, page rank, karma points, etc. More on
the development side there might be things like commits, github stats, etc.

[https://en.wikipedia.org/wiki/Campbell%27s_law](https://en.wikipedia.org/wiki/Campbell%27s_law)

------
composer
ReRe's Law of _Re_ petition and _Re_ dundancy

A programmer can accurately estimate the schedule only for the repeated and
the redundant. Yet,

A programmer's job is to automate the repeated and the redundant. Thus,

A programmer delivering to an estimated or predictable schedule is...

Not doing their job (or is redundant).

------
cdevs
"You can never learn from the 14 laws without experience but with experience
you will know what you should have learned from them." -webdude

------
TeMPOraL
Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden, slow implementation of
half of Common Lisp."

[https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule](https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)

------
edejong
Dijkstra's Law: "Simplicity is a great virtue but it requires hard work to
achieve it and education to appreciate it. And to make matters worse:
complexity sells better."

------
sitkack

        90% of this list is crap -- https://en.wikipedia.org/wiki/Theodore_Sturgeon

~~~
jakegarelick
Here's a direct link:
[https://en.wikipedia.org/wiki/Sturgeon%27s_law](https://en.wikipedia.org/wiki/Sturgeon%27s_law)

------
steveoc64
The DateField hypothesis :

For any given reasonable estimate for an item of software, add 2^N days to
that estimate, where N = the number of date/datetime fields involved on that
form or database table.

eg - You have a complex data entry screen to add to a webpage, and you KNOW
for certain that you can complete it thoroughly in 2-3 days tops, testing
every possible edge case. Good stuff.

However, if that screen has 2 date fields involved, then its going to take 2^2
or 4 extra days over and above the reasonable estimate to get it done
properly, and handle NULL dates, timezone differences, comparison of dates for
equality, parsing date inputs, converting internal representations between
front end / backend / storage ... and every other unexpected abomination.

------
maxerickson
I think a better conclusion to draw from Dunning-Kruger is that self
assessment can be problematic.

~~~
gshulegaard
I would agree with this. It's broader and still applicable.

~~~
sitkack
Dunning-Kruger actually said everyone is bad at self evaluation, not just the
low skilled.

~~~
achamayou
And that neatly applies to his law of argumentative comprehension, which
should really read "The more people _think they_ understand something, the
more willing they are to argue about it, and the more vigorously they will do
so."

------
MattyRad
Similar to Dibert Principle:
[https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)

------
vox_mollis
The Hanlon's Razor portion vastly underestimates the sheer amount of contempt
and vitriol that many people in business harbor for their technology staff.

Sometimes (oftentimes, in my experience) they really do hate you.

------
atemerev
Occam's razor has more priority than Hanlon's razor.

Sometimes assuming just a tiny bit of malice can account for layers and layers
of presumed stupidity.

------
lukasm
Atwood: "Any application that can be written in JavaScript will eventually be
written in JavaScript"

Zawinski: "Every program attempts to expand until it can read mail. Those
programs which cannot so expand are replaced by ones which can." s/mial/API
etc

And I can't find this one (IBM study?) "Adding 10% of features increases cost
by 100%"

~~~
munificent
> Adding 10% of features increases cost by 100%

Too bad the inverse isn't true. Would be nice if we could cut costs by 100%
just by ditching a tenth of the features.

~~~
rhizome
The inverse gets you bumping up against Pareto, though, so...pretty close.

------
zwieback
Valid not just for software development but any kind of engineering effort.

------
alister
A funny and ironic law:

 _Good software will grow smaller and faster as time goes by and the code is
improved and features that proved to be less useful are weeded out. [from the
programming notebooks of a heretic]_

If I were to quote the above to a layman--someone well outside the world of
software development--the response would be, "Well of course that's what would
happen, it's obvious."

------
analog31
For every of stakeholder involve in your project is completion of project
delay by 6 month.

[https://twitter.com/DEVOPS_BORAT/status/305515482465837056?l...](https://twitter.com/DEVOPS_BORAT/status/305515482465837056?lang=en)

------
agentultra
Linus' Law loses water when you consider using formal specifications, model
checking, and -- if you have the budget and time -- _proof_. These systems and
languages have come a long way and are far better than any human at checking
your work and telling you where you are making mistakes.

Model checking in particular, in my limited experience using it, is effective
at this.

You can eliminate many (not all... nothing's perfect) of these rules of thumb
with a little math and analysis[0].

[0] [https://www.amazon.ca/Programming-1990s-Introduction-
Calcula...](https://www.amazon.ca/Programming-1990s-Introduction-Calculation-
Programs/dp/0387973826?ie=UTF8&SubscriptionId=AKIAILSHYYTFIVPWUY6Q&camp=2025&creative=165953&creativeASIN=0387973826&linkCode=xm2&tag=duckduckgo-
ffab-20)

~~~
KineticLensman
The guy bf

------
dmh2000
the more complex a software system is, the more the people not involved in its
creation will criticize the colors and placement of buttons on the UI.

~~~
dizzy3gg
bikeshedding

------
amelius
I'd like to see a list of analogies, so I can explain better to my
boss/clients/friends why constructing software is hard.

~~~
rqebmm
My favorite reason is: By definition nobody builds software that's ever
existed before.

~~~
a3n
CRUD

~~~
recursive
I've worked on CRUD apps for my whole career, and I've never seen one that
didn't have some novel requirements.

~~~
mjevans
Even when you're using some base that already exists (often a highly
configurable thing that's been sold to you by someone else), you STILL have
the frequent stories of nightmares involving either an inability to configure
it to the desired specification or cost and time overruns of epic proportions.

------
bryanmikaelian
What about Conway's Law?

------
perseusprime11
oh no! Not another set of laws. I can't remember so many.

------
riazrizvi
~~laws~~ rules of thumb

~~~
Retra
A "law", in the scientific sense, is really just a detailed observation.

~~~
steveoc64
Good point.

Note also that some "laws" may remain as "laws", even in the face of
experimental evidence which directly contradicts the predicted results of that
law.

Which gives rise to "The Law of Research Funding", in which the amount of
funding that can be attracted to support a given law is proportional to the
amount of real world experimental evidence which contradicts that law. :)

