×
top 200 commentsshow 500

[–]enkideridu[S] 553 points554 points  (153 children)

This organization structure, combined with the global-ish nature of JavaScript in the browser, has made us build the desktop client UI out of many small, self-contained web apps called Spotlets. They all run inside Chromium Embedded Framework, each app living within their own little iframe, which gives squads the ability to work with whatever frameworks they need, without the need to coordinate tooling and dependencies with other squads. While this approach has the disadvantage that we have many duplicate instances of different versions of libraries, increasing the size of the app, but it offers the massive advantage that introducing a library is a discussion between a few people instead of decision that involves ~100 people and their various needs. Not only would such a big discussion extremely time-consuming and hard, it would also force us to use a least-common-denominator approach to picking libraries, instead of picking the ones specifically tailored to the problem domain of each squad.

This frame model is also corroborated in Spotify's Spotify Squad framework — Part I under "Decoupled Releases"

I imagine that the natural inclination of a company towards scaling is to standardize everything

I'd be very curious to hear what discussions brought about this seemingly insane/insanely brilliant solution. Does anyone else do this? Does Spotify still do this and do they regret this?

[–]PeterMcBeater 375 points376 points  (43 children)

I work at a place that does this. We came at it from having a bunch of big legacy systems we don't have the desire or manpower to modernize

But we want to use cool new frameworks and tools.

What to do? Build new features with the cool new stuff and iframe them in next to the old legacy screens you don't want to touch.

As long as you follow a unified visual style guide and allow your authentication solution to work on whatever. It's almost seamless to the user

[–]NotARealDeveloper 140 points141 points  (32 children)

We do this as well. 10years old jquery stuff next to react typescript redux.

[–]RevolutionaryWar0 47 points48 points  (30 children)

