Back in the early 1980s, a British software company launched a product called The Last One It promised to make programmers redundant, by enabling end users to generate all the applications they needed. It's hardly worth pointing out, but The Last One failed to deliver on its promise. Software developers have never been less redundant. The software itself may have migrated from being mainframe hosted, to mini hosted, to running on PCs, and then to Linux servers running in corporate data centres, and more recently to cloud hosted virtual servers, and most recently to Docker containers. And the user interfaces may have moved from green screens to GUI desktops, and then to browser based thin clients, and then to mobile apps. But one factor has remained constant. Consumer and enterprise demand for software has only increased and never abated. Sure, the world's supply of software developers has increased. Commercial software development work used to be the preserve of North America and Western Europe. Now Eastern Europe, Russia, India and China have joined the party. But still supply cannot keep up with demand. And that is why the promise of The Last One retains its appeal, and why there are compelling business reasons driving end user software development.
Going back to 1972, Smalltalk was conceived at Xerox Parc as a programming environment children could master. The Object Oriented programming style it introduced is still software design orthodoxy more than 40 years later. But Smalltalk was still a textual programming environment, even if it did accelerate the design, code, test cycle by dissolving the distinction between build and runtime. So it remained the preserve of "programmers", rather than end users. In his seminal Planning the Software Industrial Revolution paper from 1990, Brad Cox advocates the adoption of a snap together component model of software construction. As the creator of Objective-C, still the native language of Apple APIs, Cox's legacy endures. Systems like Fabrik implemented a visual programming metaphor that enabled system construction by snapping together components. Later implementations of the same paradigm have included MIT's Scratch and AVS/Express. But while they've been successful in their own niches, these systems have never crossed over into general mainstream acceptance for a broad range of software development projects, probably because they're designed for their niches and lack integration with common enterprise infrastructure like relational databases.
Only one system has gained widespread mainstream acceptance for end user software development, and that's Microsoft Excel. Excel is not just an application, like its siblings Word and Powerpoint in the Microsoft Office suite. It's a visual programming environment with a macro language and database integration, and it's an application platform too. To restate in software development parlance, it's a development environment, and a runtime too. Just like Smalltalk, Fabrik, Scratch and AVS/Express it unifies build and runtime, thereby accelerating the design, code, test cycle of software development. And like Fabrik, Scratch & AVS it's a visual programming environment. But unlike those systems it does not use a Lego brick, snap together paradigm. Excel's grid of cells containing formulae referencing cells as inputs is a functional programming environment. That has been one of the critical factors in its end user adoption. Being functional it is not procedural, imperative or sequential, which are all characteristics that demand the programming mindset. Being visual rather than textual is another massive factor in enabling end user software development.
So Excel's visual and functional nature, together with its integration with enterprise infrastructure like databases, and its numerical nature explain its ease of use and appeal for business users. Excel's unification of build and runtime make for rapid development. But in that unification lies Excel's fatal flaw.
A seamless build and runtime environment is not wrong in and of itself. The problem arises when the only runtime is the one integrated with the build environment. To understand why, imagine every business user is a Java developer too, and that every production Java system comes with a Java IDE embedded in its GUI enabling all its users to modify the system. Chaos would ensue in very short order! And that is exactly the state of play with Excel. Every Excel financial model, and every Excel pricing and risk management spreadsheet, is a software system that combines development environment with implementation details and a user interface that does no input validation. And each of those Excel systems can only be operated manually, on a desktop PC! Since they can only be operated manually, and there's no meaningful data validation, testing is poor to non existent, bugs abound, and human error causes frequent Excel horror stories.
The solution is SpreadServe. SpreadServe is an alternate, server side runtime for Excel logic. Here on the SpreadServe team we believe Excel is an amazing tool for empowering end users to achieve business agility by developing their own solutions. We also believe that in many cases, like financial models and pricing and risk calculation spreadsheets, Excel is not the right environment for deploying those solutions. Reliability, automation and scalability cannot be achieved on the desktop with unvalidated manual data entry. By adopting SpreadServe as the runtime for production deployment of Excel solutions, business can retain the agility of end user development, while at the same time maximising the value of Excel based solutions with the reliability, automation and scalability of monitored, server side, data centre and cloud deployment. Spreadsheet testing can automated and recorded, driving down bug counts, operation can be logged and recored in databases to create an audit trail, and report and result generation can be completely automated, eliminating countless hours of manual, "handle turning" desktop operation by skilled staff who should be doing something better.