Adding a new screen to capture information? With a nice graph to display for output? Does it conform to your UI style guide? Does it have passing unit tests? Is it integration tested? Is it code reviewed? Any migrations necessary? Any business continuity ramifications? Etc.

Engineering has overhead otherwise it's just a bunch of cowboys that are no better than Excel hackers - and probably worse, because they have a lot more rope to hang themselves.

Does your '=vlookup(x, ...)' have tests surrounding it? How about code review? How about source control?

Actually, in my experience "sanity checks" were very often built into financial models.

Does your balance sheet balance? That's a pretty basic "unit test".

Do your calculated values match the financial statements values? No? Throw an error.

Divide by zero? Reference a blank cell (similar to an unset variable)? Using a value as a number? Referencing outside of a range? All immediately throw an error that will flow through your model.

And code review often does take place - in banking at least, models written by analysts are checked by associates and then VPs. People who understand what the numbers should look like can spot mistakes pretty quickly using a TI calculator.

Source control is a problem, but many models are one-offs for specific projects - no company (or deal) is structured identically.

You're identifying problems that have, for the most part, already been solved. Not perfectly, but in ways that work well within the structures that have been built around the use of Excel as a core tool.

In my experience, the fact there is a human being staring at the output all day goes a long way towards mitigating the lack of automatic tests.

As programmers, we write tests because we can't see what's happening inside the program while it's at work, so we have to give it a thorough exam before letting it do that. Spreadsheet jockeys can take a radically different approach to validation.

There's also a bevy of issues that impact programmed systems that (in theory!), don't apply to Excel.

I can't guarantee the a programs output will be the same after every VM patch, component update, re-deployment, or even just re-compile. Generally we have multiple devs touching the same system, or same code. Generally we want that code to be robust in the face of reuse in other components and contexts. Generally we have no ability to see production errors unless they are properly logged and monitored, etc.

Worst of all I, a subject expert in nerdy things, am implementing a model in a domain I am an amateur in and have no fundamental context for assessing.

A spreadsheet jockey inverts all those problems. They know what they want, and are intimately connected to its operation.

I think you missed the point. The comment you replied to is stating that excel does not have these things. Proper software engineering will have these. Excel is fast, but also easy to repeat a mistake. With unit tests, software is much less likely to repeat a mistake. Once the mistake is made, found, corrected, unit tested, making the mistake again is likely to be caught by the unit test.

With Excel any reasonably capable business analyst can do sophisticated calculations quickly without needing anything else. With a web app, SQL database and whatever the ramp up cost is huge in comparison.

With Excel I can do things fast, at the beginning, but then I find that it get a bit more tricky, I get lost, I find out that things are wrong, I do more, I want to move to R. I can't move to R. It will take me a week. I have a day. Then I want to move to R, it will take me a month, I have a week, then I want to move to R, it will take me a year, I have a month. Then, I want to drink bleach.

The ramp up cost isn't months vs minutes. That is just pure nonsense.

I disagree. I am working on something right now at my employer where we are taking spreadsheets that have been used for quite a long time (and were created fairly quickly) and they are converting all the business logic to code. Each workbook is taking weeks for them to code and test and then send back to us to sign off on.

I'm a coder DOING some of these conversions. I see both sides of the coin here. One additional point I wanted to mention is that once we have done one or two, or a dozen of these conversions, we start to see common themes.

More often than expected, there are mistakes and misunderstandings in some of the spreadsheets. There are inconsistencies in the spreadsheets. In IT we also get calls that a spreadsheet is "locked by someone." Or that someone deleted a spreadsheet.

With code, and databases, we can ensure consistency between operators. We can also leverage the data across other applications since it lives in a database now. We can pull reports for management more easily, and with more automation.

As some other comments mentioned, spreadsheets are great for prototyping, but also have their drawbacks.

It certainly could be if these tasks now need to be delegated to a centralized software dev team who is fitting them into their project queue.

Erm, they would also need a programmer at that point. More to the point, excel is more of a thinking tool that allows for lots of tinkering with real time feedback. Programming languages require lots of thinking up front and are not meant for thinking without significant augmentation (REPL, Jypiter notebooks).

Excel is a garbage environment and its pretty trivial to find environments that provide both a capable environment AND immediate feedback.

Please tell me where every user can create his own gui within 5 minutes with shapes, activex controls, pictures, keyboard shortcuts, combine those with code which was created by macro-recording (and as such needs the most basic knowledge of programming if any), that can be opened by almost every PC in the business world (as 99% has excel installed), which comes with 100's functions and formulas allowing to create anything and everything. On top of that, please no higher costs than ~50$/user.

Delphi, before Embarcadero shat the bed

It might take a time till coder has time for it. And coder may misunderstand requirements and needs time to get them.

if it's important then coder has time, coder will understand, and coder will spend the time.

By accountants and financial analysts?

You ever tried to implement a generic pivot table builder? Good luck. See you in 2019

I have! Twice :)

https://pivottable.js.org/ and https://react-pivottable.js.org/