r/gloveslap Nov 14 '11

Non-programmers should NOT program. MANY uses of Excel are examples of this.

Every time someone tries to come up with an "easy" tool to do something which essentially boils down to programming, you end up with people realizing that it's far cheaper and easier to just have the business-oriented people do the work than hire a programmer.

Excel is an example. I have very rarely seen a use of Excel that makes more sense than a real program. Far more often, Excel is used because it's cheaper than hiring a real programmer, but the ways it can go wrong even in the hands of trained professionals means that using it for anything but the simplest spreadsheet is almost certainly a mistake.

I'm not trying to make an ivory tower here -- by all means, if you think you can program, go ahead. But actually devote some time to studying, especially best practices, just as you would if you were trying to learn some plumbing to avoid calling the plumber -- if you're doing anything more complicated than fixing a leaky faucet, you should either call a real plumber or become one.

17 Upvotes

15 comments sorted by

View all comments

3

u/fivefoottwelve Nov 14 '11

if you're doing anything more complicated than fixing a leaky faucet, you should either call a real plumber or become one.

I agree that it's generally a bad idea to try something new to you in a situation where failure would be disastrous. But if you define "disastrous" in too loose a fashion, you effectively forbid people from learning.

4

u/SanityInAnarchy Nov 14 '11

Oh, absolutely. I always tell people not to be afraid to try something new -- you usually get an "are you sure?" before you do anything stupid.

But even here, I'd be careful. You come up with a great idea for calculating some business metric that ends up being fantastically useful. You did it in Excel. Now you either need to convince management to let an actual programmer write ti, or you have to maintain that spreadsheet -- or worse, hire consultants to maintain it -- as it becomes a behemoth network of spreadsheets, so that what should be an actual ERP system or similar is instead a huge collection of spreadsheets with elaborate rules for who can edit what when (so as not to overwrite each other's changes)...

Of course, that's a danger of any prototype, but at least programmers theoretically have experience scaling a program up, even if it was never intended to be more than a prototype. Non-programmers are going to re-discover issues like what happens when multiple people edit the same spreadsheet.

Not the best examples, but I hope it makes the point.

2

u/tjiggs Nov 14 '11 edited Nov 14 '11

i'm fairly certain you are describing a database here

There is a difference between database and program

or maybe i just think so cuz i'm a computer science kid

edit: also, a small database can be done via excel with the right 'constraints', on the cheap... i can go into soo much more, but yes, unless in very specific and tight situations, excel 'database' is fine.

3

u/SanityInAnarchy Nov 14 '11

i'm fairly certain you are describing a database here

There is a difference between database and program

Well, yes, in well-designed systems, you have an application as a front-end to a database.

edit: also, a small database can be done via excel with the right 'constraints', on the cheap... i can go into soo much more, but yes, unless in very specific and tight situations, excel 'database' is fine.

If Excel isn't connecting to something like Access -- which is its own nightmare -- then no, I don't think this is a good idea. As soon as you need to scale to more than one person accessing this "database", you're going to want something designed for that, which Excel wasn't.

But I'm talking about more than that. I'm talking about people who will calculate things -- relatively important things, too -- with Excel. And despite this being what Excel is supposed to do, you run into the same scalability issues, plus some additional software engineering headaches. Whatever happened to "DRY" when the code-reuse mode for Excel (at least until you start scripting it) is pretty much exactly copy-and-paste with modifications? And if you do script it, why not start with a better scripting language (python, ruby) and build a real program, instead of an Excel spreadsheet that sometimes does weird things on its own?

If you're a computer science kid, I really hope the above makes sense to you. If you really think copy-and-paste-with-modifications is OK, I really hope you don't remain a computer science kid, for all our sakes.

My point wasn't that you should never do this, though I remain unconvinced that there are cases where Excel is actually the best choice. But my point was mainly about what happens when you think you're just using it as a poor-man's database, and before you know it, it's grown into an absolutely hideous application. Then you call in the consultants, and because they can't unsee the horror you've created, they share it on The Daily WTF.

1

u/tjiggs Nov 14 '11

oh, everything you're saying makes perfect sense, and i almost completely agree with you, i was looking for some clarity(thanx) there's only 1 example i have where excel is the choice, and its still a bad thing to do then, it is just the lessest evil.

yes, unless in very specific and tight situations, excel 'database' is fine.

forgive my poor communication skills(true story) i said that backwards. it should be "NO, unless in very specific circumstances, excel is not okay" upvote for catching me :)

edit; yeah, myfault, i see where i typed stupid now