Prototyping with Excel?

For anyone that's a hobbyist programmer or a hired one I have a question. Is it common practice for people to use Excel spreadsheets to prototype software? Right now I'm in an introduction to Computer Science course and outside of fundamentals we're learning two main methods of prototyping. Pseudocode, and flowcharts. With pseudocode giving an outline of what you should write and flowcharts shoeing a hypothetical work flow. So why Excel? Well Excel has dynamic inputs with being able to reference any cell, but a lot of functions that Excel uses are also identical to basic functions in programming. There are mathematical comparison functions, there are Boolean functions where you can determine the output for "True" or "False," with =IFERROR there's limited error testing, there are even functions that interact with text strings. Plus with the cell system there's a format to visually organize essential information. To be clear I'm still in an introductory course for CS. There could be issues with using Excel to prototype that I'll discover when I'm asked to write more complicate code. So I figured I'd ask for opinions from more experienced programmers before I consider the idea seriously.

>>38530 I can't say for every subset of the field, but I used it for simulations to assist with balancing for development for a wow server emulator and I've known some older game devs who use it for their RPGs.

Your pseudocode is more verbose than an actual Python script. I'd rather prototype my code in an executable language.

>>38535 To be fair, "pseudocode" in an academic setting is pretty much required to be this verbose by many professors.

You certainly can, good luck staying sane though

>>38530 I use it in corpo dev job for make business people understand things and they love it. Yes, if your work for a business you would learn it and use it actively for anothers, sometimes even for yourself.

I used it a couple times when doing some data analytics projects. I wouldn't call what I did prototyping, but conceivably you could. I've seen some non-programmers make spreadsheets with some functionality that they eventually pass off to programmers and say "this has outgrown excel, make a program that does this" and that could arguably be considered prototyping. In general, I don't see it very much and it comes off as a pretty odd thing to do. I rarely see prototyping at all professionally, and it's always a mistake when I do see it. It's not that prototyping is bad, on the contrary, i think its very helpful, but in a professional setting you doom yourself. No matter how hard a developer stresses that something is "just" a prototype, as soon as that prototype does something, management and coworkers will start using it and you end up with your hacky prototype being version 1 of some tool you're expected to maintain and make perfect. So there's really no point in not just doing it right from the start (well, as "right" as you can, given you're often venturing into unknown territory (as if you had enough experience with whatever you're doing that you could make it "right" on first try, you wouldn't be tempted to prototype it out)). It's unfortunate that the business side of things hasn't embraced "build one to throwaway" (despite that it's always the business/manager side of people raving about how everyone in the industry needs to read "the mythical man month," that book must have the lowest information retention rate of any non-religious text) because prototyping has been very useful in my personal projects. Pseudocode and flowcharts are pretty much nonexistent in my professional experience. Sometimes we might give junior developers pseudocode, but not often. I've never seen a flowchart used to describe a program at work (i guess hatred of flowcharts is something people do retain from "the mythical man month"). You're more likely to see architecture diagrams, and if your project is old enough that waterfall was used to manage it, you'll maybe see some design documents, UML diagrams and such. But much of the industry is on the agile train now, so you get user stories and maybe an architecture diagram if you're a good boy.

>>38530 There's actually a large amount of highly complex Excel sheets out there lying around at various businesses performing various automation jobs. Terrifying undocumented monstrosities that could be solved in a far more maintainable way with something on the order of a ~200-2000 line Python script There's just a lot of businesses, like construction, etc. that have really complicated internal stuff they need automated, but no developers on payroll. So it gets done by the office Excel wizard, not because Excel is the best tool for the job, but because they're employing someone who knows it well. And of course chaos eventually ensues because they're essentially doing software development, in Excel, with no background in CS. But often it's cheaper and easier this way than hiring a software consultant to come up with a bunch of bespoke solutions, because while the office Excel guy might not be a CS professional, they are probably a domain expert at whatever problem they're trying to automate themselves out of, and they'll stick around to keep patching the thing.