Earlier quoted context omitted.
Twice is a (reasonable) minimum.
To be honest from my experience usually it’s a factor of five to get to full completion.
Sounds like you're just rounding up from 99.999%.
Famous Laws of Software Development (2017)
81–90 of 202 posts
Re: Famous Laws of Software Development (2017)
#821. All software can be simplified.
2. All software has bugs.
Therefore, all software can ultimately be simplified down to a single line that doesn't work.
Re: Famous Laws of Software Development (2017)
#83Don't forget Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
Or it will be compiled to it.
Re: Famous Laws of Software Development (2017)
#84Earlier quoted context omitted.
Well, from a systems standpoint, it means a given "problem" is isolated to a single service, and is therefore not impacting the other services or interrupting the work of the other teams. But culturally, it would be nice if people helped each other out from time to time...
That's only true if any given problem is isolated on a single service, because while you are making intra-service problems much cheaper and faster to fix, you are also making inter-service problems almost impossible to fix.
Good point. I've seen situations where nobody would take ownership of a bug and fix it - you just had teams pointing fingers at each other...
Re: Famous Laws of Software Development (2017)
#85Quick and dirty is rarely quick and always dirty. (Don't know if it has a name)
First time hearing this one. I really like it.
Re: Famous Laws of Software Development (2017)
#86I would say Postel's Law, "Be conservative in what you send, be liberal in what you accept," should be tempered a bit. Sometimes it makes sense to be a bit more liberal with what you send (to make sure that consumers can handle errors) and more strict with what you accept (to make sure that consumers aren't relying too much on undocumented behavior). For example, if you have a service with near 100% uptime, any other…
Postel's Law is about handling standard protocols.
If you control all the clients and servers using a protocol, it does not apply to you. You're better being as strict as possible.
Re: Famous Laws of Software Development (2017)
#87does it work for you? The site only shows a beating gray circle.
It seems to be a SPA so it requires JS to load the content.
Re: Famous Laws of Software Development (2017)
#88Don't forget Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
The brainfuck community is falling behind.
Re: Famous Laws of Software Development (2017)
#89Hyrum's law is highly relevant to anyone who makes software libraries. "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." I.e. any internal implementation details that leak as behavior of the API become part of the API. Cf. Microsoft's famous "bug for bug" API compatibility through versions of Win…
They might become part of the API in a superficial sense, but if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk and won’t have a valid complaint if they want the not-covered-by-the-contractual-API preserved or become surprised by a change.
Of course, that doesn't mean they won't complain.
Re: Famous Laws of Software Development (2017)
#90DevOps Borat is a wonderful, if hardly understandable, account of related 'rules' and aphorisms. Sadly, it is no longer updated: https://twitter.com/devops_borat?lang=en
Some choice tweets:
Cloud is not ready for enterprise if is not integrate with single server running Active Directory.
Fact of useless: 90% of data is not exist 2 year ago. Fact of use: 90% of data is useless.
In devops we have best minds of generation are deal with flaky VPN client.
For increase revenue we are introduce paywall between dev team and ops team.