Because I had already done about the same thing in HP basic before PC's existed, when there wasn't a spreadsheet app anyway.
And it was on my mind the whole time.
It didn't take many more years before clients wanted their results in XLS on one tab and the invoice on another tab. Rather than the DOC files they had been wanting, which were reasonable facsimiles of the top linen typewritten paperwork I used to fax then mail by USPS or Fedex at the beginning. With the original invoice attached using a "gold" paperclip, nothing ever stapled or folded.
Oh how low I have sunk since then :\
Anyway it was pretty easy to switch from Word to Excel using the same fonts and similar formatting, even though direct integration was provided for, I just switched. When clients printed it they looked almost indistinguishable from my old typewritten multi-font documents.
And that just happened to put the paperwork onto the same spreadsheet as the data. Left one blank tab for future AI use, and the two tabs to send to the clients are in place to the right of that.
Eventually there were quite a few tabs in between the blank placeholder and the final two tabs that the clients would receive. Each with its own function to further leverage built-in Excel capabilities and make further progress toward a "paperless" office.
Saved gobs of code there too, but it gets "worse" from here ;)
It all came together by writing more VBA modules until there was an automation "shell" around the working system. Once complete it would stop so you could look at the data, decide what to type into the blank tab ("naturally", in the absence of AI) then hit the button.
And you were done.
be it things better done with a database, a word processor, a diagramming program, a label generator, a Form editor, a markup language, a web page, anything: they had all the tools at their disposal but no, no, they felt the odd compulsive need to do it with only Excel instead…
…often leading to problems down the line when the limitations of Excel for the use case (for which it wasn't made) would show more and more but they wasted already so much time and (needless) effort doing it in Excel that they would be even more reluctant to the possibility of switching to any more appropriate tool for the task.
Until the web version takes over, and you can no longer connect to anything real.
"Lessons from writing a Kubernetes Security book" at
https://news.ycombinator.com/item?id=44784495
all about the joys and problems developers encounter using kubernetes/k8.
And reading now, today here about Excel/VBA, it struck me that something was missing: couldn't I eliminate 90% of computer software and ease 80% of software devops simply by building/selling a system that ran purely Excel atop kubernetes?
I mean, isn't that all there is to computing nowadays? Plus a little social media? And some AI for fun and maybe a little Excel/k8 work as frosting on the cake.
EDIT: Upon some further thought and prompting by helpful anonymous others, I have found a slightly different path: a FORTH/kubernetes system that will be used to bootstrap versions of VBA & Excel to the cloud. This will be made available to the great unwashed masses of humanity (and their AI friends) for implementing social media for all.
Lo and behold, not every math package provides "shadow values". So you either buy a specialized math tool, or... use Excel, that has it built-in.
That one estimated nominal and peak loading on electrical distribution circuits by querying a DB for consumption on a given branch, and comparing it to a table containing current handling capabilities of various kinds of ACSR (overhead power lines). It was easier to do that in Excel because people were already used to it for various calculations.
Also if you’re wondering, yes, we had some bespoke software whose name escapes me that was specifically created to model electrical circuits; unfortunately no one knew how to use it, but one guy thought he did, and convinced management that we didn’t need to pay for training because he would train everyone else. He did not.
In my case, another not-insignificant factor was that multiple people on the team were quite good at abusing Excel and VBA, but only two others knew any other programming languages. One of them was an engineer (not SWE, engineer as in fab tool engineer - I think he was an EE) who occasionally wrote stuff in C for fun, and the other was also an engineer, but one who had convinced management that we should create an in-house SWE team. Great idea, and we weren’t the first to do so; unfortunately our manager was abruptly replaced, and his successor saw no value in the proposition.