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

121–130 of 202 posts

Re: Famous Laws of Software Development (2017)

#121

Post by badfrog »

BerislavLopac wrote: post #116
badfrog wrote: post #108

Earlier quoted context omitted.

> 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 lan…

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

If you just implement all requests directly, you're for sure going to end up with a horrible interface. You should approach API design the same way that UX/PM approaches UI and feature design: take the time to understand _why_ your partner teams/engineers are requesting certain changes and figure out the right interface to address their problems.

Re: Famous Laws of Software Development (2017)

#122

Post by hajile »

firethief wrote: post #114
hajile wrote: 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...

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 an extreme degree.

I have never found a 100 person company where 60% or more of the company was contributing absolutely nothing. I have never seen a company where a large number of people were actively harming the company and the company survived.

Re: Famous Laws of Software Development (2017)

#123

Post by BerislavLopac »

badfrog wrote: post #121
BerislavLopac wrote: post #116

Earlier quoted context omitted.

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 lan…

> 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. If you just implement all requests directly, you're for sure going to end up with a horrible interface. You should approach API design the same way that UX/PM approaches UI and feature design: tak…

Oh absolutely, but direct communication between teams is not the right method for that. Which is why every product, no matter how "micro" a service, needs to have a dedicated product owner/manager who is responsible for defining functional requirements.

Edit: I just noticed that "PM" in parent comment. Basically, product managers are not just for UI and customer-facing products.

Re: Famous Laws of Software Development (2017)

#124

Post by Benjammer »

hajile wrote: post #122
firethief wrote: post #114

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.

Sorta buried the lede there, eh?

Re: Famous Laws of Software Development (2017)

#125

Post by scriptkiddy »

badfrog wrote: post #115
mlthoughts2018 wrote: post #60

Earlier quoted context omitted.

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 provi…

Isn't this the exact reason people came up with semantic versioning?

Re: Famous Laws of Software Development (2017)

#126

Post by 0_gravitas »

dahart wrote: post #118
0_gravitas wrote: post #36

Earlier quoted context omitted.

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 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 probabilities and aliens and simulation stuff.

Re: Famous Laws of Software Development (2017)

#127

Post by maxxxxx »

eximius wrote: post #81
maxxxxx wrote: post #41

Earlier quoted context omitted.

To be honest from my experience usually it’s a factor of five to get to full completion.

Sounds like you're just rounding up from 99.999%.

True! I came up with the factor five by observation but it’s in line with the predictions

Re: Famous Laws of Software Development (2017)

#128

Post by kickopotomus »

mojuba wrote: post #100

Oh please, not the Knuth's "principle" again. Optimization is a skill, it's not evil. A skilled engineer can build sufficiently good systems without wasting much extra time on optimizations.

I think the issue is that people often conflate optimization with simplification. You can, and should, try to simplify the problem space early on in the project life cycle but don't waste your time on things like comparing runtime performance of string pattern matching algorithms.

Re: Famous Laws of Software Development (2017)

#129

Post by hajile »

Benjammer wrote: post #124
hajile wrote: post #122

Earlier quoted context omitted.

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

#130

Post by scriptkiddy »

billfruit wrote: post #11

This is a list of rather, generic catch phrases. I think the article isn't worth the time, surprised to find it at the top of HN.

I disagree. The article itself may not have much meat to it, but the discussion it has sparked is definitely worth the time to read.

There is a lot of back and forth in the comments about software design and workflow practices. I think this kind of discourse is extremely valuable.

Post reply on HN