I have a question about jQuery, since it's yet another occasion it's mentioned as some sort of rusty old obsolete tool. I'm currently using it at work for developing new interfaces. My understanding is that it doesn't compare to MVC frameworks like React/Angular/Vue, which are full-features industrial tools to build client-side apps (which I don't need because my interfaces are simpler than that); it doesn't compare either with TypeScript/CoffeeScript/etc, which are languages that compiles to JavaScript. It compares only to JavaScript itself in its ability to manipulate the DOM, adding convenient functions that are less verbose than the native DOM API.

Is the argument against jQuery not manipulating the DOM at all with new tools (in this case I'm interested to hear about that), or something else?

[–]beejamin 67 points68 points  (0 children)

You’re largely right with your first comparison: jQuery isn’t an application framework, it’s a utility library. I think a lot of the criticism against it come down to two things:

  • it’s not really needed any more, or at least, not nearly as much. When jQuery was developed, browsers were a complete mish-mash, and a lot of what it did was normalising APIs and patching/polyfilling for missing support and bugs. The landscape has improved a lot, and the DOM APIs are much more consistent, even if they’re more verbose than the jQuery equivalents.

  • People need application frameworks these days. If you’re working on any sort of decently complex front end stuff, you end up wanting state-management, componentisation, etc. you either end up writing your own ad-hoc version, or using a framework that does it well.

I still find myself using jQuery in cases where I just need a bit of polish, but not anything like an “app” (but I am an old fart).

[–]psaux_grep 22 points23 points  (9 children)

Lots of good comments, but I notice a lot of people fall into the trap of thinking “I’m not doing anything fancy, I’ll just use jQuery instead”.

Problem is that whatever starts out as nothing fancy soon becomes more complex due to scope creep or underestimating the complexity of the DOM-state you need to manage. I often feel that most of the jQuery code I’ve written is just managing DOM-state. And it’s fine, if all you want to do is filter a pre-rendered list based on a couple of buttons and an input-field. Suddenly though you want to update that list in real-time based on websockets or periodic fetching, or something different.

React and Vue can be really lightweight, you don’t need the whole kitchen sink, and it manages the DOM for you - eg. you get to write the code that adds business value. I’ve written both simple and complex stuff in jQuery, and after trying react a few years back I never looked back. Then I was handed some legacy XSLT stylesheet where they wanted to add some simple search functionality to a pre-rendered list, but jeez, the scope creep. We went from maybe 20 lines of jQuery to around 120. I don’t think a tiny React or Vue app would have been shorter, but it would have been more manageable. Debugging would make sense, and implementation time would have been at least half. There’s something to be said for making the job easier for the next guy as well. With jQuery it’s just selectors and magic, you need to understand how it affects the DOM as well. In React and Vue you make tiny components that are easy to reason about in isolation, and as long as you don’t make a mess of it it’s easy to reason about it when it scales too.

Angular 4 is a lot like React, but it tacks a lot of extra stuff on that you don’t need for simple applications and makes it harder to get into. For full blown apps you get most of what you need (making a React stack from scratch is often very time consuming and wasteful with lots of refactoring and changing libraries that didn’t do enough or too much - at least if it’s your first full blown react project) and the benefit of writing it in typescript too.

[–]ours 9 points10 points  (2 children)

Jquery results in mostly event handling and procedural code. The more advanced frameworks, if used properly end up more declarative with some event handling. That's much easier to write, read and understand.

[–]anedisi 7 points8 points  (1 child)

that is not really true, if you have some small part of the page that needs to be dynamic then jquery or pure js is all you need, submit a form without reload or something like that. especialy if you have jquery all ready loaded because of the fancy datepicker or validation.

if you get to the point where you are getting live events from ws, thats not the scope of simple project.

and with pure js or jquey solution you dont have the problem of that the whole ecosystem changed in couple of months, because the api is stable and will just work.

[–]psaux_grep 5 points6 points  (0 children)

Obviously, and it’s not counter to what I wrote in my post. Problem is - like your form example; you start out with a simple form. Then you start adding form validation. Then you want to have dynamic feedback from the backend. You suddenly end up with a lot of state that you’re writing procedures for handling, and possibly spending an unreasonable amount of time debugging. Specially on complex pages where you are loading other scripts or small web apps. Suddenly your tailored jQuery grabs an unexpected element because $(‘form’) was no longer unique (bad practice, yada, yada, yada - still happens though).

I’m not suggesting you throw the baby out with the bath water, but a tiny React or Vue powered view isn’t necessarily more complex to maintain than updating your jQuery library. You don’t need to add websockets, and lots of other fancy stuff, just the basic foundations will bring you a long way. It’s not going to change in a couple of months anyway.

[–]Bruin116 55 points56 points  (6 children)

My topical understanding is that ES6 now natively supports nearly everything jQuery used to fill in for, making it more or less obsolete.

[–]Chii 20 points21 points  (1 child)

I don't think ES6 has native support for jQuery live events, and there are some convenient jQuery selectors that aren't supported (like $blah.is(": selected") ) in the standard queryselector API.

But yes, majority of em are, and porting away from jQuery is doable.

[–]fatgirlstakingdumps 22 points23 points  (3 children)

ES6 doesn't work on older browsers, but yes - you do make a good point

[–]RuthBaderBelieveIt 14 points15 points  (0 children)

ES6 can be transpiled to work in older browsers though.

[–]Blueberryroid 26 points27 points  (0 children)

Babel.

[–]Genchou 16 points17 points  (1 child)

jQuery is actually quite fine and usable for small to medium projects. It's just that it's easy to delve into a mess with it when you add a lot of features/DOM manipulations, things that you can control with more ease when you use React/Angular/Vue.

I think that a lot of the appeal with those frameworks also comes with the close relation they have with the modern Javascript specifications (ES6 for example) and supersets (Coffeescript, Typescript, etc.). I know a lot of frontend devs who discovered this shiny stuff through learning React or Angular, while associating jQuery with "legacy" JS, hence seeing it as old and unwieldy, even bad.

I can't speak about performances though, I never looked into that.

[–]ours 2 points3 points  (0 children)

A full front-end framework may be faster for more complex UIs. Like if you have complex elements, with jquery it may be preferable to get the whole element from the server. With a richer framework, you would just touch the data and the framework takes care of calculating and applying the differences to the DOM. These changes may be more granular and therefore lighter than one would like to do in jquery.

[–]eventully 4 points5 points  (0 children)

I'm old enough to remember when building websites with specific frames was the "correct" way to do things.

The older I get, the more I realized huge parts of "modern" development come down to "what got popular at the moment".

[–]MadDoctor5813 63 points64 points  (4 children)

Sounds a bit like containerized shipping.

[–]enkideridu[S] 50 points51 points  (0 children)

Huh, that made me think, it kind of does sound like Docker in app form

[–][deleted]  (4 children)

[deleted]

    [–]rich97 51 points52 points  (1 child)

    > If your connection isn't great the start time is awful

    But this isn't an issue for spottily as they are bundled with the application itself.

    [–]Shookfr 12 points13 points  (0 children)

    I'm surprised Spotify would have duplicate instances of different libraries though; it's super easy to hoist them up and share them.

    I think they do it once a feature is stable.

    [–]shadowX015 75 points76 points  (15 children)

    The biggest downside I can think of is that if Spotify decides to cut staff or even eliminate entire squads, it might come about that people who currently only work on one feature could suddenly become responsible for maintaining many different features, all using different frameworks and libraries.

    [–]Phlosioneer 65 points66 points  (10 children)

    With fragmentation comes speed, but also maintenance. However, they likely keep things small enough that they can just scrap an iframe if they can't fix it / update it.

    [–]MCBeathoven 95 points96 points  (7 children)

    What speed? Spotify never ever implements any new features.

    [–]Notorious4CHAN 47 points48 points  (1 child)

    That might just be the most damning commentary of all on this technique...

    [–]mikehaggard 15 points16 points  (3 children)

    That's EXACTLY what happens. This practice is not new, I've seen it before. It can also naturally happens when a company takes over other companies and their products are migrated and integrated into the main company's behemoth.

    I can tell you, having 3 different versions of SQLServer, a few MySQL instances, the odd PostGres, an old JBoss server running EJB beans, a Tomcat server running some Spring version, a backend processing running a combination of Perl and PHP (I'm seriously not making this up), an admin UI build with Ruby on Rails, another part of the admin UI build with Django, user pages build with GWT, linking to pages build using JSF (with some pages using IceFaces, some RichFaces, some PrimeFaces), then some other processing service build with C++ (which can only compile on windows, so windows is needed for that server, but only windows 2000 works) and then some portal server running Liferay with some version of JSF again.

    And occasionally, you have to create work flows that touch half or more of these things, so you have to know all these things, which of course you don't.

    And the people responsible for half of it left, a long time ago. So what do you do? Try to learn some ancient variant of C++ that can only be tested on a Windows 2000 servers, which nobody has provisioned for you? Or do you paper over it?

    It's an ABSOLUTE mess! Its beyond words, and in 90% of the cases nothing is ever about "the best tool for the job". It's just about what some guy just read about that morning before coming into the office.

    I'm a very big proponent of having everything (that you develop yourself) in the same language/framework, and only use something else when it's proven beyond reasonable doubt that it's the best tool for a given job.

    [–][deleted] 17 points18 points  (2 children)

    We do this where I work, though I wasn't around for any of those decisions. We're in the process of building standard libraries/tooling/libraries that basically pin versions so we're all at least mostly on the same stack, but we still don't have a great plan to migrate everything out of the iframe model.

    The ability for individual orgs to develop using the best tools for the job is nice, the cost of actually deploying/maintaining is lower than you'd think since each app sorta freezes in its own environment. The true cost is that it's really hard to synchronize security updates, changes to services that they all use, and consistent frontend UX/style.

    [–]Mausbiber 35 points36 points  (0 children)

    The pattern is called "Self Contained Systems", or SCS.

    Mainly non-technology business are using it as it allows company wide reuse of business functionality without requiring a huge amount of governance.

    https://scs-architecture.org

    [–]howmanyusersnames 152 points153 points  (41 children)

    It has its perks, but ultimately it's a terrible design pattern and will be probably be phased out within the next 2-3 years at Spotify's current growth. It's a solution for people who can't agree on things, and if you have a bunch of people who can't agree, you will inevitably crumble. The irony of the pattern is its the antithesis of scaling successfully.

    [–]dead10ck 81 points82 points  (28 children)

    This was exactly my thought. Choosing to let chaos reign simply because nobody wants to talk to each other sounds like a recipe for an inevitable disastrous mess. If it hasn't already happened, as people leave the company, nobody will have the knowledge or resources to maintain any of the components they inherit. Development will become excruciatingly slow because every component will work with totally different tools, which the developer will have to learn, only to move onto the next component, where they have to switch gears again. Suddenly you're in a cycle where by the time you work on something again, everything you need to know has fallen out of your head and you have to relearn it. I have lived this and it is hell.

    This approach sounds incredibly shortsighted to me; either you pay now by actually talking with one another, or you pay later with an unmaintainable mess.

    [–]Decker108 66 points67 points  (17 children)

    Spotify uses an organizational model based on autonomous teams. Enabling teams to not have to speak which each other in such an organization is a feature, not a bug.

    I'll leave it as an exercise for the reader to decide whether this is a good thing or not.

    [–]Mad_Ludvig 43 points44 points  (1 child)

    To paraphrase, "Companies can only build products that mirror their organizational structure."

    [–]sourcecodesurgeon 55 points56 points  (8 children)

    The irony of the pattern is its the antithesis of scaling successfully.

    The pattern is the same core concept as microservices.

    [–]hyperforce 15 points16 points  (1 child)

    ultimately it's a terrible design pattern and will be probably be phased out within the next 2-3 years at Spotify's current growth

    Do you have any data to back this up or are you just arm-chair quarterbacking?

    [–]yojimbo_beta 19 points20 points  (2 children)

    The Guardian wasn't quite this radical, but took a similar approach: separate front-end bundles from different teams, strong error boundaries so that one team's fuckup could never kill another team's software. This meant teams could release independently without too much fuss.

    We did have some shared responsibilities though: everyone had a common interest in CPU and network resources, so the front-end 'guild' as a whole pushed for small JS bundles and fast DOM manipulation.

    What kills me though is how many posters in this thread are dissing the model just based on some transitive association with an extreme engineering practice. Haven't they ever heard of microservices? Or maybe that's just a "fad" too, they announce, as they sit down to do the monthly build of their statically linked SNOBOL program.

    [–]kevindqc 6 points7 points  (1 child)

    Haven't they ever heard of microservices?

    Probably, and hopefully they are not using that unless they work at the few companies big enough that it makes sense

    [–]Denfi 27 points28 points  (0 children)

    Spotlets

    🤢🤢🤢

    [–]morgan_lowtech 41 points42 points  (8 children)

    That's a lot of words to say, "we don't really know what we're doing, but we need to ship code."

    [–][deleted] 5 points6 points  (0 children)

    I did this a lot when doing customization's to Dynamics CRM forms. While not using chromium I could use the same authentication mechanism, style it and interface with the rest of the system to the point that user's wouldn't really know it was a customization at all.

    [–]ggtsu_00 5 points6 points  (0 children)

    Conway's Law to the extreme.

    [–]sim642 244 points245 points  (29 children)

    Why put one React into your oversized Electron app when you can put 5 Reacts, 3 Angulars, 3 Vues and a jQuery because every team has their own framework of choice?

    [–][deleted] 69 points70 points  (8 children)

    Not to mention the fact that 100+ people banging out JS framework code 8 hours a day seems excessive to me.

    [–][deleted] 40 points41 points  (5 children)

    Especially considering that we have better audio players with way smaller developer teams and budget...

    [–]enkideridu[S] 44 points45 points  (19 children)

    That would result result in an extra 815kb added to the download size (or 1/4 the size of an average mp3). So seriously, if it means you ship more features faster, why not?

    [–]sumguysr 48 points49 points  (7 children)

    I'm curious how great the performance cost is of shuttling those redundant assets around in memory is.

    [–]wavy_lines 10 points11 points  (2 children)

    According to a highly upvoted comment, they haven't added any new features in ages, instead they dropped features, it seems.

    [–]FINDarkside 6 points7 points  (0 children)

    Well, they did change "my songs" to "my favourites" and replaced the + icon with heart. Not sure if it was just some bamboozle or what, but it got reverted in couple of days.

    [–]601error 29 points30 points  (5 children)

    From an elegance perspective, it's just gross.

    [–]leupboat420smkeit 48 points49 points  (3 children)

    This is web development. Elegance was taken out back and shot a time ago. I'm pretty sure the Xbox controller drivers included with Electron is larger than there frameworks.

    [–]shponglespore 6 points7 points  (0 children)

    Some of us are still hoping to bring sexy back.

    [–]anttirt[🍰] 581 points582 points  (83 children)

    Is this why I can't recall Spotify getting any new features, well, ever? I literally cannot remember a single new feature that they would've implemented over like eight years of using the desktop app.

    Local file support continues to be completely abysmal despite the fact that Spotify is never going to have a lot of indie music that only exists on bandcamp instead of a "real" label, and naturally will never have bootleg live recordings (or bundled indie game soundtracks, or self-printed CDs released at indie art festivals etc...)

    Local file FLAC support was requested six years ago and closed as "too low priority."

    I just want to know what the fuck are all these super agile masturbation squads actually doing at Spotify?

    [–][deleted]  (10 children)

    [deleted]

      [–]sfade 75 points76 points  (5 children)

      Ya, and they removed the running playlists that tracked your pace and calibrated the music to match. Total joke. Why would they remove such a great feature?

      Also, you can’t reset Discover Weekly. I listened to some ocean sounds to fall asleep, and then for the next 2-3 months it ONLY recommended new ocean sounds I might like.

      [–]falconfetus8 26 points27 points  (3 children)

      MPJ(the author of this post) has a YouTube channel called FunFunFunction. In one of his videos, he talks about a phase he went through where he tried to make the code more maintainable by killing features. He says he later regrets this because killing features takes lots of work and pisses off users.

      You should check his channel out, it's really good.

      [–]bobindashadows 30 points31 points  (2 children)

      So at Spotify, code maintenance was a good enough reason to kill features? One engineer doing code cleanups had the authority to change the product itself to clean up code?

      What even is this

      [–]falconfetus8 3 points4 points  (0 children)

      Nah, he had to convince his colleagues that it was worth it first. Which I assume got harder and harder.

      [–]NVRLand 57 points58 points  (5 children)

      > I just want to know what the fuck are all these super agile masturbation squads actually doing at Spotify?

      EVERYONE at Spotify are working towards the same goal: making more freemium users go premium. That's the only thing that matters to them and it drives all decisions. "Will Feature A turn more freemium users into premium users?".

      I've been to the Spotify HQ a couple of times and talked to developers and one told me that they did A/B test lossless streaming for some users but couldn't see that they listened to more music than users without and they didn't buy premium to a higher degree either. So they just scrapped that.

      [–]dedorian 30 points31 points  (3 children)

      To be honest, that's the decision I'd make at the business level, too. Higher bandwidth product with negligible impact? Pass.

      [–][deleted] 8 points9 points  (0 children)

      Well, if it cost them more to provide it, that’s an understandable decision, no?

      [–][deleted] 93 points94 points  (22 children)

      It seems like once the last major-ish desktop redesign got rolled out in 2016 they just dropped desktop as any kind of priority, they've probably majorly shifted focus to mobile because it's more profitable and left desktop users in the dirt.

      [–]CartmansEvilTwin 102 points103 points  (10 children)

      Even the mobile version is stagnant. They should rather focus on improving they're recommendations, how is it ok that a radio (or whatever it's called in English) only repeats something like 50 songs. I'm basically circle jerking myself because Spotify thinks I'm only interested in a few very small niches.

      [–]goorek 16 points17 points  (3 children)

      Spotify has easly the best recommendations of any other platforms, like in Daily mixes or Discover Weekly.

      [–]sumguysr 19 points20 points  (0 children)

      I find both last.fm and Pandora recommendations to be much better. It wouldn't be so bad if Spotify still allowed apps

      [–]oblio- 9 points10 points  (0 children)

      I feel that's been the case for most major apps. If there is a rewrite, it's to facilitate code reuse for the mobile bits, not to add desktop features.

      There's going to be a desktop "feature freeze" for a few more years until the mobile market is saturated. Especially since the mobile market is inherently lower value than the desktop, except for games and a few key subscription-based apps.

      [–]knightskull 16 points17 points  (5 children)

      I’d say that’s a bingo!

      [–]socialismnotevenonce 54 points55 points  (1 child)

      Local file FLAC support was requested six years ago and closed as "too low priority."

      It's my experience that Spotify gives 0 fucks about anything "local."

      [–][deleted]  (8 children)

      [deleted]

        [–]helm 69 points70 points  (6 children)

        Yeah, OP is confusing "Spotify doesn't do anything about these three very specific issues I care about" with "Spotify doesn't do anything at all for anyone".

        [–]anttirt[🍰] 57 points58 points  (2 children)

        Seriously though, what have they actually created in the past eight years with all of these independent frontend squads? Undoubtedly there's been a lot of backend work on general infrastructure and recommendation algorithms and such but what about the frontend?

        [–]thebiglebrewski 33 points34 points  (0 children)

        I've enjoyed Your daily mix, release radar, etc.

        [–]FuzzyYellowBallz 19 points20 points  (0 children)

        I think you've misunderstood what he's criticizing. His tangent on FLAC support doesn't change the fact that they haven't created anything new in years.
        Just from a quality-of-product standpoint, the Spotify model is not one I'd go out of my way to emulate.

        [–]CaptainBland 15 points16 points  (0 children)

        I'm going to go right ahead and guess there are *tons* of integrations the user never actually sees and probably just gather all kinds of obscure analytics.

        [–]SirSassyCat 24 points25 points  (1 child)

        Theyre spending all their time supporting the clusterfuck architecture its running on.

        [–]beowolfey 8 points9 points  (0 children)

        While I totally agree about the spirit of your post, I wanted to add that it is actually remarkably easy to get your music on Spotify thanks to indie distro collectives. I think I paid something like $20-30/year to get my old band on there for fun and it took about 5 minutes of effort. If an indie band wants to be on Spotify it's totally possible and I think I've been seeing it more and more.

        Doesn't change the fact that I would freakin LOVE better local tune support though too

        [–]fear_the_future 8 points9 points  (0 children)

        They are probably all working on hidden crypto miners that work in the background of the electron app. At least that would explain why it's so fucking slow

        [–]takaci 10 points11 points  (1 child)

        despite the fact that Spotify is never going to have a lot of indie music that only exists on bandcamp instead of a "real" label

        This is the most depressing part for me. There is so much music I want to listen to but I rely on the convenience of Spotify far too much. I end up actually listening to much less music due to that fact

        [–]ethermage 6 points7 points  (0 children)

        This is the reason I refuse to start using Spotify. I'd get too attached to their ecosystem and miss out on stuff not on it. It might be only around 10% of all I hear, but it's precious 10%.

        [–]Deadhookersandblow 25 points26 points  (12 children)

        How the fuck can implementing this feature be that complex? Is it because it’s electron?

        [–]anttirt[🍰] 57 points58 points  (7 children)

        Wish I knew. Core playback and local file support in Spotify is implemented in C++, at least based on the OP article. libflac is BSD licensed and has a very simple API. It shouldn't take an experienced developer more than a day or two to integrate.

        Edit: Unless their native code base is some kind of Lovecraftian hellscape that consumes the sanity of anyone who dares to gaze upon it. In that case I might understand the reluctance to touch it, but still, six years...

        [–]LKS 18 points19 points  (1 child)

        They are in the business of streaming music to you, why do you think they have any priority on local file playback, especially if the file format has no quality limitations compared to the product they are trying to stream to you?

        [–]quick_dudley 8 points9 points  (0 children)

        Given what they're saying publicly about their frontend codebase: the scenario in your edit seems kind of probable (and I'm saying that as someone who once resorted to essentially the same thing)

        [–]darksparkone 34 points35 points  (0 children)

        It's not. My bet they just don't mind things that are not their main business.

        [–]stfm 145 points146 points  (20 children)

        WTF isn't this literally Portlets (jsr168) which were a shitty idea even when they were used in 2005?

        [–]boobsbr 155 points156 points  (3 children)

        Reimplementing the wheel in different tech stacks is the new black.

        [–]sim642 8 points9 points  (0 children)

        Only to eventually realize how bad of an idea it was to begin with.

        [–]RBC_SUCKS_BALLS 11 points12 points  (1 child)

        Better infrastructure. No way this works with lower bandwidths

        [–][deleted]  (6 children)

        [deleted]

          [–]rich97 15 points16 points  (4 children)

          It's apparently working for them.

          [–]Tore2Guh 282 points283 points  (27 children)

          This sounds like a technical solution to a management and culture problem.

          I have a hunch the people that are filling the role of PM are called something other than Product Manager and that they are also very unhappy.

          [–]enkideridu[S] 51 points52 points  (14 children)

          I believe the PM role is split into "Product Owner" and "Scrum Master", with each squad having their own

          I'm curious to know if they are happy, and also curious if you could share why you believe they aren't

          [–]Tore2Guh 94 points95 points  (12 children)

          If all they "own" is the content of one iframe, they don't really have a product, and they are competing for resources and mindshare with the other squads in a non-cooperative way with their sense of a common goal undermined by the org chart.

          I would think that the idea of letting each team go commando would be really frustrating for a PM when pulling together a common vision and keeping the team focused on that goal is one of, if not THE major thing good PMs do.

          But what it does allow is for us nerds to chase whatever shiny object we want, which is ultimately kind of childish.

          As sort of an aside, one of the bigger red flags for me was when they said each squad even had their own backend devs. There isn't even a unified team for the backend?

          [–][deleted]  (9 children)

          [deleted]

            [–]BRAILLE_GRAFFITTI 13 points14 points  (4 children)

            This. Also, if there was a unified backend team, that single team would have several hundreds of developers. I agree that this iframe solution is kind of dumb, but splitting up things on a feature level becomes more or less necessary when you grow to a certain size. I wouldn't even know where to begin with a "backend team" that large.

            [–]BRAILLE_GRAFFITTI 2 points3 points  (0 children)

            One key thing about self-organizing teams is that they get to choose how they organize themselves. Some teams have agile coaches, but far from all of them. Pretty much all teams have product owners, but their roles vary from team to team. So it all depends on which team you ask, which is probably the case for most large companies.

            [–]Kwerti 20 points21 points  (9 children)

            They actually talk about it in a 2 part video series.

            It's really cool and looks like a fantastic place to work if you work well in AGILE teams.

            https://vimeo.com/85490944

            https://vimeo.com/94950270

            [–]RetardedSquirrel 13 points14 points  (1 child)

            I know quite a few people who work there (in Stockholm). It's okay but by no means great. Like many other hyped tech companies the actual stuff most people do doesn't live up to the hype, and because its "hip" (it's actually quite enterprisy at this point) it comes with worse pay, benefits and job security.

            [–][deleted] 9 points10 points  (0 children)

            Are you saying the developers have Stockholm Syndrome?

            [–]CSMastermind 12 points13 points  (1 child)

            I have a hunch the people that are filling the role of PM are called something other than Product Manager and that they are also very unhappy.

            He's right about that part though

            [–]PC__LOAD__LETTER 11 points12 points  (1 child)

            Why did you capitalize Agile?

            [–]DrDuPont 8 points9 points  (0 children)

            Agility Grants Interoperability and Lean Expertise

            [–]waveform 184 points185 points  (47 children)

            which gives squads the ability

            Squads. Because teams are so yesterday.

            The "kind of insane" bit for me is how front-end development of a single app can involve " ~100 people".

            [–]helpfuldan 122 points123 points  (9 children)

            Really? I thought it was kind of insane the facebook ios app had 18,000 classes.

            _FBGraphQLConnectionStorePersistentPageLoaderOperationDelegate-Protocol.h _FBReactionAcornSportsContentSettingsSetShouldNotPushNotificationsMutationCall.h FBBoostedComponentCreateInputDataCreativeObjectStorySpecLinkDataCallToActionValue.h FBEventUpdateNotificationSubscriptionLevelMutationOptimisticPayloadFactoryProtocol-Protocol.h

            Ever since learning that, it's hard to reach the insane level, and 100+ people on the front-end, seems perfectly sane compared to facebook.

            [–]sozesghost 83 points84 points  (7 children)

            It's generated code.

            [–]atticmanatee 66 points67 points  (1 child)

            Someone still had to model it

            [–]killerstorm 46 points47 points  (4 children)

            It's still insane.

            [–]sozesghost 10 points11 points  (3 children)

            It's insane and I'm not arguing for it, just pointing out that it's considerably less insane than people actually typing all of that.

            [–]LightCodeBulbs 5 points6 points  (2 children)

            Facebook needs those long file names because they use those names as unique identifiers in their monorepo system. It seems nuts but it has a lot of really sound reasons to exist, unlike this spotify monstrosity. Can't believe anyone thought that was a good idea. It's sad that a startup can turn into an agile business manager driven hellhole so quickly

            [–]TyRoXx 14 points15 points  (0 children)

            Most of the 100 probably only make tiny additions to the application if they dare to touch it at all. The ten or so core contributors are probably distributed across different "squads" and don't communicate well with each other. The rest follows Conway's law.

            [–]Atlos 60 points61 points  (6 children)

            It's because software is obsessed with A/B testing every little thing. Each team wants to be autonomous so they can experiment with their own incremental changes, and in turn be able to say "Look, we increased playlist engagement by 2%!". I call it resume-driven development. The product sucks overall, but we have metrics!

            [–]epicwisdom 31 points32 points  (5 children)

            google.com and the results page both used to be very barebones. They still are (to a much lesser extent), but you can bet there's hundreds, if not thousands, of people working on just the frontend of those two pages.

            [–]mattj1 20 points21 points  (3 children)

            User experience, market research, lots of other roles to get that page right. But how many are coding the page itself? Maybe all the developers of all the libraries in the dependencies count too? How do you get to thousands?

            [–]perestroika12 74 points75 points  (6 children)

            Surely there's an easier way to containerize js. This seems insane because it is. Such a heavy handed and crippling solution.

            [–][deleted] 10 points11 points  (3 children)

            Surely there's an easier way to containerize js.

            Probably not without doing your own custom CEF branch which we'd all probably view as more insane.

            [–]perestroika12 3 points4 points  (2 children)

            It also seems like this is a technological solution for a business problem. Lack of communication, competing standards, poor standardization, etc. The correct solution is to just get all the engineering teams on the same page.

            [–]celerym 100 points101 points  (7 children)

            This is gonna be an unpopular opinion here, but companies like Spotify do not need the amount of programming staff they do to push out the product they do. It is as if companies in some sort of weird instinct to justify their own success hire way more people than they need to, and create complexity where it isn't necessary.

            [–]sim642 41 points42 points  (1 child)

            But how else can they show off their "revolutionary" organization structure that's based on the notorious <iframe>.

            [–]WJ90 15 points16 points  (0 children)

            Don’t tempt them! The next thing you know they will “revolutionize” music streaming by providing each song with a Spotlet that loads the music using an audio tag!

            They could even turn it into a social network that lets you create flashy pages!

            [–][deleted] 17 points18 points  (0 children)

            Actually this sounds like most of the places I’ve worked at.

            [–]NetSage 12 points13 points  (0 children)

            Indeed it's the business mentality of constantly growing. Which is great but you have to take a more horizontal approach(as in expanding what you do not the amount of people you have) at some point. Unless you're going to go and deep dive your niche (e.g. a better lossless format somehow to make it more viable for streaming).

            [–]maikeru 16 points17 points  (1 child)

            Just want to point out that the original Quora post appears to be from 2015 with some updates last year so it isn’t necessarily representative of how things are now. A lot of comments assume that this is the current state of things.

            [–]Pareilun 702 points703 points  (215 children)

            Oh cool, so they're decreasing performance to make things easier for 100 people instead of their 70 million paying subscribers.

            [–]rpunkfu 456 points457 points  (4 children)

            But this way Team Volume Bar and Team Play Button can deploy autonomously!

            [–]mrnuknuk 210 points211 points  (3 children)

            You mean squad!

            [–]thngzys 52 points53 points  (1 child)

            Exactly. How else do you achieve squad goals without a squad.

            [–][deleted] 2 points3 points  (0 children)

            You make them fam

            [–][deleted] 265 points266 points  (52 children)

            Actually if this helped them deliver more functionality I'd be okay. But it's not the case, their desktop app is basically stagnated, lacking obvious features, with dumb restrictions and somewhat buggy, especially when it comes to network connectivity (which I supposed shouldn't be negatively affected by this workflow, should it?)

            [–]babypuncher_ 7 points8 points  (3 children)

            And people wonder why I stick to foobar2000 instead of hopping on the Spotify bandwagon.

            A new product needs to offer a better experience than what I already have. From my experience, Spotify feels like a huge step backwards in the areas that matter to me.

            [–]Phlosioneer 210 points211 points  (82 children)

            Well... isn't that the whole point of electron apps too? "Why be efficient when we can just run our app as its own web browser!"

            People wonder why their computers get slower over time. They don't - everything is just built less and less efficiently. It's so sad.

            [–]socialismnotevenonce 45 points46 points  (37 children)

            They don't - everything is just built less and less efficiently. It's so sad.

            You have no idea how many times I heard the phrase "but memory is cheap" in college, from professors.

            [–]Slak44 70 points71 points  (31 children)

            memory is cheap

            It is true for many things.

            1. Some script that runs for 5 seconds? It doesn't matter if it allocates 1MB or 500MB of RAM for such a short time, so memory is cheap.
            2. You have a CPU-bound task that can be improved by using more RAM? Memory is cheaper than CPU time.
            3. Running 200 tabs of chrome with 20 extensions makes you more productive? The 3GB of RAM used is irrelevant if you work better when using it, so memory is cheap.

            It isn't always true of course. Stuff with daemon-like behaviour that tends to always run in the background should be more careful with memory usage, for example.

            [–]ggtsu_00 9 points10 points  (2 children)

            "Unused RAM is wasted RAM"

            I hate this mentality so much. It assumes people don't use more than one program on a multi-tasking computer. Therefore every piece of software wants to use up as much ram as available.

            [–]loup-vaillant 30 points31 points  (9 children)

            It is false for many other things. We may have Gigabytes of RAM, but we only have 64KB of L1 cache. Using more memory easily means swapping the cache into the RAM all the time, and in some cases this kills performance.

            [–]Phlosioneer 17 points18 points  (12 children)

            Be careful with singular thinking. This is the trap that my professors often fall into, as well. If you consider a program in a vacuum, then yes, it's cheap. But, unless you are deploying on a server you own, you're sharing resources with between 30 and 200 different processes on your customer's computer (depending on OS and setup). Adjust your expectations by how many other things share the resource. Ram? probably 1/50th should be your target, unless you expect to be the only major thing running (like a fullscreen videogame), then maybe like 1/10th. Disk space? 1/100 is usually about right. CPU cores? There are usually between 4 and 10 programs that need the CPU at any time, so something like 1/8th.

            Average customer has 16GB of ram, 500GB disk space, 4 cores, and it's a normal program (e.g. an IDE)? Aim for about 320MB of ram usage, 5GB disk space, 50% use of one core. Expect it to be the only program (e.g. a fullscreen game)? Aim for about 4GB of ram, 20GB, 100% use of three cores.

            [–]space_fly 26 points27 points  (4 children)

            I don't think 16GB is average. From all the laptops I fixed for acquaintances, 4GB was the most common, rarely 8GB. 8-16GB is common only on developer machines.

            500MB for an app doesn't seem much on a 16GB machine, but on 4GB which is much more common, it's huge. If you think about it, the OS takes about 1-1.5GB, a typical browser around 1.5-2GB, that leaves about 1GB for everything else, like Skype, a music player and other programs that typically run in the background. That is very little room.

            Edit: here is an article about average RAM, estimated around 5GB for 2016.

            [–][deleted] 2 points3 points  (5 children)

            Ram? probably 1/50th should be your target, unless you expect to be the only major thing running (like a fullscreen videogame), then maybe like 1/10th

            ??????

            No game targets 400-800MB of RAM usage, and some IDEs wouldn't even fit in that.

            The idea is sound but your proportions are WAY off

            [–]Phlosioneer 9 points10 points  (1 child)

            Yeah. I'd probably agree that storage-space is pretty cheap; and if you have control over the hardware and/or own the hardware, you can definitely figure out what exactly is your limiting factor and not worry about the rest. But it's really not fair, right, or sustainable to treat customers' hardware like that. And RAM is definitely not cheap.

            Need 100GB on your server? sure, that pales in comparison to your salary costs.

            Need 100GB for your videogame? fuck you, that's 1/5 of my ssd!

            [–][deleted] 54 points55 points  (30 children)

            Difference is Microsoft doesn't charge $10 a month for vscode.

            [–][deleted]  (28 children)

            [deleted]

              [–]socialismnotevenonce 28 points29 points  (6 children)

              There are plenty of very good free IDEs that aren't built on Electron.

              Yeah, like Visual Studio Community.

              [–]oblio- 11 points12 points  (5 children)

              Not cross platform, though :(

              [–][deleted] 7 points8 points  (18 children)

              As an extensible text editor you have notepad++ (lol),, sublime, atom, and VSCode as the only serious options I am aware of.

              Atom and VS code are both awesome, some people swear by sublime, personally VsCode plugins and stability are top notch. It is a great product I use it for everything from quick python scripts to writing meeting notes in markdown.

              [–]oblio- 24 points25 points  (10 children)

              There's also Emacs and Vim, but then you're in your own little weird island in the South Pacific while everyone else on your desktop is in Manhattan.

              [–]SanityInAnarchy 9 points10 points  (5 children)

              Most electron apps are running one JS VM instead of dozens, though. There's a difference between inefficiencies from making things a little more portable and a little more GC-heavy, and inefficiencies because dependency management was too hard!

              [–]Gravitationsfeld 34 points35 points  (6 children)

              Welcome to modern software development.

              [–]Pareilun 28 points29 points  (5 children)

              Been living it for a while. Just aggravated each time someone takes it to another level.

              [–]BinaryRockStar 58 points59 points  (4 children)

              The next version of Spotify is going to install Docker and have each UI component running in its own container as a MongoDB-backed REST microservice. Progress!

              [–]UniverseCity 19 points20 points  (0 children)

              You joke but...

              [–]herder 13 points14 points  (0 children)

              Needs more blockchain.

              [–]HarwellDekatron 52 points53 points  (0 children)

              ROFL, this comment is so real, it hurts.

              [–]Istalriblaka 34 points35 points  (0 children)

              decreasing performance

              More like taking it out back. My computer runs Arma 3 more smoothly than spotify.

              [–]virtyx 70 points71 points  (28 children)

              Making it easier for 100 people to deliver new app features and other value to their 70 million paying customers.

              I mean, I agree that from a technical POV this is an extremely wasteful program design. But outside of open source I've never seen a software project successfully integrate work from hundreds of developers. For a fairly young tech company I can see it being the least terrible way they know of where they can meet their business requirements without constantly breaking their app.

              [–]Paradox 43 points44 points  (4 children)

              I've never seen a software project successfully integrate work from hundreds of developers

              You've never used Google, Facebook, or anything made by Apple or Microsoft?

              [–]SanityInAnarchy 12 points13 points  (3 children)

              I wish I could sit everyone at Spotify down in front of Google's Piper paper and force them to acknowledge that teams actually working together has some advantages.

              [–]Pareilun 24 points25 points  (1 child)

              I get why they do it. It's one of the reasons microservice architecture is becoming more pervasive too. Either way, the outcome is less than ideal.

              [–]hyperforce 18 points19 points  (0 children)

              Either way, the outcome is less than ideal.

              Depends which dimensions you're comparing.

              People always seem to ignore "is an organizational success" rather than "I could code this up in assembly by myself in a weekend in my head".

              [–]occz 40 points41 points  (14 children)

              This statement is applicable for all development short of writing assembly directly. Ease of development matters for literally everyone involved: users get more features faster for less money and developers get to enjoy their work more.

              I'd concede that sometimes performance is undervalued to the point where it starts hurting users but I dont think the spotify app is a case of this problem, atleast when compared to other apps (looking at you, Slack and Postman).

              [–]iindigo 15 points16 points  (3 children)

              The Spotify desktop app runs like a dog. If you click around and explore a few artists, albums, etc its memory use explodes and quickly surpasses 700MB — I’ve seen it top a gig in the past. Remember that this is a streaming music player, not a CAD suite or something. Most competitors’ web based offerings don’t perform nearly this badly... even Apple Music, powered by a webview in iTunes and made by a company that is notoriously bad at web apps, rarely needs more than 250MB - 300MB.

              It’s definitely crossed the threshold of users benefitting from developer convenience and is falling down the other side.

              Can’t wait for Marzipan to launch in next year’s macOS release so I can just run native iOS apps on my Mac and avoid junk like this entirely.

              [–]iindigo 2 points3 points  (0 children)

              The ratio of developer convenience to end user happiness has certainly tipped too far to the left lately. As a developer myself I won’t hesitate to spend time on improving performance because really, at the end of the day, it’s my job. Software is supposed make peoples’ lives easier, and with that goal piling on new bells and whistles only goes so far — eventually you hit diminishing returns and users start wondering why your app is sitting in the background eating a gig of memory and keeping half a core pegged for no good reason. At some point, your app has to move beyond “it works” and begin to work well.

              Software dev isn’t supposed to be easy. It’s not the kind of thing you can throw tens or hundreds of uncoordinated code monkeys at and expect a good result from. Above all, good software takes a ton of time and effort, and no number of engineers can change that.

              [–]190n 39 points40 points  (4 children)

              I encountered this while trying to theme Spotify (I was working on my own script, but then I discovered Oomox). Each spotlet is a .spa file (really just a zip file). Theming works by extracting each one, modifying some css files, and rebundling and reinstalling them all.

              [–]reini_urban 55 points56 points  (1 child)

              There's a name for it. It's called balkanization, usually known as bloat.

              [–]fuckin_ziggurats 33 points34 points  (0 children)

              I'm from the Balkans and I agree that everything that's bad should have a name derived from the name of the region.

              [–]BrokenHS 313 points314 points  (43 children)

              Oh, so that’s why the Spotify desktop app is unusable.

              [–]Gunde 55 points56 points  (3 children)

              Remember when Spotify was a super-snappy ~80k native application single-handedly coded by Ludde? Software is like governments. It'll continue to expand and complexify until it's unanimously despised by everyone.

              [–]redwall_hp 13 points14 points  (0 children)

              Ah, back when Spotify was good. It played music and didn't eat hundreds of megabytes of RAM, and dragging songs felt like a native application instead of being slow and infuriating.

              [–]McRawffles 157 points158 points  (34 children)

              Hmm? Maybe I'm in the minority but I haven't had a ton of issues with it. It's far from perfect (esp on the efficiency side of things), but amongst desktop music apps it performs way above the level of its competition in most aspects.

              [–]Holy_City 147 points148 points  (22 children)

              The binary size and RAM requirements are fairly absurd for what the app does, which at the end of the day is display some text information to the user, provide an endpoint for a UDP stream, and run a decoder. Unless I'm totally off base and they're doing a ton of stuff client side that could be on the server.

              I only use play.spotify.com in Firefox because it provides an equivalent experience, except its faster and it doesn't take any additional disk space.

              The tools used to create the content Spotify streams have around the same binary size (although some can be large), have UI and logic several orders of magnitude more complex, and don't have these issues with dependency hell.

              That said the app does run smooth and it looks gorgeous, and I'm sure there's a lot under the hood to keep that up.

              [–]orangeoliviero 63 points64 points  (2 children)

              The app fucks my computer up like I'm running some high end game. It has no business being that resource intensive.

              [–]sonnytron 24 points25 points  (1 child)

              It's gonna become a benchmark for modern processors soon.

              [–]ciny 4 points5 points  (1 child)

              Don't know about the desktop app but the windows store app doesn't seem to have performance problems.. Currently listening to music - 134MB RAM and 2-4% CPU load.

              [–]mrmekon 17 points18 points  (5 children)

              The binary size and RAM requirements are fairly absurd for what the app does, which at the end of the day is display some text information to the user

              This is why I literally wrote my own miniature Spotify desktop client. I only play on speakers, and keeping the official desktop app idling in the background uses 1+GB of RAM to basically display what track is playing and let me pause sometimes.

              [–]boobsbr 9 points10 points  (1 child)

              display some text information to the user, provide an endpoint for a UDP stream, and run a decoder.

              Didn't Winamp achieve that, like, 20 years ago?

              [–]McRawffles 5 points6 points  (4 children)

              Yeah that's kinda what I was trying to get at, it's not performant but it is smooth and functional. And at the end of the day they, as a company, win out by having a wide variety of functionality, not by being the most performant. Currently their pattern for rapidly developing functionality is to isolate dependencies as much as possible.

              I have no doubt it saves time compared to trying to sync everything up but it does lead to a ton of overhead, which we're seeing.

              [–]Istalriblaka 18 points19 points  (8 children)

              My computer runs Arma 3 at playable levels. (I mean, low graphics and 30 fps, but it's playable.) Every time I switch windows to spotify it takes a solid 5+ seconds to load the window, and when I skip a song there's a 20% chance there will be noticeable lag even if spotify is the only window up.

              It doesn't have a full crash often, but it is terribly inefficient and I would be surprised if none of that is catching and dealing with errors.

              [–]Hepita 6 points7 points  (4 children)

              On Linux it's even worse, the app would crash while resizing the window.

              [–]Magnesus 5 points6 points  (3 children)

              This is really strange. I run it on Ubuntu and it works without any issue. Doesn't even stress the CPU (which I would hate since the fan in my laptop is way too loud). I never even turn it off or reboot (just put to sleep) so the app runs for weeks.

              [–]amunak 5 points6 points  (1 child)

              but amongst desktop music apps it performs way above the level of its competition in most aspects.

              What competition though? I mean sure, many music apps are utter shit. But then we have 15+ year old software (FooBar2000 anyone?) that works flawlessly, is fast, the binary is like 5 megs and the application in memory is not much bigger. And it has a shitton of great features that most other music players just don't have, and if it's missing something you can usually find a plugin for it.

              Or hell, even WinAmp is often still better than some of those modern, flashy apps. Sure - they look pretty, and they have immense budgets behind them and in some aspects you can see this. But they are also really good at pushing ads at you or trying to take as much money from you as they can, which is not the goal of those "good old apps".

              [–]Aphix 9 points10 points  (0 children)

              This explains why the UI is a disjunct mess of screen after unrelated, inconsistent screen.

              [–]ephemerr 46 points47 points  (12 children)

              Why don't they just use Qt?

              [–]wABgtbRS79EDLfaSC3W2 54 points55 points  (3 children)

              It's not hip enough.

              [–][deleted] 15 points16 points  (0 children)

              my god what kind of next level hipster do you have to be for iframe's to suddenly become cool

              [–]dvhh 12 points13 points  (0 children)

              ncurses is the way of the future of UI toolkit !

              [–]sim642 39 points40 points  (2 children)

              Because web developers can't write C++ and web developers are cheaper than C++ developers.

              [–]Pseudofailure 16 points17 points  (0 children)

              Wow, I feel like this belongs in /r/softwaregore. No wonder all of the Spotify apps always seem so buggy and unstable.

              [–][deleted] 6 points7 points  (0 children)

              Or " It's not RAM, fuck it, we can waste it"

              [–]PeabodyEagleFace 19 points20 points  (0 children)

              I now see why Spotify is such a memory pig.

              [–]EnderMB 4 points5 points  (0 children)

              In some ways, it's a clever idea. The team can move quickly, and can (probably) share a lot of its code base between the main application, the web interface, and its mobile offerings.

              On the other hand, it might also explain why everything they release is extremely buggy. Their desire to move and release quickly is probably why basic things like adding a song to a playlist or persisting the shuffle when you move between playlists break frequently. There's nothing wrong with flying by the seat of your pants, as long as you have an adequate testing framework in place to ensure you're adding new features to test, and to ensure you're not fucking up what you've already got.

              [–]FlyNap 5 points6 points  (0 children)

              Let’s all take a moment to remember Rdio, which had a superior design, features, and performance. It was the Betamax of streaming services, cut down in its prime. RIP.

              [–]boonestock 6 points7 points  (0 children)

              So that's why Spotify is so slow...

              [–]zephyrprime 5 points6 points  (1 child)

              So that's why the spotify desktop app uses so much memory

              [–]cheezballs 8 points9 points  (2 children)

              Their desktop app is garbage. It's slow, unresponsive, lacks features, and frequently messes with my screen repainting after max/min/closing the app.

              [–]bitkill 6 points7 points  (0 children)

              IFrames are not revolutionary. It's a special kind of hell.

              Also, I'm not a fan letting people put dependencies on projects like a buffet. I know the size is not a problem when you are constantly pulling audio, but the computer still has to parse and cache the javascript, and there are a lot of people complaining about the amount of ram used.

              [–]macca321 21 points22 points  (3 children)

              Can't believe all the negativity, makes me wonder if people have worked in large dev teams before. Modularised components and team ownership are vital.

              https://micro-frontends.org/ describes a similar idea.

              [–]hu6Bi5To 7 points8 points  (0 children)

              Conway's Law turned into a virtue.