[chadgeidel]

I don't know your background but "taking an Excel workbook and using that as requirements to drive an implementation" is not speedy. I've done this several times in my career and it's very, very difficult. Not because there is any "idealization", but because the reason the spreadsheet works is because a human is doing half of the work. These spreadsheets are not some "hello world" easy to understand product - they are the result of months/years of effort by a team of individuals which has grown beyond Excel's ability to handle. Translating that into code is not "quick and speedy" even if one is doing a like-for-like implementation.

[simooooo]

Currently web-ifying a huge pivot table (30+ columns) into a dynamic library SQL report for access via the web. It's a nightmare of horribly complicated aggregate grouping/totalling across many columns.

Additionally the original excel sheet made incorrect assumptions, resulting in a re-specification/design of what all the totals actually count.

NOT speedy.

[endorphone]

"Additionally the original excel sheet made incorrect assumptions ... NOT speedy."

So...not as I described then? If you are evaluating assumptions and going back to the drawing board, of course it won't be speedy. The point is that if it's simply a requirement to be implemented as is, it is a quick and speedy process.

And it is. I mean, there are dozens of products that will automate the entire process it's so rote.

[simooooo]

No but I don't think what you described exists but for the most basic scenarios.

[endorphone]

And I absolutely agree. My point was that Excel workbooks exist in a no man's land, where untenable practices are allowed by necessity. When we transition away inevitably we add layers of error checking and validations and security controls and processes, etc, that turn a simple project into a monstrosity. But it isn't that Excel was efficient anymore than having the random cowboy coder throw together the most adhoc thing imaginable (but quickly) is efficient.