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

131–140 of 202 posts

Re: Famous Laws of Software Development (2017)

#131

Post by cm2187 »

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…

I'd add, if the API is meant to implement a protocol but doesn't implement it quite correctly, you may object to the misimplementation, but if your code has to work with the implementation, you have to adapt to their bug. It's not even a matter of undocumented behavior.

Experienced recently as a consumer of an API when letsencrypt made a breaking change to implement the protocol correctly. Broke my code which relied on their original incorrect implementation.

Re: Famous Laws of Software Development (2017)

#132

Post by dllthomas »

xpil wrote: post #79
yathern wrote: post #71

Earlier quoted context omitted.

There's not exactly a consensus these days on what is correct. Either is valid, but I generally prefer _Brooks' Law_ to _Brooks's Law_ since it looks more clean. Of course, Brook's Law is incorrect, as there is no "Brook" Here's an example of the lack of consensus: Either is acceptable: https://data.grammarbook.com/blog/apostrophes/apostrophes-wi... https://owl.purdue.edu/owl/general_writing/punctuation/apost... Chic…

So, the usual clusterf*k of opinions instead of a clear spec. People should be speaking SQL. Thanks for the links. Plenty of educational value there!

> So, the usual clusterf*k of opinions instead of a clear spec. People should be speaking SQL.

Because that would be an improvement, or not much of a change?

Re: Famous Laws of Software Development (2017)

#133

Post by dllthomas »

sorahn wrote: post #34

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/905f67a…

> program complexity grows until it exceeds the capability of the programmer to maintain it.

... then it grows even faster.

Re: Famous Laws of Software Development (2017)

#134

Post by squirrelicus »

mlthoughts2018 wrote: post #60
wffurr wrote: 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.

The struggle here is that it's not always clear what behavior, buggy or not, is intended behavior. Especially as the complexity of an API endpoint or method increases, for example with large input models or mutable system state at the time of request.

Re: Famous Laws of Software Development (2017)

#135

Post by squirrelicus »

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…

It's extraordinarily difficult to quantify this. Anecdotally i believe I've worked with people who were net losses for the company, devs whose contributions would be better if they did nothing. And yet those same people often shine in specific areas, like "angular knowledge" or something like that.

Re: Famous Laws of Software Development (2017)

#136

Post by squirrelicus »

Deganta wrote: post #35
lolive wrote: post #18

Earlier quoted context omitted.

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

I like this, it rings true in my experience.

Re: Famous Laws of Software Development (2017)

#137

Post by neilk »

BerislavLopac wrote: post #5
jatsign wrote: 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.

I encountered a literal version of this the other day.

I’ve been looking at some disused AI systems, which were all written in Lisp back in the day.

In an attempt to remain relevant, at one point in the early 2000s someone tried porting one of them to Java. By first writing a Lisp interpreter in early 2000s Java. So the system had all the old dynamic Lisp programs as giant strings, embedded in a fugly static class hierarchy.

Re: Famous Laws of Software Development (2017)

#138

Post by AnimalMuppet »

BerislavLopac wrote: post #53
redcodenl wrote: post #38

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…

> 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. Honestly, this sounds like an improvement.

This depends very much on the team size. Having a team of 20 people communicate in the way you describe below is insane overkill. Having a team of 100 do so may save everyones' sanity.

Re: Famous Laws of Software Development (2017)

#139

Post by mr_tristan »

lojack wrote: post #105
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.

His full quote is a little less prone to abuse > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we…

Yeah, I get frustrated that few people actually post the full quote, because, with the context, it means something completely different to young ears.

The full quote makes me think: "You should identify the critical paths of your system early." The shortened quote makes me think: "Deal with performance later."

Pretty big difference in meaning.

Post reply on HN