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.
Famous Laws of Software Development (2017)
141–150 of 202 posts
Re: Famous Laws of Software Development (2017)
#142Earlier 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.
Re: Famous Laws of Software Development (2017)
#143Earlier 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…
Re: Famous Laws of Software Development (2017)
#144Earlier 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 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)
#145Earlier 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…
"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)
#146Earlier 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,…
Re: Famous Laws of Software Development (2017)
#147Regarding 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…
Re: Famous Laws of Software Development (2017)
#148Regarding 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…
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)
#149Re: Famous Laws of Software Development (2017)
#150Moore’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…