In 1994 I was asked to write some software for a client. They had licensed some technology from my employer and needed a Windows program to size the equipment and predict its performance. I hadn written any software at all for 15 years and then it was spaghetti code in Fortran IV for use on an IBM mainframe. So of course I said yes and offered a $3 firm price before they had written any specs for the project. I went to theputer store and asked them which language I should write the code in. The clerk suggested C so I asked to see some code written in that language. Could not make heads or tails out of the syntaxand immediately asked for a different suggestion. The clerk then showed me Visual Basic 3 which looked similar enough to Fortran IV that I bought thepiler and took it to work the next day to start reading up on the language. In those days Visual Basic came with a magazine subscription. I found most of the articles to be impenetrable. Im a mechanical engineer not aputer science major. I had no idea what those client servers were that most of the articles talked about. But one editorial resonated with me. It talked about the evils of spaghetti code and how the use of statement numbers caused it. It suggested the use of logically structured code as an alternative. And it said that the newly released Excel 5 had a new macro language that was based on Visual Basic. At this point a big lightbulb turned on in my mind. I had previously suffered through the problems of specifying the formats for punched card input and line-printer output in FORTRAN IV. Using Excel for inputs and outputs and this Visual Basic stuff for calculations seemed like a great solution to my problem. And since I already had Excel 5 installed on myputer let dive right in. About this point I received 15 pages of specifications from the client. The specs talked all about the language to be usedpilation and ing version control more of that client server nonsense documentation requirements etc. Not a single word mentioned the inputs expected outputs or user interface. Because I didn understand the specs and because they seemed irrelevant I decided to ignore them. I then spent the next 2 months breaking the problem down into small pieces. I coded each piece as a user-defined function in VBA tested it against sample problems in my books and made corrections as required. Nobody else where I worked knew how to program so I waspletely on my own. I wrote notes all over the Programmer Ge and Language Reference books that Microsoft supplied. It was then time to put all the pieces together to solve the sizing and performance problems. By this point I realized that the problem was essentially one of counting snowflakes. The client had a machine (using the licensed technology) that made those snowflakes a big tank to accumulate them and an end user who wanted to melt those snowflakes at particular times during the day. Armed with this mental model I then proceeded to write the longer pieces of code to call my building blocks and start counting those snowflakes. It took another couple of months to code my mental model. Along the way I realized that it was way too slow. I needed at least 1X improvement in speed and got it through the use of array transfer between VBA and the Excel worksheet and optimizing the algorithms used for the nested trial and error solutions to interrelated problems. I then printed out a sample input sheet and some results from my program and mailed it to the client. Got some feedback addressed it and scheduled a meeting with the client to show them the program. Believe you me they were not happy to learn that the long-awaited program was an Excel spreadsheet. But I sold them on the fact that the code was easy to maintainthey had a copy of the source code and it was liberallymented and readable by engineers. Since the last program theymissioned was written in C andpiled they were quite sensitive to the issue of not receiving a copy of the source code. And since all the calcs were done behind the scene by about 5 pages of VBA the user (a salesman) was hard-pressed to mess things up. They gritted their teeth acquiesced to the fact that I had followed absolutely none of their specs and accepted the spreadsheet as the final deliverable. And although I have added some features over the years they are still using that piece of software to size the equipment and predict its performance. I realized at this point that using the worksheet as a place to specify the inputs and receive the outputs made an awful lot of sense in the engineering world. I had control over the accuracy of the calculations in the VBA code and could let the users format the worksheet as they wished. And even though VBA code is interpreted (rather thanpiled and ed) it was plenty fast enough for the frequently iterative heat transfer and fl dynamics calculations that I needed for my day job. Over the next 2 years I programmed virtually every calculation I needed to do more than once in my engineering job using this paradigm of worksheet as user interface for calculations. I have yet to find an engineering problem that can be solved quickly enough to keep the user engaged. And I have no reservations at all rmending that approach as the answer to the question about the best way of using Excel as an interface only and running calculations outside of Excel.