Hacker News new | ask | show | jobs
by m132 44 days ago
And to think that the "old" Outlook's splash screen is there for a reason: it used to take a while to open before SSDs became commonplace! Windows in general used to be usable on HDDs; SSDs would blow everyone's pants off making everything open instantly. These days we have 20+ Gbps SSDs without the AHCI latency tax and they're no longer enough to open an e-mail.

THAT'S how low the ball has been dropped.

5 comments

It's not just Windows. It's everything Microsoft.

What steams my clams is that I can press Reply in Outlook and be halfway through the first sentence of my message before the reply window even opens. (M4 Pro)

Almost every time I use Outlook, I have to rewrite my first sentence because half of it was typed before Outlook was finished doing whatever it does in the background. This doesn't happen with other mail clients on the same machine.

It's not 1982 with 8 character keyboard buffers. I shouldn't be able to type faster than a computer can handle the input.

You're right, but it's not just Microsoft.

I've been doing software engineering for 20+ years. I've been at a lot of different companies and at almost every single one I'm always kind of flabbergasted at how shabby the engineering is. I think maybe ONCE in my career did I work somewhere that I was proud of the engineering we were doing and it was a 18 month consulting gig at a startup with 3 engineers.

This isn't hubris, I am part of the problem. Too few engineers working with overly vague requirements with not enough time always results in the same thing. We are all churning out products we should be embarrassed about.

Microsoft might be the largest, most flagrant example, but code base entropy is a rampant force of nature. It is everywhere. Google Home gets steadily worse every week. How? They have like 100,000 engineers. Can they not spare a dozen of them to keep that product from being abject shit?

Is there a solution? I don't know, but maybe LLMs replacing 80% of us is exactly what we deserve.

> I don't know, but maybe LLMs replacing 80% of us is exactly what we deserve.

Been there, done that, but I wouldn't put the blame on engineers. You said there it yourself:

> Too few engineers working with overly vague requirements with not enough time always results in the same thing. We are all churning out products we should be embarrassed about. [...] They have like 100,000 engineers. Can they not spare a dozen of them to keep that product from being abject shit?

You know the big O thing. If your algorithm is inefficient, it will ultimately slow down to a crawl at one point, no matter how many cores you throw at it. Now replace 'algorithm' and 'cores' with 'corporate processes' and 'employees' and you get a picture of what is exactly happening at large bureaucracies. Even worse so now that they can no longer afford to infinitely expand and have to cut costs (through LLMs and offshoring) while maintaining an illusion of growth for stakeholders.

The funny thing is that, despite all of this, the core problem (IMO) of managers playing political games and reaching for short-sighted quick fixes like "new agile methodologies" [0] instead of doing their jobs well remains unaddressed. Meta has been recently letting go of middle managers in a (frantic?) attempt to tame the explosion of bureaucracy and the associated loss of efficiency, but the rest of the industry just appears to be repeating "AI" like a mantra. Even though coding itself has already been the most "over-optimized" part of the whole software development process and optimizing (the costs of) it further only results in further "Outlookization" of software.

[0] https://newsletter.pragmaticengineer.com/p/project-managemen...

The solution is competition in software. But it's a really, really dysfunctional market. Outlook persists because it can speak to Exchange. Too many bad software products persist because they're part of a lock-in with something that's difficult or expensive to swap out. Ultimately, Windows itself.
The problem is more to do with people don't want to pay for software anymore. How would a new email entrant make money when no one will pay for it?
The same question can be asked in this case: if there's no money in it, why did Microsoft pay for the creation of a new Outlook that's apparently worse than the old Outlook?
I think it might be less about making money and more about burning less. From what I understand, the new Outlook is a wrapper around the code that already powers Outlook.com. Since they're already maintaining Outlook.com, they might as well integrate the functionality of the Office Outlook into it and only maintain one of the two moving forward.
Actually the answer is quite simple, their servers are the ones retrieving emails so they have access to the email contents (perhaps for training data?)
I get a weird feeling when I watch vga/dos programs like Quattro Pro 5. These were large programs quite well done, on very very limited machines. Today apps may not even provide that much (but they are fully networked, maybe more extensible).
Since Classic Outlook was developed in the glory days of OLE2.0, it's got OLE Automation baked in. VB and JScript code can access emails and appointments and perform relevant operations on those objects.
Yep, let the AI write efficient code in a compiled language. Switch everything to C++/Dlang/Rust. You are not writing the code anyway, so all arguments against those languages are moot now. Replace Node.js, Electron, and even Java/C#.
In web Outlook I *very" often begin typing as some element is loading a popover and end up hitting some key that archives the message and leaves me scrambling to click Undo. I guess it's usually some contact comes into focus of my mouse and starts trying to load the org chart or whatever. Ughhhhhh.
I remember the late nineties and early naughties, when I used to type faster than Windows could cope with, and it still never lost a keystroke.
I hear the CPU fan spins up when you hit the Start menu now.
It needs to load in all those recommendations for you to ignore.
Not everything. VS code is still good. Odd, but true. Runs like a dream. I do use an old version though from a couple years ago, never bothered to update.
If I were a trillionaire I'd buy Apple and Microsoft and force all their engineers to use spinning rust on everything.

No SSDs would be allowed anywhere except in the "does going fast break it" test room.

Anyone above VP would be required to have 5400 RPM rust.

Imagine that. There would be a company wide "max one reboot per year", planned well ahead (during vacation periods) since it would mean people can't work for days on end. Haha.
Easier and faster software development frameworks have made it cheaper to ship garbage software. Nobody really knows how to measure software quality, but agile development makes it very easy to measure software quantity, so that is what companies prioritize.

It's why AI-driven development isn't actually yielding better products even though it makes developers more efficient. It's just being used to pump out garbage faster.

Why this enshittification…

I also see this bad design pattern - tried to clone an outlook calendar event, a meeting with a teams link it that I need repeatedly at sporadic new times (thus can not set it up as repeating).

Outlook native is unable to do that - I am then forced to use Teams to clone the event, likely because Teams need a new meeting id - but why the f••• is Outlook native not able to do that (oh - it’s a webthing).

Too bad they are making changes for the sake of changes (and $$$) in stead of user needs …

Schedule+ had the concept of exceptions to a recurring appointment (RA) - meetings that didn't follow the recurring pattern (e.g. every week on thursday at 4pm).

This was exposed through the UI by letting the user adjust the date & time for the RA instance (e.g. move this week's thursday 4pm meeting to 2pm) via drag-drop or editing the RM instance and change the time in the appt dialog.

So I assume with Outlook you could schedule a recurring appt for the common case - weekly appt on wednesday at 1PM. Adjust as your needs require - no meeting needed? Delete this week's instance. Need to move the meeting earlier or later? Go and reschedule this week's instance.

Obviously wouldn't work if you needed two meetings in a week.

The recurring events calendar spec is crazy powerful, but also crazy bc its just a flat text file. For a bit i was attempting to stream-parse a huge calendar on my esp32 lcd display board and went down the rabbit hole.
The spec, i assume you mean iCalendar, came later.
Personally that's why I think 'async' in most languages is a farce - it could've never occured to 90s programmers, as back then applications frequently swapped out parts of their program code and state onto the disk - and there's no 'async' to save you from that.

Nowadays disks are fast, but a lot of apps are heavy - your Electron-based webapp is hundreds of megs of binary - there's no saving you from having to load that the same way. In fact most likely your app will have less assets to load than the sum of binaries.