The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design. To the naive mind that can conceive of order only as the product of deliberate arrangement, it may seem absurd that in complex conditions order, and adaptation to the unknown, can be achieved more effectively by decentralizing decisions and that a division of authority will actually extend the possibility of overall order. Yet that decentralization actually leads to more information being taken into account. - Friedrich A. Hayek
> Yet that decentralization actually leads to more information being taken into account
I fully agree with this quote, however it's important to note the context that Hayek (and other ancaps/neoliberals) consider that only selfish personal financial interest should be taken into account, and their proponents go to great lengths to impose that aspect on everyone through government intervention and other manipulation strategies.
See also Naomi Klein's Shock Doctrine, or Noam Chomsky's Manufacturing consent. Both of whom, from my readings, agree with that quote, but in a more social/cooperative interpretation that is more in line with how most people behave in reality. Adam Curtis also has a documentary series on this topic called "The Trap: what happened to our dreams of freedom?".
To paraphrase an experiment outlined in these documentaries, back when the game theory hypothesis of human relations was tested, it turned out only economists and sociopaths behaved accordingly. I'm sure such a study would yield significantly different results today, after decades of neoliberal propaganda and startup culture, but it's worth pointing out from a historical perspective that decentralization and mutual aid is how humanity progressed thus far (see also Piotr Kropotkin's Mutual Aid for a (out)dated scientific take on that topic).
>only selfish personal financial interest should be taken into account
Sorry, that's just wrong. Firstly, the central scientific question is one of description and not prescription. It's not what should be taken into account but what actually is. Secondly, that which is taken into account is not "selfish personal financial interest" but preference. Would you seriously try and deny that you have preferences and choose your actions in accordance with those preferences? Well, neither can anyone else.
Hey, can you please make your substantive points without crossing into the flamewar style on HN? We're trying for curious conversation here, which is more or less disjoint from ideological battle (and this particular ideological theme is of course a flamewar classic).
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful. Note this one: "Have curious conversation; don't cross-examine."
Hi, I've reviewed my comment and unfortunately I honestly can't see what's wrong with it.
I've made two points about factual errors and I asked a rhetorical question to drive my point home. I highlighted, but deliberately didn't further comment on, the unnecessarily loaded language of the parent comment.
Although I'm told I come from a culture that tends towards speaking somewhat bluntly, I'm truly surprised and a bit confused to have my comment come across as "flamewar style", when what I was going for was more along the lines of "clinically detached rebuttal".
I read HN comments rather superficially (just because time/quantity is so low). From that perspective, when a comment starts with a putdown like "Sorry, that's just wrong" and ends with "Would you seriously try and deny", it's already clear that it isn't curious conversation.
When I read the comment more closely it doesn't seem as bad. If you'd dropped the swipe in the first sentence, it would've been ok. I'm sure it's true that culture enters into this, but given that HN is a highly international/multicultural forum, what that unfortunately means is that we all have to neutralize ourselves a little bit in order to be understood correctly. or something like that.
I think the famous article 'Things you should never do' from Joel Spolsky is closely related to this. I have seen blatently ignoring the lessons from either article and reaping the predictable results from this in multiple jobs that I had. It seems the incremental approach that is both much safer and much more fruitful is a rather hard thing to sell.
Even after a project in the category 'things you should never do' had taken way too long, when another piece of code was discovered that was not quite up to standards and that was sometimes malfunctioning the first idea was again to completely throw it out and rewrite from scratch. I argued against this and instead took the Michael Feathers approach of first covering it in tests and then refactoring. This made the code familiar enough to me that I also in the meantime found the reason it was malfunctioning. It was just a multi-threading isssue that could be fixed by introducing a lock. Size of the actual patch fixing it is about 5 lines.... The result of the gradual approach was both more modern code, automated tests, and no more failures in production and it was much faster than just throwing out the whole thing and starting anew would have been.
I’ve been on a few successful rewrites, and still think those were the right decisions. It’s not a “thou shalt not”, in my opinion, but rather contextual.
Also, you could say that Chrome was a rewrite of Firefox. Office was a rewrite of Lotus Notes. Google was a rewrite of Yahoo. Facebook was a rewrite of MySpace. And so on. Most market-leading products were not the first to market, and can be seen as a rewrite of a previous product.
Quite the examples you name.... Google has come under quite a bit of public scrutiny for their general practice of espionage performed on the general public and I think we should notice that Chrome is part of that. I have never worked with lotus notes but I did with wordperfect. The progression seems from tool that are understandable to tools that throw away all formatting at the slightest provocation. I am not so sure about it. Of course, I personally would write all of my text in LaTeX.... And where do we start on the topic of Facebook.... maybe try to read a few HN threads regarding the subject.... Maybe I am just starting to feel old but it makes me wonder if we are not over the top in terms of software quality. As far as programming is concerned I consider tool churn as the biggest enemy of the programmer. Especially when a single product consists of too many languages which all have their associated tools. So, that would be another shot against rewriting. In any case, if you are to use the same toolchain anyway, one might as well take large portions of the existing system. Personally I can do anything I want to do with vim, c++, make, coq and LaTeX. All the rest of it has pretty much been brought in without me asking for any of it....
Unlike many, I won’t start with a duct-tape-and-baling-wire chimera that barely works, as MVP. I like to start with a very solid baseline. Good quality, well-tested, extensible architecture, etc., and work up from there.
I like to maintain what I call “constant beta,” where the project is what I consider “bug free,” at all times (although incomplete). This means that, as I develop a project, I am constantly testing (usually by writing a test harness in parallel with the principal codeline[0]). If I encounter any bugs (even “little” ones), I stop all forward feature development, until the bug is either fixed, or converted into a “stable” TODO.
As you can imagine, this was not popular with my employers; even the ones obsessed with Quality. I had to wait until I was released on my own recognizance, before I could try working this way.
The results have been quite good.
One example of how this pays off, is that I can start using Apple’s TestFlight beta-testing service, very, very, very early in a project. This allows the project to be distributed to many testers, evaluators, and stakeholders, for feedback and design review, at an extremely early stage. Sort of an “internal MVP,” with a great deal of control over the testing.
Works a treat. It’s definitely a bit of a risk, that the ultimate end-users are not being used as the “fuzz testing pool,” but it does help to ensure a fairly stable future for the project. Risk is basically the lifeblood of entrepreneurship. Releasing questionable-quality product, too early, carries significant risk, as well.
One issue, that I frequently encounter, is that people refuse to consider the price paid for shoddy quality. The only cost they consider, is initial development, with a “we’ll fix that down the road” mentality.
In my experience, bad quality can easily result in extinction-level events (E.L.E.) Brand damage, being one example. Brand damage can be unrecoverable. It’s also quite difficult to quantify.
But in today’s climate, end-users don’t seem to care about Quality, so I do it for my own satisfaction.
In general, they're right. But you have to be careful not to fall into the opposite trap.
Business people and VCs love MVPs and iterative solutions, because they love to sell first and build later. And others have the obligation to scramble and to actually build the solution. So, by all means, evaluate what you are building first. But that is no excuse for selling stuff that you haven't built yet or don't even know if you can build.
Now that I think about it, testing the market and the customer-fit on one hand and testing the technical feasibility and implementing the thing on the other hand are actually both things that salespeople like to skimp on. That's why there are so many half-baked, only half-fitting solutions out there.
While I do think this Gall’s law is mostly true it’s statement gave me a good laugh since clearly Gall didn’t pay attention in Discrete Math/Logic class. The “inverse” Gall discussed is in fact logically equivalent
> A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work.
14 comments
[ 2.0 ms ] story [ 46.3 ms ] threadThe curious task of economics is to demonstrate to men how little they really know about what they imagine they can design. To the naive mind that can conceive of order only as the product of deliberate arrangement, it may seem absurd that in complex conditions order, and adaptation to the unknown, can be achieved more effectively by decentralizing decisions and that a division of authority will actually extend the possibility of overall order. Yet that decentralization actually leads to more information being taken into account. - Friedrich A. Hayek
I fully agree with this quote, however it's important to note the context that Hayek (and other ancaps/neoliberals) consider that only selfish personal financial interest should be taken into account, and their proponents go to great lengths to impose that aspect on everyone through government intervention and other manipulation strategies.
See also Naomi Klein's Shock Doctrine, or Noam Chomsky's Manufacturing consent. Both of whom, from my readings, agree with that quote, but in a more social/cooperative interpretation that is more in line with how most people behave in reality. Adam Curtis also has a documentary series on this topic called "The Trap: what happened to our dreams of freedom?".
To paraphrase an experiment outlined in these documentaries, back when the game theory hypothesis of human relations was tested, it turned out only economists and sociopaths behaved accordingly. I'm sure such a study would yield significantly different results today, after decades of neoliberal propaganda and startup culture, but it's worth pointing out from a historical perspective that decentralization and mutual aid is how humanity progressed thus far (see also Piotr Kropotkin's Mutual Aid for a (out)dated scientific take on that topic).
Sorry, that's just wrong. Firstly, the central scientific question is one of description and not prescription. It's not what should be taken into account but what actually is. Secondly, that which is taken into account is not "selfish personal financial interest" but preference. Would you seriously try and deny that you have preferences and choose your actions in accordance with those preferences? Well, neither can anyone else.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful. Note this one: "Have curious conversation; don't cross-examine."
I've made two points about factual errors and I asked a rhetorical question to drive my point home. I highlighted, but deliberately didn't further comment on, the unnecessarily loaded language of the parent comment.
Although I'm told I come from a culture that tends towards speaking somewhat bluntly, I'm truly surprised and a bit confused to have my comment come across as "flamewar style", when what I was going for was more along the lines of "clinically detached rebuttal".
When I read the comment more closely it doesn't seem as bad. If you'd dropped the swipe in the first sentence, it would've been ok. I'm sure it's true that culture enters into this, but given that HN is a highly international/multicultural forum, what that unfortunately means is that we all have to neutralize ourselves a little bit in order to be understood correctly. or something like that.
Even after a project in the category 'things you should never do' had taken way too long, when another piece of code was discovered that was not quite up to standards and that was sometimes malfunctioning the first idea was again to completely throw it out and rewrite from scratch. I argued against this and instead took the Michael Feathers approach of first covering it in tests and then refactoring. This made the code familiar enough to me that I also in the meantime found the reason it was malfunctioning. It was just a multi-threading isssue that could be fixed by introducing a lock. Size of the actual patch fixing it is about 5 lines.... The result of the gradual approach was both more modern code, automated tests, and no more failures in production and it was much faster than just throwing out the whole thing and starting anew would have been.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Also, you could say that Chrome was a rewrite of Firefox. Office was a rewrite of Lotus Notes. Google was a rewrite of Yahoo. Facebook was a rewrite of MySpace. And so on. Most market-leading products were not the first to market, and can be seen as a rewrite of a previous product.
Unlike many, I won’t start with a duct-tape-and-baling-wire chimera that barely works, as MVP. I like to start with a very solid baseline. Good quality, well-tested, extensible architecture, etc., and work up from there.
I like to maintain what I call “constant beta,” where the project is what I consider “bug free,” at all times (although incomplete). This means that, as I develop a project, I am constantly testing (usually by writing a test harness in parallel with the principal codeline[0]). If I encounter any bugs (even “little” ones), I stop all forward feature development, until the bug is either fixed, or converted into a “stable” TODO.
As you can imagine, this was not popular with my employers; even the ones obsessed with Quality. I had to wait until I was released on my own recognizance, before I could try working this way.
The results have been quite good.
One example of how this pays off, is that I can start using Apple’s TestFlight beta-testing service, very, very, very early in a project. This allows the project to be distributed to many testers, evaluators, and stakeholders, for feedback and design review, at an extremely early stage. Sort of an “internal MVP,” with a great deal of control over the testing.
Works a treat. It’s definitely a bit of a risk, that the ultimate end-users are not being used as the “fuzz testing pool,” but it does help to ensure a fairly stable future for the project. Risk is basically the lifeblood of entrepreneurship. Releasing questionable-quality product, too early, carries significant risk, as well.
One issue, that I frequently encounter, is that people refuse to consider the price paid for shoddy quality. The only cost they consider, is initial development, with a “we’ll fix that down the road” mentality.
In my experience, bad quality can easily result in extinction-level events (E.L.E.) Brand damage, being one example. Brand damage can be unrecoverable. It’s also quite difficult to quantify.
But in today’s climate, end-users don’t seem to care about Quality, so I do it for my own satisfaction.
[0] https://littlegreenviper.com/miscellany/testing-harness-vs-u...
Business people and VCs love MVPs and iterative solutions, because they love to sell first and build later. And others have the obligation to scramble and to actually build the solution. So, by all means, evaluate what you are building first. But that is no excuse for selling stuff that you haven't built yet or don't even know if you can build.
Now that I think about it, testing the market and the customer-fit on one hand and testing the technical feasibility and implementing the thing on the other hand are actually both things that salespeople like to skimp on. That's why there are so many half-baked, only half-fitting solutions out there.
> A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work.
P => Q
Working Complex System => Evolved from simple
https://en.m.wikipedia.org/wiki/Modus_tollens
Not Q => Not P
Not Evolved from simple => Not Working Complex system