Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Famous Laws of Software Development (2017)

timsommer.be

Post reply on HN
Print view View original

31–40 of 202 posts

Re: Famous Laws of Software Development (2017)

#31

Post by smt88 »

lolive wrote: post #18
rubinelli wrote: post #10

Earlier quoted context omitted.

A personal rule of thumb I derived from the ninety-ninety rule is this: "Before starting a project, ask yourself if you would still do it if you knew it would cost twice as much and take twice as long as you expect. Because it probably will."

Twice is a (reasonable) minimum.

I've found that under-promising and over-delivering requires me to quadruple my best estimate.

Unfortunately, lots of us bid against people who over-promise. By the time the project is obviously behind schedule, it's too late, and the client can't switch to someone else.

Re: Famous Laws of Software Development (2017)

#32

Post by art0rz »

dahart wrote: post #26

Moore’s law is dead! Also, I think Murphy’s law should be removed, it’s less true than the other laws here. I read a fantastic article many years ago in the Atlantic where the author was analyzing and deconstructing an airplane crash, and in it was a paragraph about how Murphy’s law is completely backwards, and in reality if things can go right, then they will. Things will almost always go right unless there’s no pos…

As I interpret Murphy's Law, it's not so much about failure in actuality, but more about anticipating the failure, and designing your code/product/system for the worst case scenario.

Re: Famous Laws of Software Development (2017)

#34

Post by sorahn »

There is an entire poster of funny 'laws of computing' that was created in 1980 by Kenneth Grooms. It's pretty amazing how many of these are completely relevant 40 years later...

It's hard to find the original piece of art, but my uncle had this hanging in his office for a long time, and now it's hanging in mine.

I transcribed it in a gist so I had access to them for copy/paste.

https://gist.github.com/sorahn/905f67acf00d6f2aa69e74a39de65...

(Those pictures were from an ebay auction before I got the actual piece)

Re: Famous Laws of Software Development (2017)

#35

Post by Deganta »

lolive wrote: post #18
rubinelli wrote: post #10

Earlier quoted context omitted.

A personal rule of thumb I derived from the ninety-ninety rule is this: "Before starting a project, ask yourself if you would still do it if you knew it would cost twice as much and take twice as long as you expect. Because it probably will."

Twice is a (reasonable) minimum.

I see the 90% rule as a recursive function: First we get 90% of the whole work in the first iteration, then 90% of the remaining code (now we are 99% complete), then 99.9% and so on.

The iteration is stopped when the software has enough features and an acceptable level of bugs to be considered complete. What complete is depends entirely on the field of the software. For a proof of concept software we can stop after the first iteration, but for a safety critical software we might need 3, 4, or even more itarions.

Re: Famous Laws of Software Development (2017)

#36

Post by 0_gravitas »

dahart wrote: post #26

Moore’s law is dead! Also, I think Murphy’s law should be removed, it’s less true than the other laws here. I read a fantastic article many years ago in the Atlantic where the author was analyzing and deconstructing an airplane crash, and in it was a paragraph about how Murphy’s law is completely backwards, and in reality if things can go right, then they will. Things will almost always go right unless there’s no pos…

I think people interpret Murphy's law incorrectly most of the time.

We can extrapolate from "Anything bad that can, happen will happen", and get the statement: "If something can physically happen, given enough time, it will eventually happen."

I like to think its sort of a very tangential sister idea of the mediocrity theory.

Re: Famous Laws of Software Development (2017)

#38

Post by redcodenl »

Regarding Conway's Law:

We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure.

- Inverse Conway Law or just Roy's Law ;-)

Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams.

But after we switched to microservices the teams became responsible for just a part of the system, their microservice(s). Whenever we had an outage, one team was left to fix it, the others just went home. They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices.

Re: Famous Laws of Software Development (2017)

#39

Post by joeblau »

kgwgk wrote: post #25

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. (Originally with "sed" instead of "regular expressions")

    Some programmers, when confronted with a problem, think 
    "I know, I'll solve it with threads!"
    have Now problems. two they

Re: Famous Laws of Software Development (2017)

#40

Post by xpil »

dgacmu wrote: post #22

Page author, if you read this: Fred Brooks last name has an s. (Brooks, not Brook.) It should be Brooks' law.

Wouldn't it be "Brooks's" rather than "Brooks'"?

From what I know, the "*s'" thing works mostly for plural nouns. For singular, it only applies to classical & religious names ending with "s" ("Jesus'", "Archimedes'" etc).

I am not an English native so I may be completely off. Feel free to rage :)

Post reply on HN