Gall’s Law and how I ignored it
ivanmontilla.com
ivanmontilla.com
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
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.
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.
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...
> 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