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

71–80 of 202 posts

Re: Famous Laws of Software Development (2017)

#71

Post by yathern »

xpil wrote: post #61
pier25 wrote: post #46

Earlier quoted context omitted.

Brooks' ?

This is exactly what I am trying to establish to improve my bumpy English. My best guess is that the correct form is "Brooks's" because (1) "Brooks" is a singular noun ending with an "s" and (2) it is not a classic neither religious name. If you claim it should be "Brooks'" I am ok with this as long as you give me a sensible explanation.

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

Chicago vs AP style: https://apvschicago.com/2011/06/apostrophe-s-vs-apostrophe-f...

APA style suggests appending the extra 's': https://blog.apastyle.org/apastyle/2013/06/forming-possessiv...

Re: Famous Laws of Software Development (2017)

#72

Post by Bizarro »

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…

That reminds me of a place I used to work at, where initially we had DBAs embedded in the teams. They switched that and the DBAs were all grouped together and all hell broke loose. They were always have meetings, throwing out emails about they were dictating this and that, and had very little direct communications with the teams they were supposed to be supporting.

I ended up leaving during the peak of all of this, but in an exit-interview, a director asked me about the problems this was causing.

Re: Famous Laws of Software Development (2017)

#73

Post by throwaway2016a »

Murphy's Law has electrical engineering roots. I have a fun anecdote.[0] My wife is electromechanical and I'm computer science so we would work on projects together since we make a good team. I remember in college I was working with my wife on one of her projects and we were using force transducers. The damn things kept breaking at the worst times so we kept calling it Murphy's Law. After a while we looked it up. Turns out Murphy was working with transducers when he coined the phrase [1]. So I have this little back pocket anecdote about the time I got to use Murphy's Law in the original context. Which I can bring out in times just like this.

[0] I think it is fun. Your milage may vary.

[1] https://en.wikipedia.org/wiki/Murphy%27s_law

Re: Famous Laws of Software Development (2017)

#74

Post by billfruit »

Sahhaese wrote: post #69
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.

Yes, this doesn't strike me as good quality content at all. But it's a large list which lets everyone pick something and chip in which drives engagement. If this sort of content is the sort that this community increasingly selects for then it is perhaps time to look for fresh pastures. ( I don't however know if this indicative of HN's current community or just an 'accident' - I'm sure there have always been examples…

I think not just this one, a few of the top ones are of similar vein at the moment. Seems a bit off-colour, as usually the quality of content was rather consistent.

Re: Famous Laws of Software Development (2017)

#75

Post by ddebernardy »

I'm not sure who they should be named after, but I'd like to suggest two more:

> Redundancy is bad, but dependencies are worse.

https://yosefk.com/blog/redundancy-vs-dependencies-which-is-...

> Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

https://stackoverflow.com/questions/876089/who-wrote-this-pr...

Re: Famous Laws of Software Development (2017)

#79

Post by xpil »

yathern wrote: post #71
xpil wrote: post #61

Earlier quoted context omitted.

This is exactly what I am trying to establish to improve my bumpy English. My best guess is that the correct form is "Brooks's" because (1) "Brooks" is a singular noun ending with an "s" and (2) it is not a classic neither religious name. If you claim it should be "Brooks'" I am ok with this as long as you give me a sensible explanation.

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!

Re: Famous Laws of Software Development (2017)

#80

Post by marcosdumay »

jcadam wrote: post #64
badfrog wrote: post #54

Earlier quoted context omitted.

How is people not talking to each other an improvement?

Well, from a systems standpoint, it means a given "problem" is isolated to a single service, and is therefore not impacting the other services or interrupting the work of the other teams. But culturally, it would be nice if people helped each other out from time to time...

That's only true if any given problem is isolated on a single service, because while you are making intra-service problems much cheaper and faster to fix, you are also making inter-service problems almost impossible to fix.
Post reply on HN