101–110 of 202 posts
Could someone explain the last one, Norvig's Law: "Any technology that surpasses 50% penetration will never double again (in any number of months)."
http://www.norvig.com/norvigs-law.html
But most certainly that is not how the law was meant to be interpreted.
Hyrum'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.
I can testify to this personally, having worked at a payments processor and accidentally broken integrations. The business, as it should have, had little tolerance for me changing a depended upon API, even though it was not documented
I 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.
More concrete example: suppose that an incoming HTTP request contains CRLFLF. To the proxy, “liberal in what you accept” might mean that this is interpreted as CRLF CRLF, which is the end of the request header. To the authoritative server, perhaps the second LF is silently discarded and ignored. Voilà: instant cache poisoning attack.
Regarding Conway's Law: We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure. - Inverse Conway Law or just Roy's Law ;-) Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams. But after we switched to microservices…
Oh please, not the Knuth's "principle" again. Optimization is a skill, it's not evil. A skilled engineer can build sufficiently good systems without wasting much extra time on optimizations.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Premature optimization isn't bad, premature micro optimization is bad. You should also be thinking about optimization that results in better architecture and architectural decisions that make it easier to optimize in the future.
Earlier quoted context omitted.
How is people not talking to each other an improvement?
Presumably if you don't like other people then it's an improvement. At a guess I'd say that covers about quarter of our industry.
Organizations that are too isolated will tend to create monoliths. Organizations that are too connected and too flat will tend to create sprawling spaghetti systems. These two cases are not mutually exclusive. You can have sprawling spaghetti monoliths. This is also one of the dangers to having one team work on several microservices; those microservices will tend to intermingle in inappropriately complex ways. Boundaries are critical to system health, and boundaries can be tuned by organizing people. Don't worry about Conway's law, leverage it.
Earlier quoted context omitted.
How is people not talking to each other an improvement?
Oh, it is definitely a problem from a social/cultural standpoint. But from the point of software architecture (and, therefore, development organisation), too much (or even any) communication between teams working on discreet, separate units can become detrimental. It is perfectly fine that the people communicate, and even helping each other to improve tech skill should be encouraged; however, decisions about their re…
In order to make those decisions and define the interfaces, you need to know a lot about how your software is going to be used. That will be much easier if you have good communication with the other teams and understand their goals and motivations.
Quick and dirty is rarely quick and always dirty. (Don't know if it has a name)
A related rule: Design software for maintenance, not initial roll-out, because maintenance is where most of the cost will likely be.
An exception may be a start-up where being first to market is of utmost importance.
Other rules:
Don't repeat yourself: factor out redundancy. However, redundancy is usually better than the wrong abstraction, which often happens because the future is harder to predict than most realize.
And Yagni: You Ain't Gonna Need It: Don't add features you don't yet need. However, make the design with an eye on likely needs. For example, if there's an 80% probability of a need for Feature X, make your code "friendly" to X if it's not much change versus no preparation. Maybe there's a more succinct way to say this.