I started with software development in the very early 1980’s. Basic, Assembler and machine code at first and then on to C, C++ and most of the languages and platforms that came out after that.

After about 5 years of building yet another business application, I started to notice a rather monotonous pattern forming. Every data application I was building required an input screen, editing screen for existing records and an output screen. This also meant there was code needed to take input and create a new record from it, code to open an existing record for edits and then save those edits back to the record the original data came from and of course the code to display data. Some of the display-data code was in the form of single record displays while others were in the form of record set displays or “Browse lists” as they were known back then.
These processes were the same for every single data entry system I ever built and were usually also the most time consuming. I was building advanced and highly technical systems for RS-232 communications, expanding my ROM based programming language interpreter and expanding the capacity and capabilities of my floppy drives through code, yet I was spinning my wheels wasting time on code to create input and output displays! There had to be a better way. So, I began to wonder if there were any development tools around that simply assumed all of these functions as defaults for every data record and let you build systems on top of that framework.

User application stack
By this time, I was working at one of our local universities assisting the administration staff with their IT issues. Some issues were hardware related but the lion share of their issues were about the software tools they used. It was pretty simple; WordPerfect was their word processor and Lotus 1-2-3 for DOS was their spreadsheet. That’s it, they really didn’t have anything else.
One day I was called in because the user was having trouble with her mailing labels. I wasn’t sure what she meant by that so I stopped by. I resolved her issue but, in the process, discovered that this poor lady was using a single word processing document to store all of the contact information for students. It was one massive WordPerfect document over 50 pages long that she had to manage as though it were a letter. I was dismayed! So being an experienced data systems programmer, I asked the head of the department what kind of tools they used for managing student information. She pulled up her copy of the WordPerfect document but also pulled up a Lotus 1-2-3 spreadsheet which also contained student details. This was all they had, nothing more.
Over the next couple years, I encountered user after user who either used their word processor as a database tool or their spreadsheet. No one had an actual database tool that users were comfortable using.

A New frontier
Before I get started here, I need to make a couple things very clear.

• This is not about the product, its about the solution it brought and what we’ve lost sight of.
• The product was discontinued and couldn’t be purchased. I couldn’t sell it to you even if this were an endorsement and you can’t buy it! This is about the lessons learned.

So, the big three software companies at the time were WordPerfect, Lotus and Microsoft. Lotus had been the people who made spread sheets but everything they did was always very intelligently done and bulletproof so when the chance came, I went to work for them. That’s when I was introduced to one of their other premier products.
You see, Lotus had noticed exactly what I had noticed. Developers were wasting their time building the same code again and again from one application to another. They also noticed that users had nothing to help them manage their data, so they introduced a very simplified database tool.
The tool translated previously confusing concepts into more digestible terms for end users. Datasets became Views, Records were renamed to “Documents” and fields were simply fields.
Using these basic terms, a user could “Paint” an input screen called a “Form”. Once the form was made, the user could use the form like any computerized data input form to create or edit records (Documents). And using the Views (Datasets), a user could build a multitude of record lists to show their data in different ways. There were built in advanced search functions, sorting functions, spell checkers and automatic column totaling features all available by clicking a checkbox here and there. Viola, we had one of our first end-user friendly data management tools. A tool that not only filled the small data management gap in the end-user application stack, but also removed the minutia of software development from developers so they could focus on the bigger issues. This new end user product was called Lotus Notes.

With this tool, end-users, with no background in IT or data systems, could throw together any data tracking database they needed in minutes. They could refine their little databases and further customize them over time. The users were empowered to do what they felt needed to be done and had the right tool to help them get there without wasting tons of their time. It was intuitive and didn’t punish them for experimenting.

The Power of Empowerment
One of our more basic incentives is laziness. It doesn’t matter what your walk of life is, we’re all looking for the easiest was to achieve the most. The shortest distance between two points. Its what drives efficiencies in every successful part of the business. You can tell a user that they’ll save half a million dollars with an effort and you might get a reaction but you know if you tell them they’ll shave an hour off their work every day, you WILL get a reaction. That’s the wolf you need to feed, the lazy one. And feed that wolf we did. No one had to tell the users they had new job responsibilities. No one had to coerce or bribe the users to use the tool. You gave them a 5-minute video describing how to build a simple “contacts” database and show the possibilities as well as some really good end-user online help documents with good examples and let them do the rest.

