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

181–190 of 202 posts

Re: Famous Laws of Software Development (2017)

#181

Post by jacques_chester »

gumby wrote: post #151

I have always liked Postel's law (and Jon -- what a great human being he was) but I no longer like it as I used to. The reason it's a really great idea is that it says you should engineer in favor of resilience, which is an important form of robustness. And at the same time, "strict in what you send" means "don't cause trouble for others. However there are cases where "fail early" is more likely to be the right thing…

"The Harmful Consequences of the Robustness Principle" is a good read: https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...

Re: Famous Laws of Software Development (2017)

#182

Post by yesenadam »

MattyRad wrote: post #37

The Peter Principle is also referred to as Putt's Law ( https://en.m.wikipedia.org/wiki/Putt%27s_Law_and_the_Success... ) and phrased slightly differently.

Putt's Law seems totally different.

* Putt's Law: "Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand."

* Putt's Corollary: "Every technical hierarchy, in time, develops a competence inversion." with incompetence being "flushed out of the lower levels" of a technocratic hierarchy, ensuring that technically competent people remain directly in charge of the actual technology while those without technical competence move into management.

In the Peter model, everyone gets (or tends to get) promoted until they reach a job they can't do, and they stay there. Thus everyone will (tend to) be incompetent. In Putt's model, the technically incompetent get promoted, and those at lower levels are competent.

Putt's does sound more like the way the world works...maybe. Peter's has always sounding convincing to me, yet the world evidently isn't so bad as that.

Re: Famous Laws of Software Development (2017)

#183

Post by AnimalMuppet »

BerislavLopac wrote: post #178
AnimalMuppet wrote: post #171

Earlier quoted context omitted.

Perhaps so. Would you care to explain? Your statement here doesn't give me much to go on.

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.

Re: Famous Laws of Software Development (2017)

#184

Post by yesenadam »

sagartewari01 wrote: post #91
dreta wrote: post #4

I know this is harsh, but if you're a web developer, and your blog requires a loading screen to read, at least on mobile, then maybe you should take a step back, and learn to program, before you start writing about programming.

No you're not being harsh. That site loads 1.3 mb of js, even though it doesn't have any dynamic content at all. The small header images for related articles you see along the right side are loaded as full hd images (probably the fault of wordpress theme). Looks like the author has a real good internet connection and just hacked together a site over a lunch. Web devs should really limit there internet connection to 1…

>Web devs should really limit there internet connection to 100k while testing their sites.

Now that is a great idea.

Re: Famous Laws of Software Development (2017)

#186

Post by mikekchar »

rubinelli wrote: post #10
BerislavLopac wrote: post #3

There is an error in the ninety-ninety rule, which should be stated as: The first 90% of the code takes the first 90% of the time. The remaining 10% takes the other 90% of the time.

A personal rule of thumb I derived from the ninety-ninety rule is this: "Before starting a project, ask yourself if you would still do it if you knew it would cost twice as much and take twice as long as you expect. Because it probably will."

I totally agree. I tend to phrase it a bit differently: "If you need to know how long it will take before deciding if it is important enough, then it is likely not important enough."

Another kind of corollary: "If the business will go under if we don't get this done by X, then we probably need a new business plan, not faster development".

These are rules of thumb and there are definite places where they don't hold, but I've found it genuinely useful to consider when the inevitable tough questions start to get asked.

Re: Famous Laws of Software Development (2017)

#187

Post by mannykannot »

gumby wrote: post #151

I have always liked Postel's law (and Jon -- what a great human being he was) but I no longer like it as I used to. The reason it's a really great idea is that it says you should engineer in favor of resilience, which is an important form of robustness. And at the same time, "strict in what you send" means "don't cause trouble for others. However there are cases where "fail early" is more likely to be the right thing…

Being liberal in what you accept has turned out to be a security problem. This is especially so when this maxim is observed in a widely-deployed piece of software, as its permissiveness tends to become the de-facto standard.

Re: Famous Laws of Software Development (2017)

#188

Post by mamon »

Interesting read, although at this point the "Given enough eyeballs, all bugs are shallow" should be regardes as afallacy, not a law, because:

- noone reads open source code

- those who read do not understand it

- those who understand don't file bug reports.

- those who file bug reports file them for their own issues coming from misunderstanding/misapplication of the software, not actual bugs.

Re: Famous Laws of Software Development (2017)

#189

Post by jrochkind1 »

BerislavLopac wrote: post #123
badfrog wrote: post #121

Earlier quoted context omitted.

> In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line. If you just implement all requests directly, you're for sure going to end up with a horrible interface. You should approach API design the same way that UX/PM approaches UI and feature design: tak…

Oh absolutely, but direct communication between teams is not the right method for that. Which is why every product, no matter how "micro" a service, needs to have a dedicated product owner/manager who is responsible for defining functional requirements. Edit: I just noticed that "PM" in parent comment. Basically, product managers are not just for UI and customer-facing products.

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 them. Silo'ing everyone up isn't going to make the overall product -- which has to be composed of all these sub-components working well with each other -- any better.

Re: Famous Laws of Software Development (2017)

#190

Post by BerislavLopac »

jrochkind1 wrote: post #189
BerislavLopac wrote: post #123

Earlier quoted context omitted.

Oh absolutely, but direct communication between teams is not the right method for that. Which is why every product, no matter how "micro" a service, needs to have a dedicated product owner/manager who is responsible for defining functional requirements. Edit: I just noticed that "PM" in parent comment. Basically, product managers are not just for UI and customer-facing products.

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 going to make the overall product

This is true for certain types of product, and less so for others; you need to clearly understand what type of product you're building, and be ready to adapt as it changes (or you have a better understanding of it). In a nutshell, the more compartmentalised a product is, the isolation between the teams becomes more beneficial. Which brings us full circle back to Conway's Law.

Post reply on HN