Live data from Hacker News

Famous Laws of Software Development (2017)

timsommer.be

141–150 of 202 posts

Re: Famous Laws of Software Development (2017)

#141
post #84

Earlier quoted context omitted.

Good point. I've seen situations where nobody would take ownership of a bug and fix it - you just had teams pointing fingers at each other...

This is precisely a symptom of unclear ownership responsibilities.

No, it can be an issue of it being unclear in which component the bug actually is.

Re: Famous Laws of Software Development (2017)

#142
post #129

Earlier quoted context omitted.

>I have never seen a company where a large number of people were actively harming the company and the company survived . Sorta buried the lede there, eh?

The law seems to hold for successful companies and companies that violate the law seem to disappear. If someone has found the Russell's Teapot of companies that strays so far into absurdity while still being true, then let them bring forth the proof.

My first real job was as a contractor working with middle management at Bristol-Myers-Squibb. What I saw there was easily that absurd, and that company still exists.

Re: Famous Laws of Software Development (2017)

#143
post #32

Earlier quoted context omitted.

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.

> it's not so much about failure in actuality Murphy himself was unhappy abut the common interpretation of his law, which is negative rather than cautionary, implying a vindictiveness to exist in inanimate objects and the laws of chance. > but more about anticipating the failure, and designing your code/product/system for the worst case scenario Which was his intent. IIRC the phrase was coined while working on rocket…

Exactly. You can't say "That won't happen" or "that's unlikely to happen". You have to have a way that handles it so that, even if it does happen, the guy on the sled doesn't die.

Re: Famous Laws of Software Development (2017)

#144
post #118

Earlier quoted context omitted.

I'm not sure I understand what you think is incorrect; your explanation seems to align with the common interpretation. Here's the article I was thinking of. Totally worth the read, aside from discussion of Murphy's Law... https://www.theatlantic.com/magazine/archive/1998/03/the-les... "Keep in mind that it is also competitive, and that if one of its purposes is to make money, the other is to move the public through t…

I suppose what I generally mean is that most of the people that I've talked to only consider it within the scope of "what can go wrong ", and seem to never consider the more general statement. I'm certainly not claiming to be the first person to think such a way, if that's the impression I gave off. Murphy's law is a favorite of mine because it's the perfect driving board for conversations about infinite probabilitie…

I guess I still don't know exactly what the more general statement is you're referring to. Do you mean just that a non-zero probability of a single event happening equals 100% probability given a large enough sample of events (which may take a large amount of time)?

I feel like Murphy's law as stated captures that idea adequately. And it's certainly true if the event probability really is non-zero. Sometimes, though, we can calculate event probabilities that are apparently non-zero based on known information, but are zero in reality.

One example in my head is quantum tunneling. Maybe this is along the lines you're talking about? And this is the way my physics TA described it many years ago, but caveat I'm not a physicist and I suspect there are some problems with this analogy. He said you can calculate the probability of an atom spontaneously appearing on the other side of a solid wall, and you can calculate the same (less likely) probability of two atoms going together, therefore there is a non-zero probability that a human can teleport whole through the wall. The odds are too small to expect to ever see it, but on the other hand, with the amount of matter in the universe we should expect to see small scale examples somewhat often, and we don't. There may be unknown reasons that the probability of an event is zero.

Re: Famous Laws of Software Development (2017)

#145
post #122

Earlier quoted context omitted.

> Interestingly, Price's law seems to indicate 10x developers exist because if you have 100 employees, then 10 of them do half of all the work. Or 0.1x developers exist...

You have to completely abandon reality to get rid of the idea. If 60 of the remaining 90 devs did NOTHING, those 10 devs would still be 2.5x better than the rest. To take things further, make a bell curve chart. Put 50% of the area under the top 10%. Now, divide up the rest however you'd like. The only way to make this happen is for a huge percent to not only contribute zero, but to be actively hurting development to…

> I have never seen a company where a large number of people were actively harming the company and the company survived.

"To survive" is a temporal measure. It's pretty common for companies to survive on a successful product (or group of products). The rest of the company was a shell and revenue sink for that line.

Re: Famous Laws of Software Development (2017)

#146
post #144

Earlier quoted context omitted.

I suppose what I generally mean is that most of the people that I've talked to only consider it within the scope of "what can go wrong ", and seem to never consider the more general statement. I'm certainly not claiming to be the first person to think such a way, if that's the impression I gave off. Murphy's law is a favorite of mine because it's the perfect driving board for conversations about infinite probabilitie…

I guess I still don't know exactly what the more general statement is you're referring to. Do you mean just that a non-zero probability of a single event happening equals 100% probability given a large enough sample of events (which may take a large amount of time)? I feel like Murphy's law as stated captures that idea adequately. And it's certainly true if the event probability really is non-zero. Sometimes, though,…

It looks like we agree on all points, yes

Re: Famous Laws of Software Development (2017)

#147

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…

Haha, this is so similar to what happened where I work in SF that I feel you’re a coworker of mine.

Re: Famous Laws of Software Development (2017)

#148

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…

This outcome could be considered a feature of microservices: by abstracting the functionality into more tightly-contained units, failures are more isolated.

Sounds like the organization needs to do other things to keep people from getting siloed, though that gets increasingly difficult at scale. Well-defined SLAs (along with monitoring and reporting of those SLAs) are also necessary so that microservice failures can be understood in the right context.

Re: Famous Laws of Software Development (2017)

#149
I like Wiggin's Law (found in [My Heroku Values](https://gist.github.com/adamwiggins/5687294)): If it's hard, cut scope. I'm working on a compiler for my new language and sometimes I get caught up in the sheer amount of work involved in implementing a new language. I mean, I have to write a typechecker, a code generator, a runtime (including GC), a stdlib, etc. But instead of just getting overwhelmed, I'm trying to cut scope and just focus on getting a small part working. Even if the code is terrible, even if it's limited in functionality, I just need to get something working.

Re: Famous Laws of Software Development (2017)

#150
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…

It’s also in Understanding Human Error by Sidney Dekker when talking about normalization of deviance. Everything that can go right will go right and we’ll use that to justify deviance more and more.
Post reply on HN