Methodology

The Holy Grail of application development has always been to develop applications faster, with fewer bugs and provide adequate documentation throughout the entire process. To produce a piece of software with a feature mix that satisfies the clients needs for the lowest cost in time and dollars.

The steps of application development are:

1. Identify the environment of the application
2. Catalog the requirements and expectations
3. Build the application
4. Test the application
5. Document the application
6. Train the users
7. Convert and / or load legacy data
8. Install the application
9. Support the application

The problem is that application development is not linear. It is a circular, evolutionary process, but budgets and delivery schedules, which are linear, are set early and need to be met for serious business reasons. A quandary develops when undiscovered information comes to light in the development process that was not available earlier.

Application development as a discipline has existed for only about 40 years with just the last 10 years or so seeing the kinds of pressures we are familiar with today. It is an infantile discipline in the grand scheme of business history. During that time, the tools and environment have changed dramatically. Add to that the accelerated level of complexity and it is no wonder there are so many poorly implemented or failed projects to fill the trade papers with horror stories.

The fact that this is not a linear process is where the dilemma arises. As discoveries are made during the process, the decision to go back and re-engineer based on the new knowledge is a difficult one. It is costly in both time and dollars. Missed milestones are difficult to justify and can be critical in today’s fast paced business environment. The ability to gather more information, earlier in the process is a valuable asset. A stable application cannot be built on what is not known. No tool has been available to collect the milieu of information that is needed in today’s application development process. This collection of information is very dynamic, involves many people and is subject to constant change through the life of the project. Also, in the interest of maintaining schedules, assumptions are made by the development community as well as the user community that each understands what the other is articulating. The fallacy of this assumption is usually discovered somewhere during the implementation portion of the project.

To this end, OrganizeIt! was created. Two individuals or groups working on a project who think they understand each other, but discover subtle differences in perceptions during the process are on very dangerous ground. Users assume that developers understand the subtleties of the business process that they themselves have often not even documented. Application developers have a propensity for assuming they understand what they hear and take it in the simplest of terms. Many of the developers in the IT community are relatively new to the process and lack business and life experience. This limited scope leads to assumptions that later prove to be fatal to a project. Looking at basic human interaction, social culture, and various agreements between people, we find a pattern of communication that is severely lacking in the application development world. That is ALL language used in the process must be clearly understood by all that are involved in the process. OrganizeIt! is a tool that facilitates this process. Any words or terms that are used must be defined and that definition agreed to by all involved in the project. All words that are not understood in the common vernacular or that have domain specific meanings must be clearly defined in the context of the project. The ability to maintain and publish that glossary of terms is critical to the success of any project. Words tend to accumulate loaded meanings in domain specific use, and unless that domain specific knowledge is clear, errors will occur in the development process. In today’s world of staff changes during the project life cycle, valuable information is lost with the transition of personnel. The OrganizeIt! repository becomes the keeper of this information as it evolves and the team changes. This information can be instantly published to rich text format documents or HTML for distribution in printed, e-mail attachment or web based form. At the conclusion of a meeting, the information can be available to all members of the project, world wide in a matter of minutes. This ability has never existed before! Application requirements are built on the language that has been defined. If a word crops up in a requirement that has not been defined; it must be defined and accepted by all segments of the project team. Requirements are statements that define what the application must do. As requirements are defined, business rules surface. Business rules define how the application does what it does. They define the logic behind decisions. Business rules cannot be articulated unless requirements are clear and requirements must have a defined language in which to live. These three very simple steps are very difficult to implement but pay off greatly during the development process. Being well into a project and discovering that a term was not clearly understood or omitted from the discussion will alter requirements, which will have impact on business rules. Retrofitting this new information into the existing architecture may be difficult, expensive in time and dollars or maybe impossible. A universally available repository such as OrganizeIt! makes available an earlier horizon than ever before on the information to users, developers, marketers, technical writers, trainers and help desk staff. With the low cost licensing of OrganizeIt! this information lives on after implementation with the client. OrganizeIt! addresses the first, second, fifth and ninth facets of the development process directly.

