5 ms·

> Yet teams consistently overlook speed. Instead, they add more features (which ironically make things slower). Products bloat over time and performance goes do

by baxtr 6y ago

> Yet teams consistently overlook speed. Instead, they add more features (which ironically make things slower). Products bloat over time and performance goes downhill. This. Yet, I’d say it’s not the teams. In my experience it’s usually management that demands new features and doesn’t care about speed.

onion2k 6y ago
Yet, I’d say it’s not the teams. In my experience it’s usually management that demands new features and doesn’t care about speed. This line of reasoning makes me sad. It highlights so many problems in a company that a developer is having to deal with; - Seeing 'management' and 'devs' as opposing teams shows a lack of communication and a lack of understanding from everyone involved. - A company where managers aren't willing to listen to developers is never going to put out a great product. Developers have expertise and know what they're doing. - A company where developers think they know best is never going to put out a great product either. Managers also have expertise and know what they're doing. - If the "managers" dictating that features are added are "higher ups" rather than product managers then the company is never going to put out a great product because the people who talk to the customers and look at usage metrics should be driving the product roadmap. Customer needs should be driving what gets added. - Developers who aren't putting up a fight to write good, fast code because they're not being listened to stop caring about what they're building, and that means there's very likely to be other problems like significant bugs, tech debt, etc. That just grinds you down and stresses you out. All in all, if your opinion is "the product I build sucks because managers make it suck" you probably need to find a new job. Not every company is like that. Find a good one.
- corty 6y ago
  I think it might be necessary to just frame speed as a problem everyone can relate to, Ferengi as well as developers. One possibility for speed as in latency would be to pre-agree on a latency budget (as in realtime-systems: if you exceed that deadline, your system has failed). Then have everyone be aware of how they spend that latency budget. Say the latency deadline is at 500ms for your website to full interactivity. Currently you are at 320ms. Marketing wants to include some analytics scripts. Include them in the test page, measure the added latency, then check against your deadline: added 200ms, we are now at 520ms. Do we reject marketing's wishes or do we make the design dept. cut back on their image load times, maybe they can get from 130ms to 90ms? How about investing in better caching to get 100ms? That way you can discuss numbers and can quantify how something impacts the overall experience. Budgets is something everyone can understand, and taking a big gulp out of a limited budget is something no-one wants to be seen doing.
  - eska 6y ago
    A technique I learned from Tanenbaum's operating systems book back in the day, that has served me well over the years, is to come up with the theoretical maximum and compare it to a naive implementation. For example right now I have to deal with a data interface provided by a partner company. The theoretical limit of the interface should be 1.625 MB/s. If we were to stupidly copy our numeric streaming data over, we would be within our timing budget, and optimizing this would be optional. However, the implementation of the partner company only reaches 0.1MB/s max. So their "smart" implementation/interface is only 6% efficient, or in other words could be 16 times better. That really helps putting things into perspective, and turns management's bullshit filter on, when the partner company says "you can buy this from us if you want more performance" or "that's just the limit of the hardware".
- the_cramer 6y ago
  "Developers have expertise and know what they're doing." Unfortunately this is not always the case. Currently there are other "developers" getting access to our sql servers that drag down performance a lot. It looks to me that they may be coming from an OOP world and now trying to force these patterns onto sql which doesn't scale at all. So developer != developer and not all developers are good imho.
- danjac 6y ago
  > Customer needs should be driving what gets added. In enterprise, the "customer" is going to be someone who will almost never touch the product once they've signed off on it. Building something that's a pleasure to use (good UI, responsive etc) for the end-user is usually wayyyy low on their list of priorities.
o_m 6y ago
I've tried to think why this is, and I think it is because no one wants to make things faster because that would be admitting you didn't do it right the first time. So product owners try to hide it under the rug, and they'll focus on things they can present to their own leaders so they are on good terms all the way.
- hutzlibu 6y ago
  I rather think most devs have overpowered hardware for developing - and simply don't notice performance drops directly on consumer hardware.
  - reassembled 6y ago
    My friend develops PixelCNC, an OpenGL app for generating 3D tool paths from 2D images, on a netbook because he knows many of his users have under-powered older systems.
  - iKevinShah 6y ago
    This is so true. My workstation was i5 2nd generation with my development code running on a partition which was on HDD, the timings for every request were ~200ms to 1s depending on multiple factors. Page performance in chrome was constantly ~1s total. I upgraded to latest i5 with SSD for data, and the performance drops are basically 0. It bothers me that there is something which needs improvement and I cant check on a commit to commit basis. But yes, it is very easy to oversee performance drops due to new / faster hardware.
