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

61–70 of 202 posts

Re: Famous Laws of Software Development (2017)

#61

Post by xpil »

pier25 wrote: post #46
xpil wrote: post #40

Earlier quoted context omitted.

Wouldn't it be "Brooks's" rather than "Brooks'"? From what I know, the "*s'" thing works mostly for plural nouns. For singular, it only applies to classical & religious names ending with "s" ("Jesus'", "Archimedes'" etc). I am not an English native so I may be completely off. Feel free to rage :)

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.

Re: Famous Laws of Software Development (2017)

#62

Post by klodolph »

I would say Postel's Law, "Be conservative in what you send, be liberal in what you accept," should be tempered a bit. Sometimes it makes sense to be a bit more liberal with what you send (to make sure that consumers can handle errors) and more strict with what you accept (to make sure that consumers aren't relying too much on undocumented behavior).

For example, if you have a service with near 100% uptime, any other service which relies on it may not be able to handle errors or unavailability. Introducing errors in a controlled way can help make the dependencies more reliable.

As another example, being liberal about what you accept can sometimes result in security flaws, since different systems might be interpreting a message differently. Rejecting malformed input can be a beautiful thing.

Re: Famous Laws of Software Development (2017)

#63

Post by BerislavLopac »

joeblau wrote: post #39
kgwgk wrote: post #25

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. (Originally with "sed" instead of "regular expressions")

Some programmers, when confronted with a problem, think "I know, I'll solve it with threads!" have Now problems. two they

There are only two hard problems in distributed systems:

    2. Exactly-once delivery
    1. Guaranteed order of messages
    2. Exactly-once delivery
Source: https://twitter.com/mathiasverraes/status/632260618599403520

Re: Famous Laws of Software Development (2017)

#64

Post by jcadam »

badfrog wrote: post #54
BerislavLopac wrote: post #53

Earlier quoted context omitted.

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

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

Re: Famous Laws of Software Development (2017)

#67

Post by vibrato »

badfrog wrote: post #54
BerislavLopac wrote: post #53

Earlier quoted context omitted.

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

How is people not talking to each other an improvement?

Dunbar's number. As humans, we only have room for so many relationships.

Re: Famous Laws of Software Development (2017)

#68

Post by andrelaszlo »

xpil wrote: post #40
dgacmu wrote: post #22

Page author, if you read this: Fred Brooks last name has an s. (Brooks, not Brook.) It should be Brooks' law.

Wouldn't it be "Brooks's" rather than "Brooks'"? From what I know, the "*s'" thing works mostly for plural nouns. For singular, it only applies to classical & religious names ending with "s" ("Jesus'", "Archimedes'" etc). I am not an English native so I may be completely off. Feel free to rage :)

See https://english.stackexchange.com/questions/62257/strunk-and...

Both are acceptable, apparently.

Re: Famous Laws of Software Development (2017)

#69

Post by Sahhaese »

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 of poor quality near the top at times).

Re: Famous Laws of Software Development (2017)

#70

Post by Dangeranger »

Wouldn't the following be an embrace of Conway's Law rather than a defense against it?

> It is much better, and more and more implemented as such, to deploy teams around a bounded context. Architectures such as microservices structure their teams around service boundaries rather than siloed technical architecture partitions.

> So, structure teams to look like your target architecture, and it will be easier to achieve it. That's how you defend against Conways's law.

Post reply on HN