The next requirement of the development process is to actually build the application. With more information gathered earlier, we have a clearer target to go after. We deal with the building of an application in a clear, well-defined process. All aspects of the application architecture are defined and documented. With over 40 years of full time application development experience with small to large multi-national firms, we have the benefit of a broad spectrum of applications. We have developed a three level approach to this process. First there are components that are used by most applications. We have built these as reusable (and we DO reuse them) components that have behavior that is controlled by the calling application. Therefore, we don't re-create them for every application. They are under source code control to allow legacy applications to be moved forward if desired as new features are created without breaking the interface contract. This includes a scheme for client specific information, requirements and licensing specifications to be automatically handled. All security, data filtering and much of the printing is integrated into the underlying Genesis Architecture as well. Because of the high degree of abstraction and consistent use of patterns, a large amount of the services needed are supplied by standard components. These components typically make up about 50% of the code in an application. These components understand how to work together and have a clearly defined dependency hierarchy.

The second tool in our arsenal has been developed under the code name Genesis. This project was started back in 1993 using Visual Basic (VB) 3.0. The concept had been in use by our development team since 1976 during the advent of the microcomputer era and on WANG mini computers. But with VB 3.0 and the release of the JET database engine, we were in a place to exploit the ability to use patterns. Using User Defined Types (UDT’s) this methodology was developed and used in several very large projects. We tied the definition of the UDT with structured subroutines and took the first step towards automated, pattern based code generation based on a data model. One implementation was a VB 3.0 project using a JET (Access 1.1) database with over 40 simultaneous connections and record counts reaching the hundreds of thousands and the application ran successfully for several years. They said it couldn’t be done, but we did it. With the release of VB 4.0 and the introduction of OO development within the VB environment, a new era dawned. Genesis has been migrated along with the releases of VB and is now implemented in VB 6.0. The notion of placing the object definition (properties) and all of the necessary logic (methods and events) in one piece of code and being able to generate that code from a developer configurable interface launched the era of intelligent objects. Based on the notion that much of the code written for an application is very repetitive, or at least should be, we loaded these patterns into a Code Inference Engine and allow application specific configuration of the options at the time of creation. Genesis supports ADO as well as DAO code generation. If the needs of the application change or the data model change (seldom happens? – ya, right!), we simply update the data model in its native environment (Access, SyBase, Oracle, etc.) and synchronize it with the Genesis repository and re-generate the objects. The Genesis Code Inference Engine produces code at a rate of 2,000,000+ lines per minute on a Pentium 400 machine. Yes, the number stated is correct. It is not a typo. This code is highly optimized and only contains methods and events that are selected by the developer. The code is also tuned for the specific database specified. All of the code generated by the Genesis Code Inference Engine is also commented with inferred text to help developers using the code understand its place in the application. It should be noted that comment and blank lines are not included in the lines counts mentioned above.

The intelligent objects use a set of proprietary objects to execute common functions and lighten code weight. This architecture stratifies the code into layers that can be updated as needed or technology changes without breaking the application. In most applications, the Genesis created code accounts for about 35% to 45% of the total lines of code, the Genesis components account for about 50% of the code. Between the standard objects and the Genesis created objects, only 5% to 15% of the code is hand written. A portion of that is part of standard components that are customized for the specific application. These standard components include features that are developer configurable such as field background colors based on required or optional data and data validation based on the extended data model with intelligent error messages. Many of the features are behavior that all developers would agree should be in all applications, but schedules just do not allow the inclusion of this type of code complexity. A specific point is that in VB, the creation and destruction of objects, especially if they are a structure of nested objects and collections of objects is very critical to both speed and stability of the application. Genesis insures that the appropriate code is in place based on the object model defined and the features selected. The obvious benefit is that the standard objects are well tested and the Code Inference Engine based on known patterns generates the Genesis objects. All of this code is virtually error free. Debug and test time is dramatically reduced. The behavior is known and the outcome can be readily predicted. The cycle time between updates to the data model or functional requirements is greatly reduced. Genesis produces inferred text to greatly augment the technical and user documentation process. The AnatomizeIt! component of Genesis produces technical code documentation of various types including where used and where called mapping and much more.

A significant feature of the intelligent objects is multi channel support for persistence. Information can be read from one source and written to a different source by the same object. This aids in step 7 of the application development cycle. Data conversion can be accomplished with relative ease.

The combined effect of these tools is that more of the discovery is moved toward the front of the development cycle and can be prototyped, tested and agreed upon by all parties involved in the development process earlier than is possible with any other method. Changes can be tried with less impact on the schedule. Communication and documentation are available throughout the process, rather than at the end or worse yet, not at all.

It can safely be said that if the project fits the profile to benefit from these tools, the budget in time and dollars can be reduced significantly. But the greater benefit is better tuned, more error free code that is well documented and executes faster.