Live data from Hacker News

Famous Laws of Software Development (2017)

timsommer.be

161–170 of 202 posts

Re: Famous Laws of Software Development (2017)

#161
post #39

Earlier quoted context omitted.

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

I like.

> There are only two problems in computer science, naming things, cache invalidation and off by one errors.

I've got to say modern languages with foreach() have been amazing (makes me feel old when I consider a 20 year old widely used language 'modern').

Re: Famous Laws of Software Development (2017)

#162
Kind of unrelated to the article, but does the Moore's law joke about the cat constant make any sense? The `-C` constant should be on both sides of the equation (since the formula is future computation _relative to_ current computation), and thus cancel out. As it stands, the equation doesn't make sense when 'Number of years' is zero, and is inconsistent between calculating twice in 2-year intervals and calculating once with a 4-year interval (as an example).

Re: Famous Laws of Software Development (2017)

#163
post #122

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…

[deleted]

Re: Famous Laws of Software Development (2017)

#164

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…

This outcome could be considered a feature of microservices: by abstracting the functionality into more tightly-contained units, failures are more isolated. Sounds like the organization needs to do other things to keep people from getting siloed, though that gets increasingly difficult at scale. Well-defined SLAs (along with monitoring and reporting of those SLAs) are also necessary so that microservice failures can…

This YC talk from Amazon's CTO on how they grew to a microservice model and team structure was really interesting: https://www.youtube.com/watch?v=adtuntQ8rh4

Re: Famous Laws of Software Development (2017)

#166
post #122

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…

My understanding of your model must be inaccurate somehow. Here's what I think I'm hearing:

- the distribution of productivity of devs in an organization of N * N devs can be approximated as: N devs who are "Nx", and the rest of the devs are "1x" (Price's Law, assuming a binary distribution for simplicity)

- the value of "x" is constant for all sizes of organization (if it were relative "some are 0.1x" would be a change of units, not an abandonment of reality)

This would yield the extremely surprising result that the total dev production of an organization scales quadratically with the number of devs, so what am I misunderstanding?

Re: Famous Laws of Software Development (2017)

#169
post #15

Earlier quoted context omitted.

The modern angle on this rule is that "Every program eventually adds text chat, and they're all incompatible with each other."

Isn't mail just another form of text chat?

Somebody took your idea quite literally: https://www.coi-dev.org/

(HN discussion: https://news.ycombinator.com/item?id=19216077 )

Re: Famous Laws of Software Development (2017)

#170

Earlier quoted context omitted.

Which is a clear sign that your components are not sufficiently separate.

Um, no. The real world is not that simple. It would be nice if it were. Or perhaps your statement is correct, but in the real world components are never sufficiently separate. So, while your statement may be correct by definition, it is not useful.

You are misreading my words.
Post reply on HN