Are you Developing Apps Backwards?
The typical application developer is not developing apps backwards. They are following the normal development methodology. That includes me (until recently).
I will explain, as best I can, how developing apps backwards can significantly improve user acceptance of your work.
The usual steps to take in application development are:
1. Develop Notes Application Forms and Views
2. Check with User to see if they are on the mark
3. Add users data to application.
It took us a lot of blank stares and user review meetings where the user had a hard time staying awake to find out that the user was not moved. Being quick on the uptake, after the 20th review session with the 20th user, we decided to figure out why they looked at us blankly. In retrospect, all the users had the same general response: I'll give you better feedback when it is in production. Well, by then it would be too late, and we knew it. We thought about that some more, and decided that what they wanted was not necessarily to see the application in production, but to see the application with their data. We were boring them reviewing the list of Keywords in a field and showing them some nice graphics that we diligently scanned in.
(Warning to the reader: This story gets uglier before it gets better).
Many times, the user review is the last step before a presentation. At that presentation, a group of disinterested managers will decide the fate of the application, which by now had quite a bit of personal ownership by me and others. It was disheartening to see that same bored look. That same "so what" feeling, even with really slick applications.
We discovered, after reviewing the last year of presentations, the following facts:
1. Applications that were key to the business were being built ALL THE TIME
(no matter how bored they were).
2. Applications that were not important were never built.
3. Application that were in that elusive gray area, meaning important to limited
users or departments, were sometimes built.
In that gray area, where we could most often affect the outcome, we weren't doing very well.
We then decided to go to work and fix this problem. We tried to build even slicker applications, by adding more graphics and fancier forms. This helped a little, but not enough.
We started using huge projection screens during the presentations, and found we were hugely boring them (although when the lights went down, I think some were very grateful to be able to get some sleep).
Finally, we took the step that helped us the most: We loaded the users data into the application for the review. What a difference. What an enormous difference! When the forms contained data, the application became secondary and the business significance of the application become the primary focus (as it should). Then, the group's enthusiasm would increase significantly. Questions of data sources would begin to pop up. Discussions would start on how "clean" the data was. How often it needed to be updated was discussed. When the question of security, specifically who can see or edit this data came up, I knew that the application would see the light of day. The user was convinced this application was valuable, and needed security to protect the data.
What a difference! We did minimal presentations of boring field information, and focused on the application and how it fit into the company. The users did all the rest of the work. We could sit back and let them excitedly debate the business and deployment issues among themselves.
The lesson we learned from this experience is to load the data first and build the application around the data. How can this be done? There is a little-known feature of Notes that lets you put data into it before any forms or views are built. That's right. We actually developed a data import tool to exploit this little-known feature. The Sentinel, as the tool is called, moves the user's data to Notes first, and we then design views and forms around the data. Interestingly, form and view development proceeds much more quickly, as all of the field definitions are in the Notes database.
Previously, much of our design time was spent discussing necessary fields. The imported data defined for us over 60% of our data needs, enough to have that first review meeting. And were users ever impressed! The main reason was that they told us very little before that review meeting. They didn't have to! The data told 60% of the story.
When senior management did a project assessment (code words for a go/no go decision), they also became excited at both the progress of the application, and the access to real data. You can tell if your project will succeed if the senior managers ask if they can have access to the application at the end of the meeting! That never happened with the empty application shells.
In summary, we always develop apps backwards:
1. Add users data to application.
2. Develop Notes Application Forms and Views
3. Check with User to see if they are on the mark
Now that we are, we are building a lot more of these applications, for much happier users. We like to say that our users are all from Missouri. "Show me" is their motto. Try developing apps backwards! You'll be impressed with the results.
Sidebar 1
Financial Customer Example
We were working with a large financial institution which was new to Notes. The business managers had some interest, but they hadn't seen anything tangible. We discussed all of the things Notes could do, but no one would make any commitments to any projects. Then we had a breakthrough: A manager who had an assignment to rank order all customers approached us to assist him. He had only three days to make a first presentation! That's when we started developing apps backwards. We imported his data using the Sentinel, some 2,000+ records. Once that was loaded, we built about eight views to look at customer quality by different criteria. Finally, we built a basic form (how slick can you make a form in one hour?) in case someone wanted to look at one customer in detail.
The senior management went bonkers! They loved having all of that data at their fingertips. The form's basic look did not put them off. They had access, after all, and access was what they wanted from the start.
That application went into production that day, even though it was barely started. We eventually spruced it up, but nothing we ever did after that point created the same level of enthusiasm as that first senior management review.
Sidebar 2
How we use the Sentinel
Unfortunately, every project used to suffer delays in the data loading phase. The data loading task was difficult, time consuming and, at times, mind boggling.
Each client we worked with needed data from different sources, fed into different Notes applications. They also needed to synchronize the data in Notes when the source data changed. One client had AS/400, RDB, and Paradox data that they needed to use in a single Notes application
Our first approach was to use the COL File Import Function in Notes. While this worked as far as getting initial data from Source 1 (AS/400) into Notes, it would not let us update only certain fields from Source 2 (RDB) and Source 3 (Paradox). So we were completely frustrated. We needed to merge data from many sources into one Note.
We created the Sentinel to allow merging many sources into one Note. A side benefit was that it helped us to develop apps backwards. The Sentinel reads from any ASCII or ODBC file and adds or updates only certain records and fields in the Notes application. This can be done before any forms or views are created. As Notes users, we designed the Sentinel to work simply by composing a Notes form (see below). It can be run right from a Notes form, or scheduled to run at night or on weekends. The biggest advantage was that it required no programming, just composing Notes forms.
The user, who has tasted Notes access to Oracle, RDB, Sybase or legacy data, will not wait for long. As we all have learned, users want what they want when they want it. And with the Sentinel, we have raised their expectations on what they can get now! | |