Live data from Hacker News

Famous Laws of Software Development (2017)

timsommer.be

111–120 of 202 posts

Re: Famous Laws of Software Development (2017)

#111
Everyone always conveniently forgets Price's Law (derived from Lotka's Law) It states that 50% of work is done by the square root of the number of employees.

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.

This idea is particularly critical when it comes to things like layoffs. If they get scared and leave or they are let go for whatever reason, the business disproportionately suffers. Some economists believe that this brain drain has been a primary cause in the death spiral of some large companies.

Re: Famous Laws of Software Development (2017)

#112

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…

> “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.” This actually sounds very dysfunctional, but with the type of positive PR spin that product / executive management wants, basically anyone who believes “cross-functional” is anything more than a buzzword. Would love to know what…

Aside from the working overtime part, what sounds dysfunctional?

Re: Famous Laws of Software Development (2017)

#113
post #2

Don't forget Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."

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

A mutant variation of this: Greencodd's Rule: "Every sufficiently complex application/language/tool will either have to use a database or reinvent one the hard way." (from c2.com)

Re: Famous Laws of Software Development (2017)

#114
post #111

Everyone always conveniently forgets Price's Law (derived from Lotka's Law) It states that 50% of work is done by the square root of the number of employees. 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. This idea is particularly critical when it comes to things like layoffs. If they get scared and leave or they are let go…

> 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...

Re: Famous Laws of Software Development (2017)

#115
post #13

Hyrum's law is highly relevant to anyone who makes software libraries. "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." I.e. any internal implementation details that leak as behavior of the API become part of the API. Cf. Microsoft's famous "bug for bug" API compatibility through versions of Win…

They might become part of the API in a superficial sense, but if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk and won’t have a valid complaint if they want the not-covered-by-the-contractual-API preserved or become surprised by a change.

> if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk

That sounds nice in theory, but doesn't really work in practice. If you're building infra and a core piece of your company's product relies on these undocumented behaviors, you can't just change the behavior and shrug your shoulders when the whole product breaks. Similar if you're providing an external API to users/customers, you can't just break their stuff without worrying about it.

Re: Famous Laws of Software Development (2017)

#116

Earlier quoted context omitted.

Oh, it is definitely a problem from a social/cultural standpoint. But from the point of software architecture (and, therefore, development organisation), too much (or even any) communication between teams working on discreet, separate units can become detrimental. It is perfectly fine that the people communicate, and even helping each other to improve tech skill should be encouraged; however, decisions about their re…

> decisions about their respective products should be contained within each team, with clearly defined interfaces and usage documentation. In order to make those decisions and define the interfaces, you need to know a lot about how your software is going to be used. That will be much easier if you have good communication with the other teams and understand their goals and motivations.

I disagree. In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line.

The main advantage of distributed system, and particularly microservices, is the ability to have each system completely independent: individual components can be written in different languages, running on different platforms and use completely independent internal components. Basically, it is just like using an external library, component or service: the authors provide documentation and interfaces, and you should be able to expect it to behave as advertised.

Re: Famous Laws of Software Development (2017)

#117
post #2

Don't forget Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."

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

Variation 2: If you factor duplication heavily and go ultra-meta, you'll end up with Lisp or a clone of Lisp. However, only Lisps fans will be able to understand the code.

Re: Famous Laws of Software Development (2017)

#118
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.

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 thin air cheaply and at high speed. Safety is never first, and it never will be, but for obvious reasons it is a necessary part of the venture. Risk is a part too, but on the everyday level of practical compromises and small decisions—the building blocks of this ambitious enterprise—the view of risk is usually obscured. The people involved do not consciously trade safety for money or convenience, but they inevitably make a lot of bad little choices. They get away with those choices because, as Perrow says, Murphy's Law is wrong—what can go wrong usually goes right. But then one day a few of the bad little choices come together, and circumstances take an airplane down. Who, then, is really to blame?"

Of course, regardless of which way you interpret Murphy's law, the law itself and this alternative are both hyperbolic exaggerations. The main question is more of which way of looking at it is more useful.

In terms of thinking about safety, it seems like both points of view have something important to say about why paying attention to unlikely events is critical.

Re: Famous Laws of Software Development (2017)

#119
post #99

does it work for you? The site only shows a beating gray circle.

As is often the case with these kinds of abuses of JavaScript, Firefox's Reader View solves the problem.

It seems to be a strange interaction between css and javascript. Using umatrix, I can read the text with both css and javascript disabled, but not with only javascript disabled. This is the first time I encounter this curious behavior.

Re: Famous Laws of Software Development (2017)

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

> Murphy himself was unhappy abut the common interpretation of his law, which is negative rather than cautionary

Are you sure about that? Murphy's actual statement was negative and not cautionary. He was criticizing a person, not saying something cautionary about the nature of the universe.

https://en.wikipedia.org/wiki/Murphy%27s_law#Association_wit...

Post reply on HN