16 ms·
The Only Unbreakable Law [video]
- axiosgunnar 5y agotldw?
- 0xbadc0de5 5y agoYou care about this if: - Software architecture matters to you - Software performance matters to you - Team and organizational performance matters to you
- teddyh 5y agoIt’s Conway's law.
- smegsicle 5y agoconway's law: how it arises, why it's unavoidable, relationship w brooks' and amdahl's laws, how it explains complexity compounding over time in the form of integrating with past organization structure..
- beebmam 5y agoA law that doesn't make predictions isn't a law. A law that is not falsifiable isn't a law. It is an unscientific belief. It's truly incredible to me that people, like the person in this video, can speak with such confidence about how, for example from this video, "if we look at an org chart for an organization, and we look at the structure of the products that it produces, we would expect them to basically just be collapses of each other [i.e. a homomorphism]". Also known as https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law A sincere person in search of truth asks questions like the following when they encounter a claim: - can we think of circumstances where this law is not true? - can we test this claim to show that it is true? - can a test be devised which would falsify this claim? - if this claim is true, what are the mechanisms of action for the claim? - if this claim is true, are there any contradictions that would arise with other things we know are true? Using the same metaphor used in this video, if the currently recognized law of gravitation (General Relativity) made predictions which were different than what is observed, then that law is wrong. And a scientist would adjust their law to reality and be more than willing to point out the gaps of explanation in our law of gravitation (which they do). If we're serious about Computer Science (and Software Engineering) being a field in pursuit of truth, we should be as rigorous and critical as other fields of science and engineering when it comes to making claims.
- ukj 5y agoPlease spare us from truth-seeking and leave that to the philosophers. In science/engineering we care about instrumentalism, not truth. All models are wrong. Some are useful.
- Ygg2 5y ago> Please spare us from truth-seeking and leave that to the philosophers. What? Parent is litteraly saying don't trust a model that has no predictive power. You're saying leave model evaluation to philosophers. Last time we did that we did that we had theory of four elements and phlogiston.
- ukj 5y agoNo. I am saying leave truth/truthfulness to philosophers. Every model has predictive power. Even the God model. It predicts something existing; rather than nothing. Of course, it is a worthless prediction but it is a prediction.
- Ygg2 5y ago> No. I am saying leave truth/truthfulness to philosophers. I think you mean scientists. I.e., construct an experiment validate, etc. God model the least possible predictive power imaginable. Also, according to philosophers, God must exist because it's a perfect being. And a perfect being must exist because it is perfect. They are like people left in a sensory deprivation tank hallucinating random patterns into a sensible picture.
- aaaaaaaaaaab 5y agoConway's "law" is such a cop-out excuse for shipping shitty software... There's no such law of nature that says you must ship shitty software. Enterprises ship shitty software because the average tenure of their developers is 2 years, and they have no incentive to improve things beyond what's necessary to pay the bills.
- Ygg2 5y agoI mean at the end of the day it boils to few things. - Entropy - Capitalism - Greed To not be vague, user greed for features and less for performance cause increase in complexity. A complex system is by definition more chaotic and harder to optimize. And Capitalism rewards doing just a bit better than competition. I.e. optimize your time on quickest things that gives most users satisfaction.
- Jensson 5y ago> And Capitalism rewards doing just a bit better than competition. I.e. optimize your time on quickest things that gives most users satisfaction. More specifically, capitalism doesn't reward the worker for doing software architecture better at all, just rewards the company. So the workers will naturally make the politically safe choice for software architecture and not care whether that is right, which means making it look like the org chart.
- kortilla 5y agoGreed and capitalism don’t explain it. We get shitty software from governments and research labs that have no competition and that get no rewards for shipping extra features.
- brown 5y agoNice video. Conway's 1968 paper is a good find. The conclusion is slightly defeatist, but ultimately correct. At time 49:23, Casey says "But we have to do them right now, because we haven't figured out how to do it better." [excessive modularity] is the worst form of [software development] – except for all the others that have been tried.
- andrelaszlo 5y agoPerhaps it's a desperate attempt to defer the problem of what the organization should look like. The more nodes you have in your graph, the easier it will be to collapse it into something that maps to the organization you want?
- galangalalgol 5y agoSometimes it feels like a desperate attempt to defer working on some part of the problem a team doesn't know how to solve. Usually some domain specific thing no one wants to think about. So onion layers get put in wrapped around that bit without actually solving it, just creating an abstraction by which the rest of the system will use the "magic". But often the abstraction overconstrains the domain specific magic through ignorance, so it all has to change when someone gets around to adding it. Seen this over and over.
- jchw 5y agoI’m fairly conflicted by this, because it’s fairly insightful, but it’s also probably overselling itself. They expound quite hard on the idea that abstraction is inherently bad, and I feel this is a poor choice of words, and perhaps a mistake. Abstractions have cost. In many forms, and especially if the abstraction is a poor one. However… they don’t seem to differentiate between good and bad abstractions. They seem to regard all abstraction as simply unnecessary, only used because our brains cannot deal with the entire problem at once. I think you could make this argument to some degree but it breaks down when you start to see where abstraction is worth the cost. As an example, let’s say I’m writing a service that needs a key value store. If I make a simple abstraction for it, with well-defined properties for exactly how it should behave, how data consistency should work, etc. then implement multiple backends, this is a good abstraction. The reason for this is because software doesn’t have fixed requirements. Some users may be running a small instance of something on their desktop or a NAS or what have you, whereas others may be running software on gigantic clusters and would benefit from using clustered key value stores that are much more difficult to setup for valid, unchangeable reasons, even if we were to get rid of the abstraction and fully integrate a distributed key-value store right into our program. Also, requirements change temporally. Clang could’ve implemented everything with no abstractions, but when Clang was created it targeted older and fewer versions of programming languages. The abstractions have cost, particularly when they are bad; but not having abstractions would’ve costed far more, IMO. Extending and reusing software that has little abstraction is very difficult because there’s very few reliable boundaries you can work off of. Adding a new operator in Clang is probably still hard, but I’m sure it would be harder if you carried forward all of the abstraction and folded it down instead. You need some kind of abstraction if you want cheap extensibility. So my conclusion is basically, abstraction is not bad. Libraries are not bad. Engines are not bad. They simply have costs that are not accounted for properly, and may cost more than the value they provide in many cases. Intuitively, we know this; It’s basically the knee-jerk software engineers get when they get into a build-vs-buy discussion. You feel the jolt. The library has an amazing feature list, but something tells you it won’t be so easy. That’s the hidden cost right there.
- chii 5y ago> You need some kind of abstraction if you want cheap extensibility. so does the need for cheap extensibility comes first, in which case you build up the abstraction to enable it? Or does abstraction get built up first, which gives you cheap extensibility, then users start needing it afterwards? What if clang didn't end up being as popular as it did, and the effort it took for the "cheap" extensibility was never needed as no one actually extended it?
- unyttigfjelltol 5y agoThe law holds for human orgs for a reason beyond "communication". No business unit that is asked to contribute to a project would allow its contribution to take a form different from a discrete, quantifiable module. The 5-person team in the lecture came up with a 5-pass compiler because none of the 5 people were willing to have an unquantifiable contribution indistinguishable from having not shown up to work in the first place. The case with software classes and components is different. None of those inanimate object care if their contribution is measurable, so the law does not apply as strongly with respect to them.
- FpUser 5y agoI think basic idea and architectures stay more or less the same for decades. Wrapping it out in some fancy terminology and calling those new does not mean "braking the law". It is like RPC vs CORBA vs DCOM vs /10000 other come and go standards which are essentially the same thing.
- sbmthakur 5y agoThe Morning paper did a summary of the paper mentioned in the video. https://blog.acolyer.org/2019/12/13/how-do-committees-invent/ https://blog.acolyer.org/2019/12/13/how-do-committees-invent...
- deleted 5y ago[deleted]
- ladberg 5y agoCasey's name should be in the title! I think a lot of HNers respect him.
- russellbeattie 5y agoReally?? I have no idea who he is, and this video didn't impress me at all.
- seanhunter 5y agoWith you on that. I had no idea who he was and definitely didn’t come out of that talk wanting more of whatever he is selling. Incredibly trite and wildly overlong is how I would describe this.
- holyyikes 5y ago
- HexDecOctBin 5y ago> You can safely ignore this guy. Thanks for telling us this. We might have thought for ourselves based on the content, but now we don't need to.
- holyyikes 5y agoWhen he can't make a video shorter than 50 minutes, figuring it out for yourself is a pretty serious time investment, but whatever.
- houseinthewoods 5y ago
- dS0rrow 5y agodo you mind sharing why you consider handmade hero a con ?
- Laremere 5y agoI think it's fair to have opinions, but you are overstating your case here - > You could have had an entire career in the video game industry in the amount of time he's managed to produce some pile of crap that doesn't even have a complete gameplay loop. Including taking time to explain concepts, Q+A, and design choices made to educate that are then iterated upon (eg, doing 2d graphics from scratch then moving to 3d), he has accumulated approximately 28 weeks of full time work.[1] That's a very sad "career" in video games. [1] Math: Using playist https://www.youtube.com/playlist?list=PLnuhp3Xd9PYTt6svyQPyRO_AAuMWGxPzU https://www.youtube.com/playlist?list=PLnuhp3Xd9PYTt6svyQPyR... with a calculation tool https://ytplaylist-len.herokuapp.com/ https://ytplaylist-len.herokuapp.com/ gives an average of 1 hour 40 minutes per video. The tool has a limit of 500 videos, so multiplying average length by true playlist length, then dividing by 40 hours per week gives 27.83 weeks: https://www.wolframalpha.com/input?i=%281+hour+40+minutes%29+*+668+%2F+%2840+hours%29 https://www.wolframalpha.com/input?i=%281+hour+40+minutes%29...
- ghostly_s 5y agoWhat is this clickbait garbage?
- kirykl 5y agolede is buried at the bottom of challenger deep on this one
- mellosouls 5y agoAn hour long video with comments turned off? A summary would be useful...
- worewood 5y agoYeah.. I can understand this block on political videos or other sensitive topics but on this? Well if you can't take the criticism perhaps don't post it on youtube.
- Etherlord87 5y agoIt's sad how bad Youtube comments are, but usually some good comments float to the top, and while neither high confidence of a comment author nor high number of likes of the comment give you a guarantee that it's right, often a comment will be a good lead - for example it could link to this HN conversation on the video. I took a glimpse what people here say about the video and I find too many criticisms to consider it reasonable to spend time watching the video...
- bentheklutz 5y agoTowards the bottom of the thread there is a pretty reasonable summary. https://news.ycombinator.com/item?id=30738878 https://news.ycombinator.com/item?id=30738878
- seanhunter 5y agoI would say just read Conway’s actual paper “How do committees invent”. This is one of those talks where I’m convinced the person is being paid by the second. By the time we had got to the third iteration of “before I tell you the thing I’m going to talk about let me (define what a law is/critique Harvard business review/give an irrelevant sidebar about the language of technical papers and the fact ‘Datamation’ still exists”) I totally had lost any and all interest.
- clarkdale 5y agoI'm curious in how to use Conway's Law to be more effective. I can learn from Brooks and Amdahls to improve software, but how to apply Conway's? I think the closest thing is Bezos's API mandate. This is an attempt to flatten communications across a vast organization, with the upfront cost that each team build and maintain an API.
- deleted 5y ago[deleted]
- phtrivier 5y agoEven more depressing than "The 20 million lines problem" - because the gist of the talk is that programming with more than one person is doomed to fail, and programming with less than two is even worse.
- holyyikes 5y ago
- 0xbadc0de5 5y agoHaving watched Casey's Handmade Hero series since day-1, I've always found him to be highly skilled and insightful. While not a game developer myself, learning from his approach to first-principles software development and code optimization has paid dividends in my day to day work nonetheless.
- Ygg2 5y agoI've found him passionate and smart. But rarely right. Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.
- teddyh 5y agoNot to mention that the “S” in SOLID is closely related to what he is talking about here, namely that a software component ought to be related to only one specific source of changes – i.e. a box in an org chart – in order to minimize the risk of it being changed badly and consequently break something. This implies that you should have a connection between the org chart and the code, in order for the changes in the code over time to not constantly break the code.
- jdougan 5y agoWith both Casey and Jon Blow I find that if I mentally prefix what they say with "When developing AAA games..." then they are almost always right. Much of it doesn't transfer far outside that domain.