goatinaboat 6y ago
Yet, I’d say it’s not the teams Speaking of Teams, there is something I don't really understand, which is that we have just experienced nearly a full year of intense competition between Teams, Webex, Zoom, Bluejeans, Skype and all the rest. All of those products should be AMAZING by now. But actually most of them are still clunky as hell, and Teams itself is probably the worst of them, it's still as slow as it was a year ago, still unreliable and still missing (trivial) features that people actually want, like the ability to block/ignore certain contacts. And it can't be - if anyone at Microsoft actually uses it themselves - that they don't know how bad it is. But they seem to be doing absolutely nothing about it.
- Nextgrid 6y ago
  Microsoft Teams isn't designed to compete on technical merit, it's designed to appeal to bean-counters who have either never used anything better, or have not used and will not use the software at all, thus slowness isn't an issue because the people it would affect (the end-users) have no say in the matter. No opinion on Bluejeans nor Webex but I assume it could be the same as above. Zoom isn't actually that bad. UX-wise it has some issues but speed-wise it performs better than everything else I've tried (probably helps that it has a native app instead of being browser-based or Electron garbage). Skype is a consumer product and is left to stagnate more or less. Most likely, they don't see enough profit potential in it to make it actually better (which would involve throwing away the Electron crap and rebuilding a - or dusting off the old - native app).
  - bombcar 6y ago
    Zoom is frighteningly above all the rest; the speed is there, the background replacement is miles ahead of Bluejeans - if they weren't worth $infinity I'd expect Microsoft to buy them and shove it into Teams somehow.
  - BlargMcLarg 6y ago
    > Microsoft Teams isn't designed to compete on technical merit, it's designed to appeal to bean-counters who have either never used anything better, or have not used and will not use the software at all, thus slowness isn't an issue because the people it would affect (the end-users) have no say in the matter. Quoting for emphasis. It's incredibly telling most people who started WFH since spring 2020, they are nowhere near as adapted or sensitive to this stuff as people who used similar commercial apps with a different target audience (gamers) on the regular. Teams feels like two steps forward, one step back compared to Skype. It looks more streamlined, business-y and has cool integrations, but so many design choices irk me and the performance is meh.

by baxtr 6y ago

onion2k 6y ago

Yet, I’d say it’s not the teams. In my experience it’s usually management that demands new features and doesn’t care about speed. This line of reasoning makes me sad. It highlights so many problems in a company that a developer is having to deal with; - Seeing 'management' and 'devs' as opposing teams shows a lack of communication and a lack of understanding from everyone involved. - A company where managers aren't willing to listen to developers is never going to put out a great product. Developers have expertise and know what they're doing. - A company where developers think they know best is never going to put out a great product either. Managers also have expertise and know what they're doing. - If the "managers" dictating that features are added are "higher ups" rather than product managers then the company is never going to put out a great product because the people who talk to the customers and look at usage metrics should be driving the product roadmap. Customer needs should be driving what gets added. - Developers who aren't putting up a fight to write good, fast code because they're not being listened to stop caring about what they're building, and that means there's very likely to be other problems like significant bugs, tech debt, etc. That just grinds you down and stresses you out. All in all, if your opinion is "the product I build sucks because managers make it suck" you probably need to find a new job. Not every company is like that. Find a good one.

corty 6y ago
I think it might be necessary to just frame speed as a problem everyone can relate to, Ferengi as well as developers. One possibility for speed as in latency would be to pre-agree on a latency budget (as in realtime-systems: if you exceed that deadline, your system has failed). Then have everyone be aware of how they spend that latency budget. Say the latency deadline is at 500ms for your website to full interactivity. Currently you are at 320ms. Marketing wants to include some analytics scripts. Include them in the test page, measure the added latency, then check against your deadline: added 200ms, we are now at 520ms. Do we reject marketing's wishes or do we make the design dept. cut back on their image load times, maybe they can get from 130ms to 90ms? How about investing in better caching to get 100ms? That way you can discuss numbers and can quantify how something impacts the overall experience. Budgets is something everyone can understand, and taking a big gulp out of a limited budget is something no-one wants to be seen doing.
- eska 6y ago
  A technique I learned from Tanenbaum's operating systems book back in the day, that has served me well over the years, is to come up with the theoretical maximum and compare it to a naive implementation. For example right now I have to deal with a data interface provided by a partner company. The theoretical limit of the interface should be 1.625 MB/s. If we were to stupidly copy our numeric streaming data over, we would be within our timing budget, and optimizing this would be optional. However, the implementation of the partner company only reaches 0.1MB/s max. So their "smart" implementation/interface is only 6% efficient, or in other words could be 16 times better. That really helps putting things into perspective, and turns management's bullshit filter on, when the partner company says "you can buy this from us if you want more performance" or "that's just the limit of the hardware".
