14 ms·
Famous Laws of Software Development (2017)
- jatsign 8y agoDon't forget Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
- BerislavLopac 8y agoOr Greenspun's Tenth Rule of Programming: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp.
- cheez 8y agoaka JavaScript.
- jacobush 8y agoI suppose you mean that half manifests itself as Javascript.
- tabtab 8y agoA mutant variation of this: Greencodd's Rule: "Every sufficiently complex application/language/tool will either have to use a database or reinvent one the hard way." (from c2.com)
- tabtab 8y agoVariation 2: If you factor duplication heavily and go ultra-meta, you'll end up with Lisp or a clone of Lisp. However, only Lisps fans will be able to understand the code.
- neilk 8y agoI encountered a literal version of this the other day. I’ve been looking at some disused AI systems, which were all written in Lisp back in the day. In an attempt to remain relevant, at one point in the early 2000s someone tried porting one of them to Java. By first writing a Lisp interpreter in early 2000s Java. So the system had all the old dynamic Lisp programs as giant strings, embedded in a fugly static class hierarchy.
- flambard 8y agoAnd then there is Virding's First Rule of Programming: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
- sagartewari01 8y agoOr it will be compiled to it.
- marcosdumay 8y agoThe brainfuck community is falling behind.
- BerislavLopac 8y agoThere 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.
- rubinelli 8y agoA 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."
- lolive 8y agoTwice is a (reasonable) minimum.
- smt88 8y agoI've found that under-promising and over-delivering requires me to quadruple my best estimate. Unfortunately, lots of us bid against people who over-promise. By the time the project is obviously behind schedule, it's too late, and the client can't switch to someone else.
- Deganta 8y agoI see the 90% rule as a recursive function: First we get 90% of the whole work in the first iteration, then 90% of the remaining code (now we are 99% complete), then 99.9% and so on. The iteration is stopped when the software has enough features and an acceptable level of bugs to be considered complete. What complete is depends entirely on the field of the software. For a proof of concept software we can stop after the first iteration, but for a safety critical software we might need 3, 4, or even more itarions.
- squirrelicus 8y agoI like this, it rings true in my experience.
- dreta 8y agoI 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.
- avip 8y ago100% agree. This website looks terrible. You can't be a self-declared "web developer", contemplate poetically about meta-programming, and publish this amateurish thing. Fix the #anchors to start with?
- corndoge 8y agoHush noob
- chasingthewind 8y agoThat loaded extremely slowly on mobile admittedly, but I do agree that you're being overly harsh. Why assume he authored the site himself? Is it a requirement that someone doing web programming has to author their own blog site? It feels like a form of gatekeeping to be honest.
- Cthulhu_ 8y agoOh no, the problem is they DO know how to program; a simple web page (or off the shelf CMS or blog software) is too easy. Anyway, this was made with Ghost according to the generator tag; send https://ghost.org/ https://ghost.org/ a ping that you're willing to help them improve their software.
- asimpletune 8y agoHN’s law 1: anything you didn’t build seems worse to you. HN’s law 2: you always become a parody of yourself.
- patsplat 8y agoThe loading graphic may be more to prevent a Flash of Unstyled Content (FOUC) than to mask loading times: https://en.m.wikipedia.org/wiki/Flash_of_unstyled_content https://en.m.wikipedia.org/wiki/Flash_of_unstyled_content Single page apps have quite a bit of control over rendering, however Google prefers that indexed markup be pre rendered from the server. Juggling the two competing priorities leads to byzantine technical issues. Front end development for content sites can be complex.
- gpvos 8y agoZawinski's law of software envelopment: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
- ryandrake 8y agoThe modern angle on this rule is that "Every program eventually adds text chat, and they're all incompatible with each other."
- wffurr 8y agoIsn't mail just another form of text chat?
- mcv 8y agoYes. That makes it the more general form of the original law.
- ryandrake 8y agoThe incompatibility is the key feature that differentiates modern text chat from those inferior mail applications.
- HerrMonnezza 8y agoSomebody took your idea quite literally: https://www.coi-dev.org/ https://www.coi-dev.org/ (HN discussion: https://news.ycombinator.com/item?id=19216077 https://news.ycombinator.com/item?id=19216077 )
- Balgair 8y agoAnother of jwz's laws is: Any social media company will expand until it behaves like a bank; receiving deposits and making loans to customers (not necessarily users).
- billfruit 8y agoThis is a list of rather, generic catch phrases. I think the article isn't worth the time, surprised to find it at the top of HN.
- Sahhaese 8y agoYes, this doesn't strike me as good quality content at all. But it's a large list which lets everyone pick something and chip in which drives engagement. If this sort of content is the sort that this community increasingly selects for then it is perhaps time to look for fresh pastures. ( I don't however know if this indicative of HN's current community or just an 'accident' - I'm sure there have always been examples of poor quality near the top at times).
- billfruit 8y agoI think not just this one, a few of the top ones are of similar vein at the moment. Seems a bit off-colour, as usually the quality of content was rather consistent.
- scriptkiddy 8y agoI disagree. The article itself may not have much meat to it, but the discussion it has sparked is definitely worth the time to read. There is a lot of back and forth in the comments about software design and workflow practices. I think this kind of discourse is extremely valuable.
- squirrelicus 8y agoThey might be catch phrase, but that doesn't make them inaccurate.
- wffurr 8y agoHyrum'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 Windows. Http://www.hyrumslaw.com
- mlthoughts2018 8y agoThey 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.
- KSteffensen 8y agoOf course, that doesn't mean they won't complain.
- wbronitsky 8y agoWhile you might not view their complaint as valid, what if the change you made cuts off service to the customer? And what if the service you provide is in the critical path for the customer, such as hosting, payments, or even power? 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
- badfrog 8y ago> if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk That sounds nice in theory, but doesn't really work in practice. If you're building infra and a core piece of your company's product relies on these undocumented behaviors, you can't just change the behavior and shrug your shoulders when the whole product breaks. Similar if you're providing an external API to users/customers, you can't just break their stuff without worrying about it.
- hokumguru 8y agoLast week I was trying to remember a term for when a programmer designs a system so generic that it becomes a prototype of itself. For the life of me, I can't remember - anyone here on HN know?
- Sahhaese 8y agoThat's the inner platform effect https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
- dgacmu 8y agoPage author, if you read this: Fred Brooks last name has an s. (Brooks, not Brook.) It should be Brooks' law.
- xpil 8y agoWouldn't it be "Brooks's" rather than "Brooks'"? From what I know, the "*s'" thing works mostly for plural nouns. For singular, it only applies to classical & religious names ending with "s" ("Jesus'", "Archimedes'" etc). I am not an English native so I may be completely off. Feel free to rage :)
- pier25 8y agoBrooks' ?
- xpil 8y agoThis is exactly what I am trying to establish to improve my bumpy English. My best guess is that the correct form is "Brooks's" because (1) "Brooks" is a singular noun ending with an "s" and (2) it is not a classic neither religious name. If you claim it should be "Brooks'" I am ok with this as long as you give me a sensible explanation.
- yathern 8y agoThere's not exactly a consensus these days on what is correct. Either is valid, but I generally prefer _Brooks' Law_ to _Brooks's Law_ since it looks more clean. Of course, Brook's Law is incorrect, as there is no "Brook" Here's an example of the lack of consensus: Either is acceptable: https://data.grammarbook.com/blog/apostrophes/apostrophes-with-names-ending-in-s-ch-or-z/ https://data.grammarbook.com/blog/apostrophes/apostrophes-wi... https://owl.purdue.edu/owl/general_writing/punctuation/apostrophe_introduction.html https://owl.purdue.edu/owl/general_writing/punctuation/apost... Chicago vs AP style: https://apvschicago.com/2011/06/apostrophe-s-vs-apostrophe-forming.html https://apvschicago.com/2011/06/apostrophe-s-vs-apostrophe-f... APA style suggests appending the extra 's': https://blog.apastyle.org/apastyle/2013/06/forming-possessives-with-singular-names.html https://blog.apastyle.org/apastyle/2013/06/forming-possessiv...
- kgwgk 8y agoSome people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. (Originally with "sed" instead of "regular expressions")
- joeblau 8y agoSome programmers, when confronted with a problem, think "I know, I'll solve it with threads!" have Now problems. two they
- BerislavLopac 8y agoThere are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery Source: https://twitter.com/mathiasverraes/status/632260618599403520 https://twitter.com/mathiasverraes/status/632260618599403520
- noir_lord 8y agoI like. > There are only two problems in computer science, naming things, cache invalidation and off by one errors. I've got to say modern languages with foreach() have been amazing (makes me feel old when I consider a 20 year old widely used language 'modern').
- dahart 8y agoMoore’s law is dead! Also, I think Murphy’s law should be removed, it’s less true than the other laws here. I read a fantastic article many years ago in the Atlantic where the author was analyzing and deconstructing an airplane crash, and in it was a paragraph about how Murphy’s law is completely backwards, and in reality if things can go right, then they will. Things will almost always go right unless there’s no possible way they can, in other words only the extremely rare alignment of multiple mistakes causes catastrophes. Can’t remember if the author had a name for the alternative Murphy’s law, but I believe it, especially in software. We get away with crappy software and bugs & mistakes all over the place.
- art0rz 8y agoAs I interpret Murphy's Law, it's not so much about failure in actuality, but more about anticipating the failure, and designing your code/product/system for the worst case scenario.
- dspillett 8y ago> it's not so much about failure in actuality Murphy himself was unhappy abut the common interpretation of his law, which is negative rather than cautionary, implying a vindictiveness to exist in inanimate objects and the laws of chance. > but more about anticipating the failure, and designing your code/product/system for the worst case scenario Which was his intent. IIRC the phrase was coined while working on rocket sleds for a land speed record attempt. He was essentially trying to achieve "no matter what happens we want to maximise the chance of the pilot being alive afterwards, if some of the equipment survives too that is even better" and promoting a defensive always-fail-as-safely-as-possible engineering stance.
- dahart 8y ago> Murphy himself was unhappy abut the common interpretation of his law, which is negative rather than cautionary Are you sure about that? Murphy's actual statement was negative and not cautionary. He was criticizing a person, not saying something cautionary about the nature of the universe. https://en.wikipedia.org/wiki/Murphy%27s_law#Association_with_Murphy https://en.wikipedia.org/wiki/Murphy%27s_law#Association_wit...
- turingbook 8y agoThere are some better lists for laws of Software Development: [1] http://www.globalnerdy.com/2007/07/18/laws-of-software-development/ http://www.globalnerdy.com/2007/07/18/laws-of-software-devel... [2] https://exceptionnotfound.net/fundamental-laws-of-software-development/ https://exceptionnotfound.net/fundamental-laws-of-software-d... (not so good but with solid discussions from HN https://news.ycombinator.com/item?id=11574715 https://news.ycombinator.com/item?id=11574715 ) And more: [3] https://embeddedartistry.com/blog/2018/8/13/timeless-laws-software-development https://embeddedartistry.com/blog/2018/8/13/timeless-laws-so... (a whole book titled Timeless Laws of Software Development) [4] https://www.red-gate.com/simple-talk/opinion/opinion-pieces/some-laws-of-software-development/ https://www.red-gate.com/simple-talk/opinion/opinion-pieces/... [5] https://www.netobjectives.com/blogs/some-laws-software-development https://www.netobjectives.com/blogs/some-laws-software-devel... [6] http://www.methodsandtools.com/archive/softwarelaws.php http://www.methodsandtools.com/archive/softwarelaws.php
- sneak 8y agoPostel’s law is lately considered harmful, and Linus’ law has been disproven a lot of times (eg goto fail, but also in the linux kernel).
- deleted 8y ago[deleted]
- coleca 8y agoBiggest one that is missing from the list in my opinion is Vogels Law: "Everything breaks, all the time" - Dr. Werner Vogels CTO Amazon.com
- BerislavLopac 8y agoOr, alternatively, Norton's law: "Everything is broken." https://medium.com/message/everything-is-broken-81e5f33a24e1 https://medium.com/message/everything-is-broken-81e5f33a24e1
- CalChris 8y agoJoy’s Law: most of the smartest people work for someone else.
- carlmr 8y agoIf your company doesn't hire more than 50% of all developers in the world at random, then this is probably true.
- sorahn 8y agoThere is an entire poster of funny 'laws of computing' that was created in 1980 by Kenneth Grooms. It's pretty amazing how many of these are completely relevant 40 years later... It's hard to find the original piece of art, but my uncle had this hanging in his office for a long time, and now it's hanging in mine. I transcribed it in a gist so I had access to them for copy/paste. https://gist.github.com/sorahn/905f67acf00d6f2aa69e74a39de65941 https://gist.github.com/sorahn/905f67acf00d6f2aa69e74a39de65... (Those pictures were from an ebay auction before I got the actual piece)
- MattyRad 8y agoThe Peter Principle is also referred to as Putt's Law (https://en.m.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat https://en.m.wikipedia.org/wiki/Putt%27s_Law_and_the_Success...) and phrased slightly differently.
- yesenadam 8y agoPutt'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.
- redcodenl 8y agoRegarding 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 the teams became responsible for just a part of the system, their microservice(s). Whenever we had an outage, one team was left to fix it, the others just went home. They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices.
- BerislavLopac 8y ago> They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices. Honestly, this sounds like an improvement.
- badfrog 8y agoHow is people not talking to each other an improvement?
- jcadam 8y agoWell, 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...
- marcosdumay 8y agoThat'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.
- enriquto 8y agodoes it work for you? The site only shows a beating gray circle.
- yoz-y 8y agoIt seems to be a SPA so it requires JS to load the content.
- mrob 8y agoAs is often the case with these kinds of abuses of JavaScript, Firefox's Reader View solves the problem.
- enriquto 8y agoIt seems to be a strange interaction between css and javascript. Using umatrix, I can read the text with both css and javascript disabled, but not with only javascript disabled. This is the first time I encounter this curious behavior.
- theandrewbailey 8y agoFinagle's law: "Anything that can go wrong, will-at the worst possible moment." https://en.wikipedia.org/wiki/Finagle%27s_law https://en.wikipedia.org/wiki/Finagle%27s_law
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- davidkuhta 8y agoI feel like Fonzie's Law would be a worthwhile inclusion: "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
- aitchnyu 8y agoI refuse to fall for that bait.
- davidkuhta 8y agoRemember that all is opinion. For what was said by the Cynic Monimus is manifest: and manifest too is the use of what was said, if a man receives what may be got out of it as far as it is true.
- dccoolgai 8y agoMissing: Goodhearts Law
- JackFr 8y agoQuick and dirty is rarely quick and always dirty. (Don't know if it has a name)
- sagartewari01 8y agoEspecially in the java world. It can no longer be considered quick by the time IDE boots up.
- yoz-y 8y agoFirst time hearing this one. I really like it.
- tabtab 8y agoYou can have quick-and-dirty for initial release, but it's rarely practical from a maintenance perspective. 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.
- klodolph 8y agoI 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 service which relies on it may not be able to handle errors or unavailability. Introducing errors in a controlled way can help make the dependencies more reliable. As another example, being liberal about what you accept can sometimes result in security flaws, since different systems might be interpreting a message differently. Rejecting malformed input can be a beautiful thing.
- marcosdumay 8y agoPostel'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.
- klodolph 8y agoI know what Postel’s law is about, the argument stands. Postel said that in 1989 and our thinking about protocols has changed a bit since then. If you’re implementing a standard protocol like HTTP or TLS, and you are liberal in what you accept, this can cause security problems or other unintended behavior. For example, consider a proxy or gateway that interprets a request differently from an authoritative server. Suppose a nonstandard request is handled differently by each component. Ideally, one of the responses is, "this request is malformed, reject it". If each component handles the same request differently but without rejecting the request, you are quite possibly in a world of hurt. 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.
- JackFr 8y ago______ is like violence, if it's not solving your problem, you're not using enough of it. (I first heard that for XML, and since have heard it for others. Was very funny for XML though. I also know its not really a law.)
- sagartewari01 8y agoCommunication?
- andrelaszlo 8y agoI expected to see Lehman's laws[0] in there too, but maybe they are not famous enough. Maybe they don't deserve to be, but I think they are relevant observations. [0]: http://wiki.c2.com/?LehmansLaws http://wiki.c2.com/?LehmansLaws
- Dangeranger 8y agoWouldn't the following be an embrace of Conway's Law rather than a defense against it? > It is much better, and more and more implemented as such, to deploy teams around a bounded context. Architectures such as microservices structure their teams around service boundaries rather than siloed technical architecture partitions. > So, structure teams to look like your target architecture, and it will be easier to achieve it. That's how you defend against Conways's law.
- throwaway2016a 8y agoMurphy's Law has electrical engineering roots. I have a fun anecdote.[0] My wife is electromechanical and I'm computer science so we would work on projects together since we make a good team. I remember in college I was working with my wife on one of her projects and we were using force transducers. The damn things kept breaking at the worst times so we kept calling it Murphy's Law. After a while we looked it up. Turns out Murphy was working with transducers when he coined the phrase [1]. So I have this little back pocket anecdote about the time I got to use Murphy's Law in the original context. Which I can bring out in times just like this. [0] I think it is fun. Your milage may vary. [1] https://en.wikipedia.org/wiki/Murphy%27s_law https://en.wikipedia.org/wiki/Murphy%27s_law
- ddebernardy 8y agoI'm not sure who they should be named after, but I'd like to suggest two more: > Redundancy is bad, but dependencies are worse. https://yosefk.com/blog/redundancy-vs-dependencies-which-is-worse.html https://yosefk.com/blog/redundancy-vs-dependencies-which-is-... > Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. https://stackoverflow.com/questions/876089/who-wrote-this-programing-saying-always-code-as-if-the-guy-who-ends-up-maintai https://stackoverflow.com/questions/876089/who-wrote-this-pr...
- Gipetto 8y agoIs there a law about the probability that an article about programming will reference XKCD?
- _ah 8y ago1. 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.
- Balgair 8y agoDevOps 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 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.
- ComodoHacker 8y agoCould someone explain the last one, Norvig's Law: "Any technology that surpasses 50% penetration will never double again (in any number of months)."
- TeMPOraL 8y ago2x 50% penetration = 100% penetration.
- jnty 8y agoDouble 50% is 100%, so assuming your market doesn't significantly grow, it's impossible to double your market share again.
- arendtio 8y agoWell, I wonder if it is true. I mean, theoretically, something could reach 50% drop down to 30% again and double to 60% again. Yes, it is unlikely, but I see no reason why it should not be possible: http://www.norvig.com/norvigs-law.html http://www.norvig.com/norvigs-law.html But most certainly that is not how the law was meant to be interpreted.
- mojuba 8y agoOh 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.
- lojack 8y agoHis full quote is a little less prone to abuse > 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.
- mr_tristan 8y agoYeah, I get frustrated that few people actually post the full quote, because, with the context, it means something completely different to young ears. The full quote makes me think: "You should identify the critical paths of your system early." The shortened quote makes me think: "Deal with performance later." Pretty big difference in meaning.
- hermitdev 8y agoPersonally, I think it's more about balancing trade offs. You need to have some semblance of target performance needs. Bad architecture can be hard to overcome later. Most decisions are small, but can lead to compounding effects. Personally, I think one should also avoid premature pessimissation as well. No one in their right mind would use bubble sort over quick sort, for instance (not saying quick sort is the best algorithm, but it's better than bubble sort). One pet peeve I have in C++ is when I see people initializing a std::string with a literal empty string instead of using the default constructor. The default constructor is usually a memset or initializing 3 pointers. Initializing with an empty literal involves a call to strlen, malloc and strcpy. I've yet to see a compiler optimize this. May not seem like a big deal, but considering one of the most frequently used data types is a string, it adds up a lot. Most of the applications I've worked on show std::string methods and constructors as hotspots when profiled (back office financial systems). I agree one should avoid premature micro-optimization, but that you can also avoid premature pessimissation.
- tynpeddler 8y agoIt's very common for Conway's law to be regarded as some kind of warning, as if it's something to be "defended" against. It's not. Conway's law is the most basic and important principle to creating software at scale. A better way of stating Conway's law is that if you want to design a large, sophisticated system, the first step is to design the organization that will implement the system. 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.
- thomasjudge 8y agoA partner to the Peter Principle, particularly with respect to managers, is the Dunning-Kruger effect: "In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people of low ability have illusory superiority and mistakenly assess their cognitive ability as greater than it is."
- hajile 8y agoEveryone always conveniently forgets Price's Law (derived from Lotka's Law) It states that 50% of work is done by the square root of the number of employees. Interestingly, Price's law seems to indicate 10x developers exist because if you have 100 employees, then 10 of them do half of all the work. This idea is particularly critical when it comes to things like layoffs. If they get scared and leave or they are let go for whatever reason, the business disproportionately suffers. Some economists believe that this brain drain has been a primary cause in the death spiral of some large companies.
- firethief 8y ago> Interestingly, Price's law seems to indicate 10x developers exist because if you have 100 employees, then 10 of them do half of all the work. Or 0.1x developers exist...
- hajile 8y agoYou have to completely abandon reality to get rid of the idea. If 60 of the remaining 90 devs did NOTHING, those 10 devs would still be 2.5x better than the rest. To take things further, make a bell curve chart. Put 50% of the area under the top 10%. Now, divide up the rest however you'd like. The only way to make this happen is for a huge percent to not only contribute zero, but to be actively hurting development to an extreme degree. I have never found a 100 person company where 60% or more of the company was contributing absolutely nothing. I have never seen a company where a large number of people were actively harming the company and the company survived.
- Benjammer 8y ago>I have never seen a company where a large number of people were actively harming the company and the company survived. Sorta buried the lede there, eh?
- hajile 8y agoThe law seems to hold for successful companies and companies that violate the law seem to disappear. If someone has found the Russell's Teapot of companies that strays so far into absurdity while still being true, then let them bring forth the proof.
- _hardwaregeek 8y agoI like Wiggin's Law (found in [My Heroku Values](https://gist.github.com/adamwiggins/5687294) https://gist.github.com/adamwiggins/5687294)): If it's hard, cut scope. I'm working on a compiler for my new language and sometimes I get caught up in the sheer amount of work involved in implementing a new language. I mean, I have to write a typechecker, a code generator, a runtime (including GC), a stdlib, etc. But instead of just getting overwhelmed, I'm trying to cut scope and just focus on getting a small part working. Even if the code is terrible, even if it's limited in functionality, I just need to get something working.
- gumby 8y agoI 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. Here are a few: 1 - Backward compatibility can bite you in the leg. For example, USB Type C (which I love!) can support very high transfer rates but when it can't it will silently fall back. So you could have a 40 Gbps drive connected to a 40 Gbps port on a computer via a cable that only supports USB 2 speeds. It will "work" but maybe not as intended. Is this good, or should it have failed to work (or alerted the user to make a choice) so that the user can go find a better cable? 2 - DWIM is inherently unstable. For users that might not be bad (they can see the result and retry) or terrible ("crap, I didn't mean to destroy the whole filesystem"). I see these problems all the time in our own code base where someone generates some invalidly-formatted traffic which is interpreted one way by their code and a different way by someone else's. Our system is written in at least four languages. We'd be better off being more strict, but some of the languages (Python, Javascript) are liberal in both what they accept and generate. This aphorism/law was written for the network back when we wrote all the protocol handlers by hand. Now we have so many structured tools and layered protocols this is much less necessary.
- jacques_chester 8y ago"The Harmful Consequences of the Robustness Principle" is a good read: https://tools.ietf.org/html/draft-iab-protocol-maintenance-01 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
- mannykannot 8y agoBeing 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.
- jrochkind1 8y agoPostel's law, "be conservative in what you send, be liberal in what you accept"is definitely not "a uniter"! https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...
- aeternus 8y agoYes, especially when you consider Hyrum's law.
- Cpoll 8y agoKind of unrelated to the article, but does the Moore's law joke about the cat constant make any sense? The `-C` constant should be on both sides of the equation (since the formula is future computation _relative to_ current computation), and thus cancel out. As it stands, the equation doesn't make sense when 'Number of years' is zero, and is inconsistent between calculating twice in 2-year intervals and calculating once with a 4-year interval (as an example).
- DGAP 8y agoMy personal law from working in software consulting is "triple the estimate."
- AzzieElbab 8y agoMy law: convenience topples correctness. Evidence -programmers have been proven incapable of quoting Knuth's optimization principle correctly and in full
- vram22 8y agoMurphy's Law: https://en.wikipedia.org/wiki/Murphy%27s_law https://en.wikipedia.org/wiki/Murphy%27s_law and Muphry's Law: https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law
- worik 8y ago* A organisation's requirements for data processing is a function of the organisations data processing capabilities and always greater * All software has bugs, no software is inefficient * A programmer's work is never done
- composer 8y agoReRe's Law of Repetition and Redundancy [2] seems appropriate here: A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet, A programmer's job is to automate the repeated and the redundant. Thus, A programmer delivering to an estimated or predictable schedule is... Not doing their job (or is redundant). [2] https://news.ycombinator.com/item?id=12150889 https://news.ycombinator.com/item?id=12150889
- mamon 8y agoInteresting 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.
- sporkland 8y agoI would add Greenspun's tenth rule (law)[1]: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. And Beneford's law of controversy [2], which I see around monorepo vs polyrepo, language choices, tabs vs spaces, etc: Passion is inversely proportional to the amount of real information available. [1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule [2] https://en.wikipedia.org/wiki/Gregory_Benford https://en.wikipedia.org/wiki/Gregory_Benford
- b0rsuk 8y ago"Any programmer can be replaced with a finite number of interns" - Janusz Filipiak, the biggest shareholder of Comarch, Poland.
- Const-me 8y agoAm I the only person here thinking that many of them are just anecdotes, or are deprecated? > Given enough eyeballs, all bugs are shallow. Just count of viewers doesn't help. The owners of these eyeballs need both motivation to look for these bugs, and expertise to find them. > The power of computers per unit cost doubles every 24 month. Slowed down years ago. > Software gets slower faster than hardware gets faster. It doesn't. If you'll benchmark new software on new PCs versus old software on old PCs processing same amount of data, you'll find out the new one is faster by orders of magnitude. Input to screen latency might be 1-2 frames slower, because USB, GPU, HDMI, LCD indeed have more latency compared to COM ports, VGA, and CRT. But throughput is way better. > Premature optimization is the root of all evil. Was probably true while the power of computers doubled every 24 month. It doesn't any more.