ABOUT ME

Steve Hollister, SNAME, IEEE (Life Member), ACM

I wrote my first program in 1972 at UConn using cards. In 1973, I transferred to Michigan Engineering and used the famous Michigan Terminal System (MTS) and Integrated Graphics (*IG) package in computer graphics classes with Bert Herzog and Dick Phillips. We wrote "interactive" graphics programs in FORTRAN for Tektronix terminals and Calcomp plotters. I graduated in 1978 with two separate master's degrees in Naval Architecture and Marine Engineering (NAME), and Computer, Information, and Control Engineering (CICE). I was one of the first to have formal computer engineering and subject matter expertise.

Then came the PC era with computers that had nothing. I wrote graphics drivers in assembly for devices like the CGA, EGA, and VGA displays and the Hercules card and Epson printer and  programmed everything from Bresenham's algorithm up through the display of points, curves, and surfaces, hidden line renderings, 3D viewing transforms, to a full graphics user interface where there were separate text and graphics modes. I wrote and still write general CAD software and software for boat and ship design and analysis. One of my programs is a general 3D CAD program that uses NURB surfaces (see www.pilot3d.com and www.newavesys.com) See also my top-searched paper called "The Dirty Little Secrets of NURBS."

In the mid-80s I taught college math and computer science full time during the height of Turbo Pascal. I connected it to my graphics drivers for my computer graphics course. Those were also the years of emergence for C and then C++. After many years developing code at all levels for programs in DOS, Windows came in the late 90s. Most all of my code had to be thrown out and only that which was commercially viable was updated.

What was the new programming environment? Microsoft Foundation Classes (MFC). Now, years later, that's old and perhaps going away. Next are web-based apps and SaaS and we now have Java and Python and Agile Programming. What justifies conversion time and cost? I've written over a million lines of code over 45 years and a lot of it has been thrown out. Even though calculations might be coded into libraries, the cost of building new apps is prohibitive. I'm a subject matter expert programmer who has spent much of my career writing UI and data file access code - again and again as technology changed - losing code and market opportunities along the way. When will change, learning curves, and programming objects be properly encapsulated?

Then there are the problems of no automation of separate calculations and the problems of "neutral" data file formats like IGES and STEP. TSPA is my solution to all of those problems. It's the story of and result of my career. The traditional "app" user model of program architecture has to change. Industries and users have to take back control and users must become creators. Bottom up agile programming cannot exist with an internal top down management mentality in an increasingly interdependent, outsourced, and SaaS world of external programs and data.

​For TSPA applied to a specific industry (Naval Architecture and Marine Engineering), go to www.sname.org/project114/home or see my Paper Trail page. This will also describe the history and development of TSPA, including the specific example shown in the picture below.

You can contact me directly by email here.

TSPA can "wrap" multiple separate code or calc engines to create a combined single calc engine that can be launched by a standard open source UIF. The sequenced calc engines above search for an optimum solution and this wrapping was done without writing a line of new code, and each calc engine can be located anywhere on the web. The sequence above combines a ship hull shape variation calc engine with a hydrostatics calc engine and followed by a ship resistance calc engine. These programs were wrapped together by a user to create one calc engine to use with a standard open macro source UIF spreadsheet. A technical paper was presented on this working solution at the 2016 annual conference of SNAME. This solution is not possible unless calculations are separated from user interfaces. This is an updated recreation of work described in a paper given in 1996 (over 20 years ago!) by Steve Hollister that accomplished the same task, but all calculation and user interface code had to be combined into one app and tested. TSPA completely eliminates that need. This is extremely important for all areas of software development. The alternative is complex and very costly custom programming - by programming experts, not users. TSPA gives subject matter experts the tools to take back full creative control over their work - and their markets!

Test Page