the_cramer 6y ago
"Developers have expertise and know what they're doing." Unfortunately this is not always the case. Currently there are other "developers" getting access to our sql servers that drag down performance a lot. It looks to me that they may be coming from an OOP world and now trying to force these patterns onto sql which doesn't scale at all. So developer != developer and not all developers are good imho.
danjac 6y ago
> Customer needs should be driving what gets added. In enterprise, the "customer" is going to be someone who will almost never touch the product once they've signed off on it. Building something that's a pleasure to use (good UI, responsive etc) for the end-user is usually wayyyy low on their list of priorities.

o_m 6y ago

I've tried to think why this is, and I think it is because no one wants to make things faster because that would be admitting you didn't do it right the first time. So product owners try to hide it under the rug, and they'll focus on things they can present to their own leaders so they are on good terms all the way.

hutzlibu 6y ago
I rather think most devs have overpowered hardware for developing - and simply don't notice performance drops directly on consumer hardware.
- reassembled 6y ago
  My friend develops PixelCNC, an OpenGL app for generating 3D tool paths from 2D images, on a netbook because he knows many of his users have under-powered older systems.
- iKevinShah 6y ago
  This is so true. My workstation was i5 2nd generation with my development code running on a partition which was on HDD, the timings for every request were ~200ms to 1s depending on multiple factors. Page performance in chrome was constantly ~1s total. I upgraded to latest i5 with SSD for data, and the performance drops are basically 0. It bothers me that there is something which needs improvement and I cant check on a commit to commit basis. But yes, it is very easy to oversee performance drops due to new / faster hardware.

goatinaboat 6y ago

Yet, I’d say it’s not the teams Speaking of Teams, there is something I don't really understand, which is that we have just experienced nearly a full year of intense competition between Teams, Webex, Zoom, Bluejeans, Skype and all the rest. All of those products should be AMAZING by now. But actually most of them are still clunky as hell, and Teams itself is probably the worst of them, it's still as slow as it was a year ago, still unreliable and still missing (trivial) features that people actually want, like the ability to block/ignore certain contacts. And it can't be - if anyone at Microsoft actually uses it themselves - that they don't know how bad it is. But they seem to be doing absolutely nothing about it.

Nextgrid 6y ago
Microsoft Teams isn't designed to compete on technical merit, it's designed to appeal to bean-counters who have either never used anything better, or have not used and will not use the software at all, thus slowness isn't an issue because the people it would affect (the end-users) have no say in the matter. No opinion on Bluejeans nor Webex but I assume it could be the same as above. Zoom isn't actually that bad. UX-wise it has some issues but speed-wise it performs better than everything else I've tried (probably helps that it has a native app instead of being browser-based or Electron garbage). Skype is a consumer product and is left to stagnate more or less. Most likely, they don't see enough profit potential in it to make it actually better (which would involve throwing away the Electron crap and rebuilding a - or dusting off the old - native app).
- bombcar 6y ago
  Zoom is frighteningly above all the rest; the speed is there, the background replacement is miles ahead of Bluejeans - if they weren't worth $infinity I'd expect Microsoft to buy them and shove it into Teams somehow.
- BlargMcLarg 6y ago
  > Microsoft Teams isn't designed to compete on technical merit, it's designed to appeal to bean-counters who have either never used anything better, or have not used and will not use the software at all, thus slowness isn't an issue because the people it would affect (the end-users) have no say in the matter. Quoting for emphasis. It's incredibly telling most people who started WFH since spring 2020, they are nowhere near as adapted or sensitive to this stuff as people who used similar commercial apps with a different target audience (gamers) on the regular. Teams feels like two steps forward, one step back compared to Skype. It looks more streamlined, business-y and has cool integrations, but so many design choices irk me and the performance is meh.