Why is the new design of Gmail so slow?

    As you know, in 2018, Google conducted the largest interface redesign of its email service Gmail. As usual, far from everyone turned out to be satisfied with it - and this time there are quite objective reasons for dissatisfaction with the service. Why did downloading Gmail take a lot of time, and actions like deleting or archiving a conversation could take 4-6 seconds?

    A couple of days ago, a user of Hacker News asked a similar question - and he received a response from an anonymous Google employee, who had a glimpse of the development culture inside the company and his colleagues.

    According to him, all this is happening due to the fact that Google does not provide for any penalties for such “blunders”.

    Within the walls of the company they actively promote launches (launch) - public releases of something. And the fact that products can contain only half of the necessary features does not work, work only from Chrome and so on - it does not bother anyone, because their creators are not in danger. This is the norm.

    The meaning of such actions is only one thing - in promotion, because without major launches it will not be possible to go beyond a certain level. So we end up with hundreds of unnecessary chat applications, endless redesigns and restarts — otherwise individuals will not be able to get promoted.

    When the company's management tried to solve the problem by releasing an internal document that instead of “launches” (launches), it motivates to achieve successful “landings” ( landings , successful launches) - all that the staff changed in their lives was how they performed s / launch / landing / g in its performance review.

    Take, for example, the messenger Allo. It took two years to develop it, after which the company decided to suspend development and freeze the project. As it turns out, the people responsible for the messenger did not suffer at the same time - on the contrary, some of them even got promoted.

    Alas, but apparently, the pressing problems of users of the company today are not too interested in:
    Do you know how many bugs you need to fix in order to get a promotion? Infinitely many. No matter how many bugs you fix - it will never bring you enough "contribution" to increase, never. But it is enough to launch just one redesign - even if it is practically useless - and the increase is in your pocket.

    Naturally, within the walls of the company itself, there are people who warn about the possibility of such a thing and complain that they put performance bugs in the trackers - only this is ignored; Most of the workers eventually give up and stop writing about bugs, because the typical answer to them is “you are not our target audience.”

    And we all know about these problems! We all! Some quit when it comes to them; others are just starting to “optimize” upward - instead of optimizing in the direction of what is good for the user or for the company.

    The developer is not alone in his thoughts. Graham Wheeler shared a story from his life in Google , confirming his position.
    Once in Google I got a negative performance review. I decided that the best way to spend my time would be to refactor the code that I got in order to bring the test coverage from 0% to 80%, fixing quite a few bugs along the way. In the end, I received a shit review for performance review, and the author of the original govnokoda is a promotion.

    Stories about the problems of managing development in the walls of Google appear on the Web regularly . The reaction of users is also not long in coming. Business customers using Google Apps are switching to FastMail , the basic principle of which is email only and nothing superfluous.

    Something like this we get you and things like the new Gmail. Which, on the one hand, acquired a redesign in the spirit of Material Design, offline mode and many other minor improvements that carry it from Google Inbox, which will order to live a long time next year. On the other hand, for full download, it performs 358 requests and extorts 6.3MB. For comparison, the “ancient” HTML View mode in Gmail is just 14 requests and 25.3KB, which allowed it to load in 2 seconds.

    Of course, this practice applies not only to Google, but also to many other large companies. We observe the well-known principle “You get what you measure” in action.

    A similar story was told by developer Steve , who worked at Apple on MacOS X Snow Leopard. Steve mostly dealt with the fact that he fixed bugs in all the main frameworks of the operating system - and as a result of the release he was denied promotion due to the fact that his presence "was not critically important in any of the projects."

    The irony here is that this version of the OS, according to the idea of ​​the company's management, was to be a release in which everything was aimed at improving the stability and performance of the system. However, while some were expected to work on stability, others actively “pushed through” new features like the garbage collector for Objective-C into the release, which delayed the work of the others and made XCode unusable for several months.

    But the work on the bugs was not in vain for ordinary users, who remembered the excellent performance of Snow Leopard and the Lion that followed it - unlike Chrome, which only during the writing of this post managed to hang up a couple of times and cause a “crash” tab with a draft.

    Also popular now: