Hacker News Reader

Comment by max46 | Hacker News Reader

I think I big mistake people make here is that they think they are far better at everything on a computer than a non-programmer. They don't realize how much you can do in Excel and how much they suck at it. If you can't use it without a mouse and/or if you don't know pivot tables, you are just as much of a beginner as a C++ programmer who doesn't know what a pointer is.

It's only after trying to convert an excel sheet to [insert your favorite language] that they realize it would take them 6 month with a team of 5 to replicate what a single accountant did in a week.

View on HN

Indeed. Excel gets a lot of (pretty deserved, actually) shit from our industry, but the reality is that Excel does what computers are meant to do: enable users to create sophisticated applications[0] that solve their problems with no coding expertise required, nor kowtowing to some developer, with the option to onramp into adding some code via macros.

Excel is the most widely used programming environment on earth because it is so good at it. That said, I think the fact that we haven't made anything better speaks to the change in philosophy our industry has undergone, from one where we wanted to enable users with computing to one where we want to herd and farm them for money.

[0] yes, both 'sophisticated' and 'application' are defined pretty loosely here.

Opposing anecdote: I have converted excel spreadsheets built over years to SQL, and typically it did not take weeks to do that.

( Any organization that has a smallest reason to care about their data should remove save button from excel and start educating their personnel. Using excel in any important role should be seen as making the eventual mistakes on purpose and someone should be kept responsible.)

Getting rid of lousy Excel-driven processes is a big part of my current job. SQL only solves half the problem, though: Excel is also a tool for manual data-input and manipulation. To solve this piece you often need to create CRUD webapps, which can be much more complex to develop and maintain than some SQL in the database.

> To solve this piece you often need to create CRUD webapps, which can be much more complex to develop and maintain than some SQL in the database.

Why do they need to be webapps? If you've done it with Excel so far, you're obviously on a LAN, so why not traditional client/server native apps?

Deployment and authentication is going to be a problem, but the big thing is that in many such environments users would simply not be able to execute your native client app on their controlled workstation by default. But for most software teams nowadays creating a CRUD webapp is simpler and cheaper than traditional client/server native apps; I've seen major companies maintain their existing client/server native apps but whenever they have the choice (e.g. greenfield development), they'd rather not have a native app because, frankly, there's no good reason to do so as the maintenance is much simpler if you don't have to worry about the deployed client instances.

> I have converted excel spreadsheets built over years to SQL, and typically it did not take weeks to do that.

The "years" of work are typically not for implementing the spreadsheet, but to define what it does. The requirements evolve over many versions.

Of course it's fast to re-implement it after all the work to define the requirement is done, but it's only possible because Excel allowed all those prototypes.

Grandparent claimed that something done in excel by one person in a week takes a team of five and half a year to reimplement in some other language. I disagree with that as a general rule (of course, exceptions may apply, as usual).

I fully agree that Excel is great for quick drafting, visualizing data quickly, and prototyping. But it should be left there. Anything you do that lasts even overnight and has any significant numbers in it should be done with something else than Excel.

Fair enough, the issues for me are that: once something works in a spreadsheet there are no money assigned and willpower to redo it clean in something else, because most of the value is already there; and the people who are available and know the requirements aren’t skilled in anything else.

So prototypes are done in Excel because it’s the fastest and cheapest way to do it, and they don’t get redone in something else afterwards for the reasons above.

> done in excel by one person in a week

Done by a domain expert in their field. If you had to create the project from scratch without aid of an existing Excel file to clone, you would not be able to do it even remotely as quickly as the domain expert, if at all.

> and typically it did not take weeks to do that.

You're not seeing the process and effort that went into it, which can be considerable.

I think you misread my comment. Some of the excel sheets were a result of considerable effort. Years of different people working on them. Converting those to SQL was not a tremendously large effort. That was made by me, so I kind of know the effort:)

Reply on news.ycombinator.com