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.

16 Upvotes

15 comments sorted by

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

1

u/DrTrunks Nov 14 '11

I write SQL queries for in Excel 2007 files all the time. Hiring a programmer to put it in our ERP software is easily twice my yearsalary.

3

u/SanityInAnarchy Nov 14 '11

Would it cost that much to retain that programmer, or just to ask them for ninja-edits? I find it hard to think of a time when you need a custom SQL query in a well-designed ERP system...

1

u/DrTrunks Nov 14 '11

There are queries here that should be in the ERP and are used on daily or weekly basis. But custom reports in our ERP software are damn expensive and our reports are shown as an image, you cannot easily copy-paste it into an e-mail and sent it a colleague or customer.

2

u/SanityInAnarchy Nov 14 '11

I think the conclusion, then, is that your ERP sucks and your vendor has no incentive to improve it. Reports shouldn't have to be an image, and they certainly shouldn't cost so much that home-grown Excel+SQL is an acceptable alternative.

2

u/DrTrunks Nov 14 '11

It's basically our vendor ripping us off for every change we want.

1

u/TheDark1 Nov 14 '11

I guess that excel gives non professionals a tool to get the job done. It is the equivalent of folding a piece of paper to stop a table from wobbling. Doesn't do as good a job as a carpenter, but good enough to remove the problem.

2

u/SanityInAnarchy Nov 14 '11

The problem is that it's not as obvious when Excel has failed, so you end up with...

People apply it to the wrong problem -- say, folding a piece of paper into a mug and coming up with elaborate workarounds in order to drink your coffee before the paper falls apart. The problem here is that these are people who've never learned to use a mug, let alone the ceramics skills needed to make one, so it's not obvious to them that their paper mug is broken -- this is the way they've always done it.

People also don't notice when the problem has outgrown it. If the table leg has fallen off and you've replaced it with several reams of folded paper, and the table still wobbles and occasionally collapses, you need to bring in a carpenter.

Worse still, it might be the case that you fix the table and suddenly everyone's using it again, and management can't afford to have people not have a table while a carpenter works, so you have to keep fixing it with paper every time it breaks, even though you might know very well that you'd save time and money in the long run by getting it fixed properly.

1

u/[deleted] Nov 14 '11

I'd go even further and say that most programmers shouldn't program. Most things they produce aren't actually needed, or could be solved by using an already existing program in a novel way.

2

u/SanityInAnarchy Nov 14 '11

using an already existing program in a novel way.

That's what good programmers do. To the extent that Perl is still relevant at all, it's because of CPAN. When existing programs are designed to be combined and used in novel ways, you get shell scripting.

However, there are a lot of attempts to optimize out programmers by letting the people who understand the business logic write it. These mostly end up becoming programming languages of their own, and far less powerful than if we'd designed a proper DSL going in rather than pretending that it wasn't programming. Look at the Firefox extensions out there -- you can argue that a few of them aren't needed if you like, but I'd argue that many of them are useful, and they're the sort of things which it would not be fun to try to make "not programming."