> 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.
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.
"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.
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.
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".
> 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.
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.
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).
> 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.
For most people in the environments where Teams is rolled out, the standard used to be either e-mail (using bloated clients like Outlook) or Skype for Business (formerly Microsoft Office Lync).
The question as to why those previous options can't be as good as the consumer-grade alternatives (such as the social networks they're often using) has already been settled long ago and they've accepted whatever BS answer they've been given.
Compared to what they used previously, Teams is indeed an upgrade (albeit small) and they are unlikely to question its quality as they've already accepted that the tools they use in their enterprise are terrible compared to consumer-grade alternatives they use outside of the enterprise.
The real eye-opener for them would be to try Slack, where they would suddenly realize that office chat doesn't have to suck, though I have to say Slack is doing a great job over the last couple years at catching up to Teams when it comes to terribleness.
> designed to appeal to bean-counters who ... will not use the software at all
Easy conspiracy theory to postulate, but with WFH "bean counters" use video conferencing software just as much as devs - indeed probably far more intensely.
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.
Having used Teams, Zoom, Skype, Google Meet and Jitsi, I'm having a very hard time understanding why people go through the pain of Teams, Zoom or Skype.
Jitsi and Google Meet don't employ any dark patterns, they are fast, they are reliable, they are easy to use. (I do use them only in Chromium.)
Zoom desperately wants me to download their client, even going so far as to require multiple failed attempts before showing the button to join using the browser. Then it wants me to complete a CAPTCHA before letting me join. If I do use the client it opens several separate windows and asks if I want to join using desktop audio. (Of course I do, and if you still want to ask please keep it in the main window.)
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.
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.
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.
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.