Contact Knowledge base Software

Google's tendency to hide things under the carpet

Google's tendency to hide things under the carpet

Posted on: 04/26/2017 22:49
Posted by: root - Michael Palazov - Elfial
I can say a number of good things about technologies coming from Google, but there is the other side of the coin as well. Sometimes Google or people defending them (for whatever reason) start spreading strange and sometimes bizarre claims in order to make people accept a failure or a limitation as a plus, even a heroic achievement.

I am using Android,but I rarely write code for the platform (yes it is not an OS, it is a software platform based on Linux, but we owe Apple for this confusion, Google was just forced to follow suit). Still, I cannot but admire the simplicity that made it accessible for so many developers without the need of too long and difficult learning process. Still, I can remember the 4.4.X times when a number of people started to explain why SD cards are not needed and if they are they have to be FAT formatted. Perhaps 95% of all the devices (even then) kept the memory cards under the covers and removing them to plug them into a PC was far from an everyday job. Yet many people explained how unsecured FAT is (which it is) and why we need to keep it and may be forget about memory cards, because they are slow and so on and so on ... Rubbish, complete rubbish! I guess (I cannot be sure, of course) they tried and failed to implement certain file system on SD cards in any dependable fashion and they started to spread this as excuse, because nothing in these claims computes. Even if you consider the need of FAT justified by rescuing your data, how internal memory of a device that needs rescuing can be better? A driver or even a dedicated application could read even the weirdest file system - they could have done that if those were the reasons, but no, people needed to hear not about a failure, but about care about their security. Well, I could be wrong, the reason could have been different, but these were the stated reasons, not speed for instance or difficulty (completely justifiable) of implementing fail-safe file system on SD card.

You see, I find this kind of acceptable - it was a way to deal with the widest public - it was a PR thing, but there are other situations, like Node.js for instance.Fan boys make it even harder to combat the propaganda here, I'd even say, Google is less responsible for this than its fan boys. Anyway, leaving the fans to spread their beliefs actually hurts Google in the long run, because people adopt Node.js for purposes completely unnatural for the platform. I talk about the single threaded nature of the thing. Yes it makes sense, it is even necessary, because of the Javascript standards, but even clustering (forking processes) with all its inadequacies is not promoted as a cure, instead we hear how good and powerful the single threaded approach is and how it is better than multi threading. Well, there is truth and fallacy here- Node is hybride - single Javascript thread and multiple worker threads usable by native modules. If you can make it so that the majority of your processing work is "simplified" to operations performed by such modules, then it is true (providing this thread pool works nicely - I confess, I never found the time to browse through its source code). However the reality is different and people need to do a lot of work in the Javascript, many modules do stuff that is expected to be synchronous and we end up with the cluster module as the only cure available to us. Here I want to say something about the fashion - Node.js won the young and inexperienced, they believe and follow every prescription and every limitation as if they are God's will - without questions, without doubt. Nobody bats an eye when they learn that they can exchange only serialized data between clustered processes, but I can remember how ASP (Classic) developers attacked me (as if I am The Big Bad Microsoft) when I told them that they cannot put in Application Javascript/VBScript objects, because they are from separate script engine instances which may not even have partially overlapping life cycles. This was 15-20 years ago, now the overwhelming majority of the Node users doesn't even care what is the reason or how the V8 works, they just obey, because it is the best thing in the world and must be obeyed.

I read a bunch of comparisons with Apache, Nginx and some others, long and wrong explanations about what worker processes or threads are. Still, nobody explained what really worker processes are, how they can actually dispatch their work internally over many threads (if they want to), how even Fast CGI standard is kind of designed to help such attempts. It is simply ridiculous to discuss if Apache is or isn't multi-threaded, because the dispatching of the application level work is by design "after" the Apache (or in any of the high performance oriented WEB servers). Yet, many of those articles have gone far and wide to discuss pros and cons of something their authors imagined with their limited knowledge and imagination.

What I cannot understand is why Google is not putting enough effort to propagate the practical truth. Even if there are good articles from Google, I never hit even one, on the contrary I read some doubtful explanations even in the documentation - not fallacies, but articles leaving space for fans to imagine wrong explanations. I am not just ranting here, I am mad about the months and years I lost explaining to young programmers why they should listen to me or someone else who knows what he/she is talking about instead of wasting time to discuss between themselves how we are not using the most modern and advanced stuff - they really believe that a tool for quick modeling and low intensity networking is better than software optimized and refined for years to handle heavy loads. I am not joking - even those who understand that something is amiss, find it hard to change their beliefs. Tomorrow even Google will have hard time to sell these people something that will require them to think harder in order to achieve more - all because of beliefs they grew in a software not designed for such use (Yes you can cure the deficiencies of Node, but it will hardly deserve to continue be called node after that, the nature of the coding one will need to employ will change ... well anything can be improved one way or another, but if it remains what it is in the end is a completely different question). It is a good thing to promote your stuff, but a company like Google builds new things all the time, it needs to put effort into preparing people to grasp them, instead of making them love current fashion for all the wrong reasons. There are serious things you can do with Node, but you cannot build heavy load handling network servers (including WEB) without changing the simplistic approach that makes people like it. It is still a nice tool for many of these tasks, but it is no longer use like the Node the young people love. So, why not help them see the truth? I am often asked to review for their lack of performance capabilities projects built by enthusiasts and every time I had to explain to managers and startups how public talk and technology are different things.

Basically PR talk hurts technology and its community in the long run, even if it wins supporters in the short term. Unfortunately Google is not even the worst case - they are just too passive in that respect, letting the fans build an illusion. There are others who actively use any opportunity that will win people on their side, regardless of the false expectations this will create. I see a growing number of ruined projects by managers who listen to the most inexperienced programmers more than to the ones who put current fads under critical consideration. Projects are getting ruined and often repeatedly by managers who believe following the PR is more beneficial than deep technology understanding that may (even potentially) put them in doubt. A few bootstrap styles that make a demo look nice would way too often make managers waste millions on stuff that will eventually fail the clients and they (the managers) most often will continue to believe it is not the wrong technological decisions, but some wrong implementation of agile scrum (for example). So, being realistic and taking care for your followers and especially the young ones, is not a waste of time - we all are going to pay the price for the effects of these illusions and companies who deliver software tools are not safe either. Being truthful and stopping young programmers from believing rubbish may make some of them unhappy, but will win you a status of completely dependable source of technology in the long run. People can forget and ignore the negatives from misplaced beliefs for a long time, but this also has a limit and if it is reached it is very hard to bring the trust back.

Comments