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

191–200 of 202 posts

Re: Famous Laws of Software Development (2017)

#191

Post by BerislavLopac »

AnimalMuppet wrote: post #183
BerislavLopac wrote: post #178

Earlier quoted context omitted.

Well I meant it quite literally: if it is not clear which component has the bug, the components are not separate enough. You also say: > in the real world components are never sufficiently separate But the separation of components is not an issue of "real world", it is a function of design and implementation. It is absolutely to the developers how independently the components will be implemented; if there is no way t…

Yes, but then you find web pages that attempt to determine which kind of browser requested the page, and changes what is sent back in order to work around the broken-ness of specific browsers. Yes, it's supposed to be a nice clean interface specified by standards. But in the real world, as they say, all abstractions leak. "All" may be an overstatement, but the problem is real. We never separate things cleanly enough.

This statement is true, depending on how you define "enough".

Re: Famous Laws of Software Development (2017)

#193

Post by xpil »

dllthomas wrote: post #132
xpil wrote: post #79

Earlier quoted context omitted.

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?

Sorry, forgot to set the Sarcasm New Roman font again!

Re: Famous Laws of Software Development (2017)

#194

Post by jrochkind1 »

BerislavLopac wrote: post #190
jrochkind1 wrote: post #189

Earlier quoted context omitted.

The idea that "functional requirements" can be decided independently from "technical architecture", as opposed to in interplay with each other, is exactly the opposite of what I've learned from good experiences with "agility", although some people seem to somehow take it that the opposite. But yes, you can never just do what "the users" ask for. The best way to understand what they need is to be in conversation with…

> The idea that "functional requirements" can be decided independently from "technical architecture" Oh it absolutely can; it's just that it usually is not a good idea. But I'm not talking about the process of reaching that decision, I'm talking about the responsibility to reach them. Functional and technical decisions are separate, but in most cases should be defined in conjunction. > Silo'ing everyone up isn't goin…

> But I'm not talking about the process of reaching that decision, I'm talking about the responsibility to reach them

Of course you're talking about the process. Your claims that "direct communication between teams is not the right method for that," and "communication between teams working on discreet, separate units can become detrimental," for instance, are about process.

I don't think this conversation is going anywhere, but from my experience, lack of communication between teams working on discrete, separate units (that are expected to be composed to provide business value), can become detrimental. And that's about process.

Re: Famous Laws of Software Development (2017)

#195

Post by hajile »

firethief wrote: post #166
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…

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

It actually looks more like an exponential curve with 50% of the area under the curve fitting in the last few devs. If we normalized the "flat" side of the curve to be a 1x dev, the we probably have 80 1x devs, 5 2-3x devs, 5 4-6x devs and 10 8-9x devs.

Rather than quadratic scaling, we're dealing with scaling by root. This actually meshes very well with the "mythical man month"

If we almost double from 100 devs to 196 devs, we only go from 10 to 14 devs doing half the work.

We've already accepted that 10 devs were doing half the work of 100 devs. We've also accepted that those devs must be giving it their all. So, doubling the devs, but only getting 4 new people to fill the doubled top 50%. Either we have some new 20x devs or the actual amount of work hasn't increased at the same rate.

I would still say that is probably incorrect though. The "mythic man month" doesn't apply to total work done -- only to total useful work done. As the social complexities increase, the ratio of other work decreases, but the those top developers will still have to carry both increases (to at least some degree) in order to still be doing half the work.

I suspect that as the social overhead increases, you should see three interesting cases. Those who can deal with the social overhead more quickly, so they have more real work time to compensate for being slower at it (potentially bumping a 5x dev with better social strategies higher). You could see the opposite where a 10x dev simply loses all their time in meetings. You could also see where a 1x dev with better social strategies handles most of a 10x devs social workload so that dev can instead focus on coding (it's rare, but I've worked on teams with 1-2 devs who did little except keep the team productive by fending off the bureaucracy).

Re: Famous Laws of Software Development (2017)

#196

Post by davidkuhta »

aitchnyu wrote: post #192
davidkuhta wrote: post #52

I feel like Fonzie's Law would be a worthwhile inclusion: "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."

I refuse to fall for that bait.

Remember that all is opinion. For what was said by the Cynic Monimus is manifest: and manifest too is the use of what was said, if a man receives what may be got out of it as far as it is true.

Re: Famous Laws of Software Development (2017)

#197

Post by sporkland »

I would add Greenspun's tenth rule (law)[1]:

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

And Beneford's law of controversy [2], which I see around monorepo vs polyrepo, language choices, tabs vs spaces, etc:

Passion is inversely proportional to the amount of real information available.

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule [2] https://en.wikipedia.org/wiki/Gregory_Benford

Re: Famous Laws of Software Development (2017)

#198

Post by dllthomas »

xpil wrote: post #193
dllthomas wrote: post #132

Earlier quoted context omitted.

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

Sorry, forgot to set the Sarcasm New Roman font again!

Honestly, it's more amusing for the ambiguity :)

Re: Famous Laws of Software Development (2017)

#199

Post by Izkata »

Wildgoose wrote: post #155
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.

Native English speaker, from England, and we were explicitly taught to use Brooks' rather than Brooks's. However that didn't stop the Beatles from using "In an Octopus's Garden" as a song title. (Note that the song is about a single Octopus). I would suggest that it depends on whether you intend to explicitly repeat the 's' when speaking. Plurals of words ending with an 's' are an occasional minefield. You sometimes…

In the US - I've always understood it to have something to do with pluralization, along the lines of:

* One river's fish.

* Jesus's fish.

* Many rivers exist.

* Many rivers' fish.

The name "Brooks" unfortunately fits both the second and fourth of these examples, making it even weirder.

Re: Famous Laws of Software Development (2017)

#200

Post by AnimalMuppet »

BerislavLopac wrote: post #191
AnimalMuppet wrote: post #183

Earlier quoted context omitted.

Yes, but then you find web pages that attempt to determine which kind of browser requested the page, and changes what is sent back in order to work around the broken-ness of specific browsers. Yes, it's supposed to be a nice clean interface specified by standards. But in the real world, as they say, all abstractions leak. "All" may be an overstatement, but the problem is real. We never separate things cleanly enough.

This statement is true, depending on how you define "enough".

Sure. Look, despite the impression I may have given, I'm not arguing for separating things badly. The cleaner the separation, the better. It really makes a difference.
Post reply on HN