Lotus Notes exploded the world over but the story was always the same, no one in upper management had a clue where this thing came from. The product grew in companies from the bottom up because it helped every member of the organization to be more organized and productive by empowering them to create their own data systems and processes in a way that was more efficient than doing nothing at all.

By the mid 90’s every desktop application stack included a word processor, a spread sheet tool, a mail tool and a database tool that was simple for end users to work with and allowed them to create as many databases as they wanted in as much variety as they wanted on their own desktop machine without any server. Many will recall that Lotus Notes made use of servers but serves were only required if you wanted to share interactive use of a database with other users.

In the new millennium the Lotus Notes product took a massive beating for any reason imaginable. Scalability to midscale and large-scale data systems, it’s failures as an object-oriented development tool, the fact that the data wasn’t relational but was flat instead. Everyone forgot that it was a small-scale end user database tool. Now I could go through an entire analysis of why the Lotus Notes tool is gone and believe me it’s a sad loss but the fact is it’s gone and the real losers have been the end users and our bottom line because even the tiniest applications are far more complicated to build now and the vast majority of the tools they’d want are far too simple to become an approved project.
To build that simple “Contacts” application in the office today, you need project managers, web developers to build the record creation page, the record edit page and the record browse list. You need coders (Java or C#) to build the code that has to reside on a corporate backend server to process all of these pages your web developers built (sound familiar). And let’s not forget the Web application server that the website needs to be hosted on and the SQL server that the data has to be stored in as well as the specialized SQL skills needed for that. At the end of the day, after a protracted project and requirements analysis and approval process, the costs associated with building this simple application would be assessed as excessive with no return on investment and the user will be forced to go back to managing their contact data through word processors and spread sheets, just like in the 1980’s.
Well, truth be known, the user would never ask for the application in the first place because they know the kinds of costs and approval processes it would involve and they’re afraid it’s not worth it. In the late 90’s they could have built this same application in less time than it took me to type this paragraph. If you doubt that, I have the discontinued tool installed on my Windows 10 machine and still use today. I’ll shoot you a video of just how fast and easy it was so you can wish it wasn’t dead and gone.

The year is 2020. What tasks can your users address with their current application stack on their own? How are your end users empowered to work smarter and more efficiently?

Again, I have to reiterate here that this is not about the tool but rather the hole that the tool filled in our application stack and what fills that hole today, after 20 years of technological advancement.

Empower them all!
We tend to think in terms of specific projects for specific departments for specific purposes. These projects are defined and fully costed out with definitive ROI expectations, but if you want to empower your end-users, you have to think outside the classic project-based box.

• Think in terms of generic task-oriented tools. Put a little GTO into your end-user stack.
• Go “Long” with request deferrals and reduced workload so your development teams can focus on more mission critical systems.
• Think in terms of cost and time savings through end-user empowerment. Its not about what you’re going to make, it’s about what you’re not going to spend.

End-user empowerment can add some real benefits to your systems development processes too. For most development projects, the process either ends in a project completed on time and on budget with a stream of ongoing, out of budget changes until the application is a twisted mess of Band-Aids, something I like to call, “an application by Johnson & Johnson”, that requires more ongoing spoon feeding than would ever have passed approval, or the project simply never ends until someone loses a job or worse, has to find a way to make the old dead project work.
The problem is that stake holders have other things to worry about on a day to day basis. They don’t have the head space to really think about system requirements until the middle or worse, near the end of the development process. You need to get them thinking about things a lot earlier. I’ve lost count the number of times I’ve walked into a situation where some person known only to a few close colleges used their generic task-based tools to build exactly what the department needed and were using it in exactly the way it needed to be used. It was the perfect template to base the fully scalable solution on and had already been fully vetted and tested by the user’s themselves. Because the system I was building was based on the work of the end-users who had so much personal investment in the system, they were actively defending it from anyone who dared suggest changes to what I was building. That’s empowerment!