Live data from Hacker News

‘Laws’ of Software Development

exceptionnotfound.net

21–30 of 74 posts

Re: ‘Laws’ of Software Development

#21
Over on the education side of things, we have a lot of problems with Campbell's law. Once people focus on a quantitative indicator to evaluate things of any importance, it essentially gets corrupted. Like test scores, university rankings... On the software side of things, there might be things ranging from website hits, ad clicks, page rank, karma points, etc. More on the development side there might be things like commits, github stats, etc.

https://en.wikipedia.org/wiki/Campbell%27s_law

Re: ‘Laws’ of Software Development

#22
post #20

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle : > In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…

Yeah. I agree that this is a slippery slope. SMTP followed this, and there were a lot of whacky things, then qmail came and rejected the bad implementations.

Perhaps it's better to use this law for UI, where being liberal with accepting things by trimming white space is better than rejecting, which would confuse an end user.

Re: ‘Laws’ of Software Development

#24

Missing some big ones: Gall's Law: "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la... Conway's Law: "organizations which design systems ... are constrained to pr…

Also, Kernighan's Law: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

Re: ‘Laws’ of Software Development

#25
post #20

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle : > In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…

That may be true, but it's only a problem if you believe we are capable of designing sane, useful standards initially. Postel's law allows a limited form of evolution for standards. Sometimes that allows for useful extensions to be adopted into later revisions, other times it can run rampant and create monstrous mutations (which might still be accepted. I'm looking at you, IMAP).

Re: ‘Laws’ of Software Development

#28
post #20

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle : > In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…

How I wish more engineers would take this precaution, as it is arguable the law caused harm over good, well intended as it might be.

Engineering with unspecified bounds often needlessly introduces complexity and cost.

Re: ‘Laws’ of Software Development

#29
post #20

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle : > In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…

Yeah. I agree that this is a slippery slope. SMTP followed this, and there were a lot of whacky things, then qmail came and rejected the bad implementations. Perhaps it's better to use this law for UI, where being liberal with accepting things by trimming white space is better than rejecting, which would confuse an end user.

Perhaps, but we introduce a new implicit specification by doing this, possibly closing the door for situations where white-space is relevant.

The common appearance of the ignorant user seems to stem from him generalizing patterns as a holdover from one UI to another. Perhaps we should better study these patterns and steer the user to a consistent path. But instead, it seems we're trying to out-smart him time and time again, creating a jungle of user interactions which merely belittle and confuse.

Post reply on HN