Live data from Hacker News

‘Laws’ of Software Development

exceptionnotfound.net

61–70 of 74 posts

Re: ‘Laws’ of Software Development

#61
post #23

The Gervais Principle is worth reading about: http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o... Related to the Peter & Dilbert Principles, but darker and told through the lens of the Office.

It took me two days to read it, so I'll provide a summary:

In a corporate hierarchy are the losers (bottom), clueless (middle), and sociopaths (top).

Losers: Economic losers in that they prefer a fixed monthly paycheck over their fair share for their contribution. Risk-averse. They know they made a bad deal and don't do more than expected. They play social validation games with each other to feel better in order to stand their fate.

Clueless: They believe in the corporate story and work more than they're payed for. They're promoted into middle management where they serve as a buffer between the top management (sociopaths) and the workers (losers). They execute all ideas from top management, from the stupid over the risky to the good. If something succeeds, the sociopaths take the credit. If something fails, the clueless take the blame.

Sociopaths: Nihilists who emotionally broke under the realization that no true values exist in this universe, so they're free to make values and goals up as they like. Those stories are given to the clueless to believe in. In every corporate life cycle exist different sociopaths. In the beginning they're the risk-takers with a vision and the willpower to push something new through. In established companies they kill off new and threatening ideas to protect the successful products. During decline they milk the company for the remaining values, then leave the sinking ship and hand responsibility over to the clueless to let them take the blame.

One important part are the different languages of the three classes. Losers have "game language", the social games they play to validate each other, but the talk and the content are unrelated to reality and don't advance them in the hierarchy. The clueless try to speak like the sociopaths but don't realize that one has to have stakes in the game (i.e. something to lose or something valuable to offer) in order to be taken seriously, so their language is full of empty phrases and threats. The sociopaths' "power talk" is full of hints (without commitments) that are only understood by equals and when they talk about something they have to lose or gain something -- it's about the real things, not the empty phrases the clueless use.

Re: ‘Laws’ of Software Development

#62

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…

Security is a forethought, not an afterthought.

Performance is a constraint, not a goal.

Re: ‘Laws’ of Software Development

#63

The 15 laws succinctly: Do what is simplest, and remember, everyone is attacking you with stupidity. Most of your simple work will be done quickly, a small amount will be done in the time remaining. You will think you are better at doing all this than you are. To wit, seek the help of others to talk you down-- accept things from others. You'll need it because eventually you become a stranger even to yourself. And fro…

Love this. Though isn't this more about over estimating our skills?

Seems to make more sense given "we think we are better at doing this than we are".

Re: ‘Laws’ of Software Development

#64

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…

There are many other laws, e.g.: Zawinski's Law of Software Development: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. Atwood's Law: Any application that can be written in JavaScript, will eventually be written in JavaScript. But there is perhaps no greater legal scholar than Norman Augustine: Law XVI: Software is like entropy. It is dif…

Law XVI's exception is XFS, which has had a steadily declining LOC count for years.

http://sandeen.net/wordpress/wp-content/uploads/2012/04/fs-l...

Re: ‘Laws’ of Software Development

#65
post #3

Don't forget Wiio's laws ("Communication usually fails, except by accident"). See https://www.cs.tut.fi/~jkorpela/wiio.html

Though I had adopted the maxim s contained within as worthy of remembrance, I had searched in vain to find this page again after my first encounter with it several years ago; thank you for restoring it to my bookmarks list.

Re: ‘Laws’ of Software Development

#66

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

Notice that this can be interpreted in two ways. The hacker's interpretation is that, if you want to improve your smarts then you have to code as cleverly as possible, otherwise you cannot learn anything when debugging! This is called kernighan's lever: http://www.linusakesson.net/programming/kernighans-lever/

Re: ‘Laws’ of Software Development

#67
A funny and ironic law:

Good software will grow smaller and faster as time goes by and the code is improved and features that proved to be less useful are weeded out. [from the programming notebooks of a heretic]

If I were to quote the above to a layman--someone well outside the world of software development--the response would be, "Well of course that's what would happen, it's obvious."

Re: ‘Laws’ of Software Development

#68

Earlier quoted context omitted.

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

Notice that this can be interpreted in two ways. The hacker's interpretation is that, if you want to improve your smarts then you have to code as cleverly as possible, otherwise you cannot learn anything when debugging! This is called kernighan's lever: http://www.linusakesson.net/programming/kernighans-lever/

This is perfect! I've never heard of that interpretation before. Thanks for sharing!

Re: ‘Laws’ of Software Development

#70
post #42
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…

Being liberal in what you accept is fine, iff strictly define the variations in the grammar. Meredith and Sergey's outstanding talk about properly parsing all input discusses this update to how Postel's Law should be interpreted. https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit

Thanks! The link is missing a trailing `y`.
Post reply on HN