4 ms·
People think that Excel is the most used "programming language" in the world. Which may or may not be true. But the one truth is this: the world runs on broken
by TacticalCoder 3y ago
People think that Excel is the most used "programming language" in the world. Which may or may not be true.
But the one truth is this: the world runs on broken Excel spreadsheets.
People have no idea. The number of decisions taken higher up the chain based on wrong numbers are beyond belief.
If you've ever been tasked to rewrite a semi-advanced Excel spreadsheet to a dedicated (web)app, you know.
I'm a coder and I do use spreadsheets (not Excel though). Spreadsheets in the hands of programmers are okay.
But thinking that somehow because Joel Spolsky can use advanced Excel features, regular people can too, then you're being completely delusional.
You can't have it both ways: either it's the most used programming language in the world and it has to be used by programmers, or it's a recipe for incorrectness.
- cryptonym 3y agoTools wrongly used, mistakes carried up to top management, this is nothing new and not Excel-specific. They are usually looking at numbers to support decisions, not much for actual guidance/directions.
- onionisafruit 3y agoIf it’s a programming language, then its users are programmers. Just like with javascript or c, some of those programmers are more skilled than others.
- TeMPOraL 3y ago> People have no idea. The number of decisions taken higher up the chain based on wrong numbers are beyond belief. Yup. That's a lesson in how robust organizational systems are - the errors mostly get compensated for somewhere downstream, so visibly bad outcomes are rare. > If you've ever been tasked to rewrite a semi-advanced Excel spreadsheet to a dedicated (web)app, you know. Yeah, I know. I've worked in a place that tried and failed to beat an Excel plugin with a web app. The thing is, in my experience, you'll have a team spend two years doing the rewrite - with a lot of that going into designing and then building complex web frontend using modern tech stack - and in the end, you'll get a dedicated application that has less functionality and worse ergonomics than the spreadsheet you tried to replace. The timeframes and costs involved with getting a Proper Software Development Team to build you a Proper App For That are absurd, and are only getting worse with everyone wanting to do bespoke web SPAs using modern practices and tool stacks. Even if one could afford that, the outcome is unlikely to be better for actual users. And so Excel stays, covering for all the processes that are custom enough that there is no ready-made popular Enterprise SaaS on the market that management can order people to use instead.
- ben_w 3y ago> The timeframes and costs involved with getting a Proper Software Development Team to build you a Proper App For That are absurd, and are only getting worse with everyone wanting to do bespoke web SPAs using modern practices and tool stacks. Even if one could afford that, the outcome is unlikely to be better for actual users. And so Excel stays, covering for all the processes that are custom enough that there is no ready-made popular Enterprise SaaS on the market that management can order people to use instead. I've had similar thoughts recently, though without the direct personal experience of trying to convert from a spreadsheet to an app. Makes me wonder: perhaps what we really need isn't a shiny new framework like React or a design pattern like async/await, but rather "VB for the web"[0] — drag and drop a text field here, a number field there, perhaps a checkbox or some radio buttons, then add some "done" and "cancel" buttons… it shouldn't be as hard as it has become. Heck, give Figma or whatever a way to be event-driven like VB was, it's not like we should need engineers to hand-craft code that replicates the look of a design document. [0] Xojo and VB.net both exist, so the question is really: why are they not dominant? Is it as simple as "BASIC-family languages are fundamentally bad"? But the language itself obviously isn't a necessary constraint; and likewise Xcode has Interface Builder (though less reliable in SwiftUI than it was in UIKit, still present, yet why isn't it better?)