Each year, the application development process becomes more complex as Office and related technologies become more powerful. Additionally, development timelines keep getting shorter and development staffs smaller as a decade of corporate downsizing takes its toll. Mastering the application development role in such a challenging environment requires a formalized, proven, repeatable approach to development. In this chapter, I itemize the formalized approach my company has devised, and show you the following:
A Company with a VIEW
I started my first company when I was 23, mostly because I didn't travel in a circle of friends brave enough to tell me what a silly idea it was to go into business fresh out of college with no business experience. In order to stay afloat, I had to get very organized very quickly.During times when database development work was slow in coming, I spent time organizing my company and planning its future. After awhile, friends were asking me to help them get their small firms organized as well. Eventually, we formalized the process of helping each other get businesses started and organized by founding a non-profit group to help startup companies do business planning. Our group provided free seminars and training for small businesses.
For the training events, I developed a curriculum I called "VIEWing Your Company's Future". I used the acronym VIEW to stand for a four step planning process I designed:
- Visualize. The first step is to "brainstorm"-to visualize all of the possible options for a project or enterprise.
- Investigate. The second step is to explore each of the brainstormed ideas for feasibility-to "flesh out" the details.
- Eliminate. The third step is to remove from consideration or defer those ideas that are not the most practical or profitable.
- Write. The final step is to formalize the project plan in writing.
When I would speak on this methodology to business people, I was surprised by how well-received the concept was. To me, it was simply common sense.From this experience, I learned an important lesson about how people approach complex endeavors-they use outlines and checklists. Business people, programmers, even your children all feel less intimidated by a task when given a simple list of common-sense bullet points to work from.
I survived the early days of PC software development by devising simple methodologies to keep my projects organized (see the sidebar). However, as my company moved into the 90s, software tools and development projects were becoming so complex that simple common sense approaches didn't provide enough structure.
Before Access, my company built most of our applications with only one tool-we chose either R:BASE, dBASE, Clipper, or Visual Basic as the platform for any single project. But when Access came along, we discovered that having both Access and VB in our toolkit let us create applications more powerful and complex than we ever had with a single product.
Not long after the first release of Access, Excel got the Basic language and became its own robust application development tool, and SQL Server became available on Windows NT. It seemed that, suddenly, every few months we were adding another tool to our development environment.
At some point in this evolution, it became apparent to our clients that Microsoft's application-building tools had reached the level where we could create with them complete solutions at the departmental or even enterprise level, and that these solutions would replace the previous applications written with C or Cobol code. Suddenly, we weren't writing simple budgeting databases or spreadsheets, we were creating budgeting environments that included multiple accounting modules, mail merge letters, spreadsheet exports, and links to historical corporate budget data (in short, we were writing "mission-critical" applications with Office).
With these newly complex development tools and projects came the need for a better overall vision of how to develop effective applications, and the Leszynski Development Framework (LDF) was born. LDF is simply a formalized set of objectives, principles, and guidelines that I built to help my staff create quality software solutions.
This chapter introduces the core objectives, principles, and guidelines of LDF. The implementation of the framework (examples of turning the guidelines into methodologies) is explored and documented throughout this book.
In common usage, the term framework refers to an abstraction-a unified set of related concepts. In contrast, a methodology is a set of policies, procedures, processes, techniques, and tools that fit within the framework. One or more methodologies can be derived from or influenced by a single framework. A management team creates a framework and a development team works from a methodology that fits that framework.
For example, the framework for financial accounting in American business is clearly defined. The notion of a chart of accounts, the system of debits and credits, and the reporting concepts of profit/loss and balance sheets are widely stated and understood. However, these is no single methodology used to implement this framework; different accounting departments, CPA firms, and software packages define and use different techniques for applying the concepts found in the framework. In this book, I define the conceptual framework of LDF in this chapter. In the remainder of the book, I include techniques, tools, and templates that fit within the framework, forming the methodology that I use for application development within my own company.
My hope, in sharing LDF with you, is that you use it as a set of base guidelines and expand upon it to create your own team development framework. I also expect you to use the practical methodologies included in this book as examples that you can apply or extend toward your project development efforts.
I sometimes use the terms developer and programmer interchangeably in this chapter and elsewhere in this book to describe someone who creates solutions. In practical terms, however, the term developer actually implies a higher skill set than does programmer. Programmers often worked within a very narrow range of tasks and tools (writing Cobol reports for months on end, for example), while a solution developer (in the LDF sense) must possess the skills to design and deploy solutions in addition to coding them.
LDF or any development philosophy cannot exist in a vacuum. There are certain givens that are central to all application development endeavors and dictate the environment for any methodological approach to working with software tools like Access.
Before describing LDF, let's explore the external factors that affect it. The following list highlights some of the fundamental attributes of the development process. A development style like LDF should attempt to address these aspects of development that are common to all projects:
The needs of the users. Users provide the sparks that ignite each development effort. The needs of the users must be addressed by the solution, or the solution will fail. Thus, accurately capturing and describing users' needs should be addressed by a good development framework.
The use of multiple tools and platforms. You cannot give the users what they need if your tools do not provide the necessary capabilities. A development framework should not prescribe a specific set of tools, otherwise the maxim "When all you have is a hammer, everything looks like a nail" becomes true and you might try to make one tool do everything.
Instead, a framework must support working with multiple tools. Thus, a development style for Access should be part of, or leveraged from, a larger set of style guidelines that apply to related databases (like SQL Server) and related languages (like Visual Basic and Excel VBA).
Current trends in the marketplace. If everyone is writing code a certain way, and you are not, or if you still build a single application database when all other developers are creating a front end/back end mix, your framework is clearly out of step. A development style must recognize trends in the marketplace and be adaptive to them.
One example of this adage is provided by the interface standards established by Microsoft Office applications. The Office interface standard seems to change with each Office release; a framework and its methodologies must be reviewed and modified accordingly at such times.
Other Defined Frameworks. There are good, published techniques for researching users' needs, managing development, and delivering applications. Any framework you adopt or create will have some contrasts and some similarities with these other approaches.
Within one organization, there may actually be multiple defined frameworks with multiple methodologies under them. For example, the PC database development style and the mainframe development style may each be a subset or derivation of a grander, corporate framework for database development.
The next few topics define more clearly these foundation elements within the context of Access application development. Before you can understand the principles of LDF, you must understand the environment that we will apply it.
The users' needs are the top priority. On the surface, this statement sounds like an obvious introduction to any development framework. However, many pressures can cause development projects to stray away from this precept, including
LDF places the users first by recognizing the severity of these pitfalls and by emphasizing developer training and tools to address and correct them. LDF also believes that users must invest their own time and effort in the development process in order to be protected from these pitfalls. See the following section "Element 1-User and Business Requirements" for LDF's approach to these issues.
Lost in the rush to produce new solutions and keep the existing ones running, many developers and IT groups dream about standardizing their development policies, techniques, and tools but never have the time to bring the dream to reality. For them, the next best thing is to cobble together a compendium from guidelines that are publicly available and most closely match their needs.
There is plenty of material available for such an effort. The free exchange of ideas in the Access community gains more and more momentum daily, as the ubiquity of CompuServe as an information focal point is displaced by the Internet, magazines, conferences, user groups, and so on.
Sometimes, as more ideas are exchanged, more consensus develops and developers in aggregate begin to evolve towards the same style. For example, even the simplest Access application these days has separate data (back-end) and interface (front-end) database files. This style was not universally accepted among Access developers in the days of Access 1.0, but it is now.
More often than not, the free exchange of ideas produces more than one good idea on the same topic, and developers divide into camps around the best of these ideas. No clear standard emerges; instead, the market provides a list of good ideas to choose from, without any clear strategy for piecing these ideas together.
Once, accountants suffered from a similar discord and found that they could reduce the confusion in their industry by adopting and applying written guidelines (called Generally Accepted Accounting Principles). GAAP has given accountants a methodology for solving many of their style disputes and a common framework for the presentation of information.
Ideally, a good software development style should do no less. It should synthesize the best of what the market does and pull these ideas together into written guidelines. More importantly, however, it must make the ideas fit together to achieve a common objective or vision. A development standard should also add ideas that take the high road-principles that most developers know they should observe but don't always make the time for. For example, LDF takes this high road by saying "Place a comment block at the top of each procedure" and "Every project should have a written specification".
The first step toward a GAAP-like standard for Access developers is for someone to provide ideas that synthesize the generally accepted development conventions. LDF does this and creates a list that can be used as a focal point for debate among developers. Active discussion of the ideas here will help this framework evolve into a consensus document on application development precepts.
Access is almost always at a pivotal location in applications where it's a component. However, this pivotal role can become either larger or smaller over time. Thus, any understanding of how Access fits into a project must be tempered by an understanding of the entire life cycle of the project and Access' changing role throughout that life cycle.
At one end of the spectrum, consider a departmental application for tracking information about shippers and shipping rates. The application has a central database and five users. Users enter information into shipper and pricing tables and run queries to determine the best shipper to use for a specific shipment, based on a combination of cost and locale. Access is very good at solutions like this, and if the department does not grow rapidly the needs don't change dramatically, this standalone application can go through its five year life span virtually unchanged.
An example like this provides fodder for developers who ask "Why do I need a development methodology? I can hack out a quick solution to this shipping data problem using any development style or none at all. Besides, I'll be around for the next five years to debug it if something goes wrong." It is quite hard to argue with such a utilitarian attitude given these facts, so I'll capitulate and admit that this developer's attitude serves him well in this scenario. However, very few applications live in such a vacuum where the users can guarantee that their needs won't change, and the developer can guarantee that he won't leave.
Exploring the other end of the continuum, imagine a departmental budgeting application that is distributed to all five departments in a company. These departments share a single database but will each have a slightly different interface to match their unique budgeting requirements. This application has complex needs such as data validation and auditing, segmentation of features and data ownership by department, reporting that produces detailed budget spreadsheets, and links to corporate accounting data.
Clearly, this type of application cannot simply be slapped together as in the previous example. Access' role in this project is not as the only component but rather as a facilitator, bringing together information from, or serving data to, several external components. Developers working on an application in this capacity must understand how to augment Access with other tools and how to have Access provide the best interaction with these other tools.
Consequently, understanding the role of Access in a project like this one involves:
Viewed at a conceptual level, development of this complex project would be more successful if guided by a framework that takes into account the many facets of Access-centric database solutions. A good development framework can help you create large solutions by providing a direction for each of the critical tasks in creating the solution: research, design, management, coding, deployment, and enhancement.
In 1993, Microsoft created a definition of Office compatibility and a set of criteria for software that is qualified to wear this mantle. Access applications can be sent to a testing lab and receive certification as Office Compatible (OC). This certification enables the application to display the OC logo, an advantageous marketing attribute for a retail application.
To find out about the requirements for certifying your applications as Office Compatible, send an e-mail with your information request to email@example.com. If you are creating an add-in, tool, or industry-specific application that will be sold in the retail marketplace, membership in this program can provide substantial marketing benefits.
Should developers that aren't doing retail applications care about Office Compatible? In terms of the actual certification process, no. However, the OC specification provides some guidelines for building Windows-style interfaces; these guidelines can be used as a framework for designing Access application interfaces.
Unfortunately, OC doesn't outline database-specific application interfaces and provides no guidelines for interface issues involved in creating, editing, saving, and searching for records. Thus, developers must extend OC by creating their own guidelines for situations that OC doesn't discuss.
Chapter 8, "Designing Effective Interfaces," discusses the Office Compatible guidelines in more detail and discusses how to supplement them with interface guidelines for your database-centric applications. The general tenet of OC, that Access application interfaces should look and feel like other Windows applications, has been incorporated into LDF and should be incorporated into your solutions.
The Microsoft Solutions Framework (MSF) is the mindset employed and taught by Microsoft Consulting Services. Microsoft defines MSF as "the reference guide for building and deploying distributed enterprise systems based on Microsoft tools and technologies."
MSF provides a well-defined framework that describes development as a process, meaning that MSF enumerates high-level guidelines that provide structure to the development of your own internal methodology. MSF is not a methodology itself, because it does not include policy documents, tools, reusable objects, templates, or similar components.
MSF is based on several core concepts, including
If you are not familiar with this three-tier layering model, see Chapter 7, "Understanding Application Architecture," for a description.
MSF does not conflict with LDF. In fact, the two frameworks coexist just fine, because MSF is at a higher level than LDF. MSF can work for smaller projects and development teams but is not tuned for them. It was derived from experiences on very large projects inside Microsoft and their largest customer companies.
LDF, by contrast, is structured for development teams of one to ten people, working on projects taking hundreds of hours instead of thousands. Over the long term, as MSF and LDF both expand to include wider audiences and a broader range of projects, they will overlap or possibly even collide, but Access developers should still be able to benefit from elements of both.
So far in this chapter, I've laid some of the groundwork for the Leszynski Development Framework by clarifying the unique environmental factors that provide its foundation. To summarize, these are the pervasive factors in Access application development that LDF deems important:
LDF takes these base assumptions and builds upon and around them, applying these two attitudes to each: common sense and consistency.
If you are a sophisticated developer, to hear me say that every project should have a design document, and that every design process should include a representative sample of actual users, seems like I'm stating the obvious. It should be obvious to you if you've been developing for awhile, but remember, pearls of wisdom like this are not obvious until you have tried the alternative approaches and failed with them. New developers that have not yet been through the trial-and-error process can be saved some distress by applying a framework that bypasses it.
LDF attempts to distill the sometimes-complex development process into a set of simple guidelines and techniques that read much like everyday common sense. In this respect, LDF provides a middle-ground between the extremes that frameworks often drift toward:
LDF adheres to the middle-ground and a common-sense kernel by passing all of its concepts through the following filter:
It would be easy for me to reduce LDF to a ten-point bulleted list of common-sense approaches to Access development. However, at this level you would have only a teaser, rather than a complete fabric of information that you could actually use. Ultimately all developers want more than just a sneak peek.
At the other end of the spectrum, I could summarize every one of the individual ideas and tips in this book into a bulleted LDF outline that would span dozens of pages. This approach would be counterproductive to the nature of the framework, by providing excessive detail and leaving no discretion to developers in the use of its principles.
I've struck a middle ground instead of either of these options. My framework provides statements and objectives, and this book provides examples of implementations of the principles. Taken as a whole, you can use my ideas to guide much of your development process, or you can simply use them as seeds for the creation of your own guidelines.
The purpose of any framework is to pull together related concepts and to make them work harmoniously. The roots of LDF are in our actual application development experiences. The pieces fit together not because they've been forced, but because they reflect the actual development environment that my staff and I have created around us. Thus, the laboratory for my concepts is my consulting company, and none of our ideas escape from the lab until they have been through the "clinical trials" of hands-on use.
This brings to LDF a healthy consistency and a lack of gaps or inherent contradictions. It also enables LDF to move beyond the theoretical to the practical.
For example, many development styles include these two maxims:
Both of these common guidelines are noble and useful, and each is a part of LDF. However, when you apply these concepts in the real world, an evolution occurs that creates a third point:
The third point is a consistent and logical outflow of the first two. Further, this book attempts to be consistent in its efforts to demonstrate LDF to you with practical examples. Thus, Chapter 20, "Applying Development Shortcuts," gives you specific techniques that you can use to apply the three LDF principles listed above to your own work, by describing how to
Professionals in any field will tell you that the path to success is to find a system that works and to continually refine it toward a state of perfection. As you sit reading this, my staff is continuing to use and refine LDF toward that lofty state.
The fact that this entire book is a living example of LDF makes it hard for me to distill the framework into one single section. My staff learns LDF not simply by reading bulleted lists and policy documents, but through team meetings, client interaction, training sessions, and hands-on implementation. Nevertheless, you do not have the luxury of dropping by my office, so I must enumerate the essence of LDF in the remainder of this chapter. LDF is best expressed by the model shown in Figure 2.1.
This diagram graphically reflects the composition of the Leszynski Development Framework.
I call each of the segments of the diagram in Figure 2.1 an element. One element does not equate to one group of people or one block of processes. Instead, one element is a collection of concepts that are related to each other. Taken together, the six elements include all of the primary notions that I believe are critical to application development:
Each of these elements is described in much greater detail in the pages that follow. A document that summarizes LDF and that can be used as a starting point for evolving LDF to fit your development environment is found on the CD-ROM as LDF-SUMM.DOC.
I've chosen the triangular layout of the LDF diagram to emphasize two points:
The remainder of this chapter details the six elements of the Leszynski Development Framework diagram. Each element in LDF is exemplified by precepts, or statements that convey an objective, fact or guideline. Not all precepts apply to every project, and you do not need to agree with all precepts in order to derive value from its parent element or from the framework.
LDF attempts to keep precepts at a broad level because they provide guidelines for behavior without necessarily specifying the actual behavior itself. For example, Element 2, Design Precept 3 states that "Every project should have a written plan." This precept provides a rule without specifying an implementation strategy to fulfill it, so you need to create your own execution blueprint for this guideline or utilize the examples I provide in Chapter 4, "Creating Design Specifications," and Appendix B, "Design Specifications-A Detailed Outline."
This element of LDF is placed at the top of the diagram for a reason. LDF adheres strongly to the belief that all automated solutions should be driven by a clearly defined set of user requirements, and that these should dovetail into the larger needs of the business.
User and business requirements drive solutions.
User Requirement Precepts
Some development projects start with a user or users stating a set of needs to the development team. Other development efforts are the brainchild of Information Technology staffers who see a shortcoming in a current business system. Still other solutions are (wrongly) implemented because someone got excited about applying an interesting new technology to a workgroup. It doesn't matter who conceives of the need, but it does matter who defines the need. Users must be actively involved in the design and review process of an automated solution, from conception through deployment, and the business management layer that pays for the solution must require that the project be cost justified before it is begun.
Step One for a new development project is when someone says one of the following:
The core of any automated solution must be a human or business need (or both). The success of the automation project depends on the degree that the needs are properly defined before starting and how well they are satisfied after completion.
LDF requires that developers stay focused on the users' needs and the needs of their company during design and development. This focus helps to keep coders from taking technology tangents, introducing ad-hoc feature redesigns, and other common distractions. A solution process that begins with the third phrase in the previous list is likely to fail, because a fascination with technology, as opposed to a defined user or business need, is driving the solution design process. Thus, this precept really is saying: All solutions must start with a defined need rather than a fascination with technology or a sales call from a vendor.
When users have defined their needs as a new project concept, the users' manager and the development manager must prioritize the concept against other pending projects in the same budgetary unit (workgroup, department, or similar segment). No company can afford to implement all good ideas; trade-offs must always be made to allocate finite budgets and manpower to the most pressing needs.
In addition to weighing the proposed project against other proposed development efforts, managers should try to weigh each need within the project against the other needs. As the user requirements are defined, the weighting must be maintained so that it is easier to decide which features will be kept and which deferred if inadequate funds are available to satisfy all listed needs. Many projects die of bloat by trying to do too much with too little time and money.
Users must commit an up-front effort to define their problems, needs, hopes, and objectives in detail at the beginning of the research phase. Developers can lead users astray with technology tangents that cause a project to stray from the original vision. This situation is less likely if the vision is clearly specified early on.
When defining the project objectives, try to withhold discussion of tools, technologies, budgets, and other constricting facts. Design an ideal system first, unencumbered by constraining factors, then fit the solution to budget realities later.
Several problem-definition steps occur early in project planning:
These and other steps in the design process are detailed in Chapter 3, "Preparing for Development."
The user is unlikely to utilize a solution that does not solve the defined business problem no matter how powerful, easy to use, or well-designed it is. A system that "misses the mark," even slightly, with respect to the users' defined needs falls into disuse almost immediately.
Consider how often you, as a developer, purchase tools and utilities to assist you with your work, only to find them missing a feature you deem critical. You quickly reduce or remove your dependence on the tool once you have found its fatal flaw. Remember that users respond to your application with very similar behavior.
Business Requirement Precepts
A development project must feed one of the company's strategic objectives, such as "Reduce head count" or "Improve customer satisfaction," in addition to a defined set of user needs. Otherwise, the application will be branded rogue and its users selfish due to the lack of tie-in with larger objectives.
After defining the users' needs for a new project, test the defined needs against the department's or company's overall needs. A project can be successful in the short term if it fits the needs of a workgroup, but it cannot be successful in the long run unless it fits a broader need or objective.
Users must help developers understand how their proposed solution fits into the big picture and must be able to justify the project to those up the corporate hierarchy at higher levels.
In the current climate of rapid and regular business reorganizations, a project in process can quickly be swept away into oblivion by the tide of restructuring. This point reinforces the precept that a project that feeds the corporate vision has greater longevity and support in high places than one that serves a compartmentalized need.
Determine who the highest-level beneficiary of a project in the company is; then involve that person in the project. If the solution project hits a political or financial roadblock later, the blockage will often be cleared quickly by the highly-placed champion.
I call the highest-level beneficiary of an application the ultimate user, as defined further in Chapter 3, "Preparing for Development." An example of the highest-level beneficiary is the manager of the department that initiates the project, or perhaps an executive that will use reports produced by the proposed system.
A thorough analysis and design effort is a critical factor in the success of most projects. When done well, it launches the project ship riding high in the water; when done poorly or skipped, the project begins sinking before it even leaves port.
A thorough analysis and design is critical.
Analysis Process Precepts
The analysis of existing processes and research into users' needs is often maligned. Developers and users both find it tedious. Executives don't understand why it takes so long to define the solution to an obvious problem, so the definition phase is often under-funded. Yet, the solution surgeons may operate on the wrong problem if they don't perform the proper diagnostic procedures.
A design effort must be done by a design team. Such a team usually includes core members (developers and user representatives) and peripheral members (user and management reviewers).
Much of the success of a project relates directly to the quality of its design team. Here are five keys to composing a successful design team:
In LDF, the design process includes participation by and input from each of these parties:
These roles and their responsibilities are described in detail in "Selecting the Players" in Chapter 3, "Preparing for Development."
There is a correct way and a wrong way to do research. The success of a research effort depends on the level of organization of the researchers, their ability to meticulously dissect processes, and their political skills when interviewing affected parties.
The key pitfalls to avoid in a research and design effort are:
LDF provides three models for performing automated solution research:
See "Researching Automated Solutions" in Chapter 3, "Preparing for Development," for clarification of these research models.
Whenever possible, the discussion of development tools should come late in the design process. Early in the design process, focus on the problem being solved, not on the technology that will be used to solve it.
In smaller organizations, Access may be the tool of choice and your project design will be constrained by its selection from the outset. Larger organizations, however, will have several layers of standards:
Developers may have an inkling of the appropriate tool or tool mix for a particular project early in the design phase but should not express this bias to the users or let the bias affect the research and design process. See "Selecting the Tools" in Chapter 3, "Preparing for Development," for more information on determining the development platform.
System Design Precepts
Developers without a plan are wanderers in the solution development desert, looking for a direction. A strong, written design specification document is one of the core elements of LDF. The document must be comprehensive and clear.
A project that begins by pointing in the wrong direction ends up in the wrong location. To create a quality solution, the users92' needs must be accurately defined and the system design must describe an application that fills these needs.
Users must be encouraged to vocalize all of their thoughts and perceptions related to a proposed solution, without fear of ridicule by the development team, fellow workers, or management. Developers, on the other hand, must remain attentive during the processes of brainstorming, research, and specification writing-the tasks that historically bore many programmers.
In addition, the developers writing the project plan must have the skill set necessary to produce an accurate, technically feasible plan that solves the business problem as defined by the users.
The backbone of a database project is a set of data records. If the data records are flawed, the entire database may be worthless. Imagine an order database with a field for credit card number but missing an expiration date field? Or picture how databases that use two-digit years in their records will not be able to adapt to the turn of the century coming just around the corner.
Forms are easier to change than data and reports easier than forms. Data structures are the hardest component to change in a deployed system; so make certain that the table structures are accurate the first time around.
Developers and users bring distinctly different skills and perceptions to the design table. To presume that each group understands what the other is saying is as dangerous as assuming that parents and their teenagers communicate from the same mindset.
A common rapid application development scenario involves users giving a developer a spreadsheet of data and some hand-drawn reports, and saying this: "Move the spreadsheet data to a database, create an entry form, and add a report that looks like this spreadsheet." To some developers, this qualifies as a written plan, but LDF is more demanding than such developers.
Developers and users have a better chance of minimizing misunderstanding and disagreement when they all work from the same written plan. Every development project has a minimum set of information that should be either researched in detail, or discussed and dismissed. See Chapter 4, "Creating Design Specifications," and Appendix B, "Design Specifications-A Detailed Outline," for a complete discourse on these elements and the layout of a good written design specification.
Most applications follow a somewhat generic evolutionary path as their life span progresses. Good applications are built to support an easy migration to each new level of that evolution, and every application should have a long term (multi-year) growth or maintenance plan.
An application that is built with a short time window in mind often suffers from a near-sighted design process and is antiquated when the time window expires. With an architecture that is not extensible, such an application may cost more to revise than to simply replace (rewrite).
In contrast, if an application is engineered to grow, moving it from one stage in its life cycle to the next stage requires a process of extension, but not renovation.
Here are the ten LDF stages in the average life cycle of a database-centric application, as described fully in "Understanding an Application's Life Cycle" in Chapter 3, "Preparing for Development":
Many developers think that a project is completed when it gets into the hands of the users (stage 5 on this list). However, you'll note from the list that the fifth stage is only halfway through a good application's life cycle. The more of these stages that are defined in the original project plan, the more likely the application will be well-constructed and evolve smoothly into each new stage.
LDF places high value on user involvement in most facets of the design, development, testing, and deployment process. Users can be an extension of the development team, as well as its masters.
In the course of system design, developers are often inclined to take seeds (ideas, problems, or process descriptions) from the users and to define the solution from these seeds, deserting the users when issues arise that present complex decision points. LDF states that it is better to stop and educate the users on issues that are important to them, and involve them in the decision process, than to act as their proxy.
If the users' sense of ownership and participation in the design process begins to lessen, so does their commitment to the overall success of the project. Also, their ability to successfully blame the developers for every problem throughout the project is enhanced when developers shoo them away and create the application autonomously.
One good diagram is worth a thousand words, or more. Throughout the design process and in the written plan, use drawings and diagrams to clarify key concepts. Visual aids are proven to stimulate the creative process, communicate difficult concepts, and guide discussions in group meetings.
Consider these points, as elaborated in Chapter 3, "Preparing for Development," Chapter 4, "Creating Design Specifications," and Appendix B, "Design Specifications-A Detailed Outline":
Each of these diagrams should be prominently included in the specification document.
A design effort must be budgeted separately from a development effort. This ensures that researching and writing a plan is itself a project, complete with its own team, management, milestones, and deliverable (a specification document). This also ensures that the research effort explores multiple options for resolving the stated problem or need, because the planners' judgment is not clouded with the foreknowledge of the target development budget or timeline.
When following the LDF research and design model, the design budget for a project is usually at least 10 percent of the overall project cost. See Chapter 4, "Creating Design Specifications," for information on how to cost-justify the design effort.
Establishing the development budget before the research begins automatically limits the scope of the design team's vision and places blinders on the research process. Instead, the research effort should proceed as if development money were unlimited (or at least ample), with an eye toward designing the best possible solution to the problem. Then, at the end of the design process, the budgetary realities are introduced, and three determinations are made in order to fit the design and the budget together:
Witness my careful choice of words in the second point. No feature that is dear to the users should ever be canceled, which removes it from consideration and the design plan. Instead, features that are not affordable now are "deferred indefinitely," which keeps them in the plan for future review and resuscitation if economics change later.
It's important to understand the ramifications of the third point. Some developers scoff when I state that design discussions should downplay budget realities. They feel that it is wasteful of effort to discuss a feature that the users can obviously not afford.
I see the situation differently. The purpose of a design phase is to define a problem and its possible solutions. Stifling discussion during design meetings is a bad idea. Many times I have seen users describe some grandiose feature that they clearly cannot afford, only to hear another member of the design team redefine the need or the application's approach to it and concoct an affordable alternative. Without an environment that encourages free and open debate, the design phase will not be comprehensive.
Chapter 4, "Creating Design Specifications," provides a thorough discussion of budgeting in the section "Budgeting From a Specification."
Do not presume that the data you key into a Jet database will always reside only in that Jet database. Data that has value often migrates into other database platforms, analytical tools, and storage structures. Thus, you must carefully weigh any aspects of a database layout that decrease its portability.
Here are two examples of data structures that are limiting to migration:
As part of Chapter 6, "Leszynski Naming Conventions for Access," I discuss how to keep object names portable between Access/Jet and SQL Server.
Today's critical information may be tomorrow's minutiae, and data taken for granted when collected may provide a wealth of information at some point in the future. It is not always possible to accurately predict the future value of today's collected data.
As a consequence, LDF maintains that no valid data should ever be discarded. Records are not deleted, they are archived. See my discussions of archive tables and data warehouses in Chapter 7, "Understanding Application Architecture," for more information on LDF's obsession with saving copies of every data item.
Also, as critical information is modified, consider making backup copies of the affected records before the changes are made. Chapter 15, "Protecting and Validating Data," exemplifies this with an illustration of archiving deleted records.
Most applications are used by people with diverse computer skills. Developers must be aware of the spectrum of users' skills and abilities when designing a system's interface. An application's design must focus on creating a tool that can be mastered by anyone in the user community, not a tool that is only comprehensive to developers and power users.
Forms are the primary user interface element in an application, thus techniques for maximizing usability under this precept will usually apply to forms. Chapters 13, "Mastering Combo and List Boxes," through 17, "Bulletproofing Your Application Interface," expand this precept into hands-on techniques for building forms that are powerful yet highly usable.
The application rubber meets the road here. After days or months of planning, debate, and definition, the development effort begins. LDF views management personnel and development personnel as two legs of the project's structure; if both legs are not present and solid, the project can not stand up.
Management and development support a project's structure.
Project Management Precepts
PC database projects often have no hands-on management personnel. Instead, one or a handful of developers are beholden directly to the users for their inputs, motivation, and feedback. LDF maintains that full-time developers should not manage the workflow like this, nor directly control the budgeting, milestones and delivery of an application.
The following points refer specifically to the management of the development process and its team.
Small applications can be created by a single person. In many corporate departments, one PC support person provides both hardware and software support, and his or her job definition may include creating database applications. But however tempting it is to enable a person like this to solo on a project, LDF maintains that the smallest logical team for a development effort has these three roles:
In some cases, the role of project manager and development manager fall on the same person, which can work fine if the project manager is technically sophisticated (see the following precept).
If the opinions of readers of this book reflect the composition of developers in the real world, they are fairly evenly divided between the beliefs that the leader of a development team should be an outstanding business manager or a brilliant technologist.
Of course, someone with both talents is automatically qualified for the position, and such a combination is preferred in a development manager. Assuming, however, that such a joint skill set is rare, LDF chooses to weight the technology bent as a higher factor than the management skills.
Why? Consider the example of the military. Never are civilians brought in and made into generals. Working your way through the ranks is the only valid course of advancement that earns you the respect of your peers and crew, and provides you with an understanding of the processes and people you must control.
So it is with development teams. There is little regard in programming circles for management personnel at all and even less for development managers who have not themselves been developers. Thus, the natural job path for a development manager is up through the ranks of development. Having reached the management role, the manager should not forswear all coding, at the risk of getting out of touch with the needs of the development staff and the options for the users.
A quick reading of the prior precept might lead you to believe that the development manager should also be a developer, but LDF maintains the such a position is best filled by an ex-developer. The development manager should have a development background and should still dabble with technology, in order to properly understand the processes used to create solutions.
However, a development manager should be involved in only a small amount of actual current development. Fulfilling development responsibilities in addition to business responsibilities tends to give a manager two conflicting job roles. Of the two roles, management is the more important one.
While they may not participate in the actual development of mission-critical code, managers should be part of the review process for code and architecture, as detailed in Chapter 9, "Completing and Deploying a Solution."
Most developers define or innately follow a fairly consistent development style. The style will have repeatable techniques and guidelines; some of them will probably be quite detailed. For example, Chapter 20, "Applying Development Shortcuts," describes several methodologies for controlling application object versions in a multi-developer environment. Most development teams will follow one of the methodologies described in that chapter and employ a fairly detailed team development policy.
However, it would not be appropriate for LDF to prescribe one version control methodology over another. In keeping with the synopsis nature of LDF precepts, the development principles reflected in this element are at a high level and do not concern themselves with implementation details.
The core application processes (data management routines such as end-of-month postings) are the hardest elements of a system to design, write, and test. Because these processes can evolve as they are developed, you should not finalize an interface before creating the processes it surrounds.
LDF encourages an early focus on the interface in order to facilitate user reviews and feedback (see the "Prototyping" section of Chapter 3, "Preparing for Development"). However, this is only to solidify the interface from a layout standpoint; it is difficult for users to finalize an interface until its processes are completed.
If significant development resources are available, it is possible to code interfaces and processes in parallel, with the developers sharing information closely. If not, the team must code interfaces in rings around the processes, bringing each process to a state of solidity first, then developing its related interfaces.
This precept is akin to eating the dessert after the meal (saving the best for last). Many developers find form and report development faster and more rewarding (the dessert) than slogging through core processes (the meal) and do this fun work first. This precept ensures that developers finish all of their broccoli before starting on the ice cream.
Consistency of development style, as touted by the focus on standards in the Skills and Standards element of LDF, is only half of the development equation. An equally important area of focus is consistent management of the development process and the players in it.
Coding assignments must be delegated in a way that balances the skills currently held by each of the development team members against the skills that they may want or need to acquire during the current project. A development manager must deftly juggle the skills and schedules of the team members and also the project's deliverables and milestones. Creating a reliable model for delegation and coordination of all these tasks can improve the harmonious functioning of the team. These intricacies of project management are detailed further in Chapter 9, "Completing and Deploying a Solution."
Creating code and application objects can be a joyous creative effort one day and a tedious debugging morass the next. Developers are more successful in surmounting the tangents, distractions, and pitfalls of coding if they stay focused on specific objectives.
Project tasks should be doled-out in bite-size chunks, with reasonable and regular milestones attached. Milestones for team members should mesh so that, at various intervals, team members can meet to review progress and note specific components that have been completed. Identifying component completion as it occurs allows the unit testing process to occur parallel with the development effort, which very favorably impacts development timelines.
The management of milestones is discussed in Chapter 9, "Completing and Deploying a Solution."
Solutions that look great on paper must, when implemented, conform to the reality of the infrastructure on which they depend. The capabilities of the tools, languages, operating systems, and other environmental elements have a significant impact on the actual implemented solution.
Tools and platforms
LDF can apply in many different development environments, but it is obviously a database-focused framework. Presuming that you use Jet and Access for data and interface services, you may or may not require any additional tools to complete the solution.
Too many programmers love to burden applications with gadgets, widgets, and good-looking extensions that ultimately slow the solution down more than they increase productivity. Developers must resist both their urges, and those of the users, to employ application devices that have a negative performance impact such as voice, video, large or complex graphics, and some types of ActiveX controls. This is especially true where reasonable alternatives exist.
A good example of the scenario mentioned in the preceding paragraph was found in tabbed forms. While alternatives to a tabbed layout (toggling control visibility or using multiple pages) have always existed in Access, many developers insisted on trying to emulate tabs with graphics or ActiveX controls because it made forms more attractive. Such efforts usually were quirky or slow. Fortunately, this struggle was not lost on Microsoft, and we inherited an intrinsic tab control with Access 97.
Developers must make conscious performance tradeoffs when enabling user features. For example, on slower machines, the negative performance impact of operations like sending e-mail messages in the background from a database application may require a creative but equally functional alternative approach, such as writing messages to a table and sending all queued messages late at night.
As a tool builder by nature (read Chapter 20, "Applying Development Shortcuts"), LDF reflects my inherent bias with respect to automating the development process. It is absolutely true that home-made tools are more expensive than retail tools, in the first use. However, the real cost is measured over the long-term, not up front.
Consider why custom solutions are developed:
If you are the developer of such a custom solution, why would you choose to suffer the ills that you protect your users from (compromising on features and not having ownership of code) by purchasing and using retail tools that don't work precisely as your needs dictate?
There are, of course, plenty of good tools on the market that may match your needs precisely. LDF doesn't argue against purchasing a tool that does exactly what you need, only against compromising with a less-than-perfect match if you are capable of writing your own tool in-house.
Because Access is not a cross-platform solution, the developer knows much about the environment that an application will be deployed in without ever asking the users. Windows, Office, MAPI, and other environmental factors can usually be assumed as a given. Nevertheless, developers must still consider the various configurations of machinery and connectivity when creating the solution.
We frequently see companies spend thirty to fifty thousand dollars on a custom solution, only to load it onto 486 computers with 8M of memory. In this scenario, users are waiting (and waiting, and waiting...) for each application process to complete. A company that budgets hundreds of thousands of dollars for mainframe memory and does not spend a few thousand dollars on PC RAM is wasting valuable human capital, by forcing people to wait for their machines.
Assume that an average worker costs a company $40,000 each year in wages and benefits and spends all day working on the computer. Suppose also that purchasing a new computer for this worker costs $5,000. The worker would need to produce 12.5 percent more work each year (5,000 divided into 40,000) to recoup the cost of the machine in one year. In an environment where each PC upgrade nets the buyer an average computing speed increase of 100 percent, it does not seem hard to justify the purchase of new equipment based on this math.
The platform and infrastructure that the application ride must treat the data with the seriousness that it deserves. Database records are often mission-critical, and the databases that contain them must be adequately supported by the users' hardware.
LDF maintains that the network infrastructure for a database application must provide these features:
As with any other team of people working together, a development team needs a clear set of policies and standards to apply to their work. Only minor variances of coding and architectural styles, and sometimes development skills, can be tolerated if the team is to succeed collectively.
A development team needs clear policies and standards.
The goal of this standardization effort can be exemplified as follows: four developers, using the published style for their development team, could each work on a quarter of an application. When their components were combined, the application would have a single, consistent appearance to all of the objects and code.
Developer Skills Precepts
No framework can legitimately mandate that only expert coders work on a project; we all have to start at the bottom of the skills ladder and work up. However, LDF does expect that policies will be created to help elevate the skill levels of all developers on a team, with an eye toward building a balanced staff of experts.
Fundamental to LDF is the belief that solution developers must have a broader knowledge base than simply writing code. Just as a doctor must learn anatomy, someone who solves business problems for a living should understand how business processes work.
LDF's leaning in this respect can be summarized this way:
As team members move from programmers to analysts to consultants to psychologists, they evolve from the ability to code what is in a specification to the ability to truly understand how people work and how to automate it. They become able to envision the problems an application will solve and to suggest enhancements to processes and application designs, and can then offer alternative solutions in the course of development. A careful reading of Part I of this book, "The Leszynski Development Framework," can help you to move up the skills ladder this way.
How do you maintain a high-quality and balanced development team? By setting and testing against skill level hurdles. Ideally, both new hires and existing team members can be challenged with creative examinations or tasks that demonstrate the areas that are ripe for improvement.
Aptitude tests for programmers are a bit awkward to create and apply. The most successful means for measuring aptitude and charting areas for improvement that I've found are these:
This review process is not solely relevant to skills enhancement; code reviews should be a regular part of the quality assurance process when building applications.
Chapter 9, "Completing and Deploying a Solution," discusses these types of reviews in more detail.
Of course, another type of skill review comes from the users of the application, who find its feature deficiencies and application bugs. The nature of these deficiencies and defects speaks volumes about the skills and motivation of the programmers that created them.
Developers usually learn on the job. All too often, developers are thrust into a project in progress on their first day of work and given immediate milestones to achieve. The pressure of such a situation is not conducive to a quality learning experience.
As an alternative, companies can send new (and existing) team members to expensive classes and conferences for training. If the quality of information provided by such an event is marginal, as many are, the company loses twice: the developer is dispirited, and the team has lost productive time.
In between these extremes, teams must place a high priority on contriving a training model that is cost- and time-efficient and make sure that developers who are eager to move themselves up the skills ladder are given the effective tools and reviews to do so.
In my company, we've found that developers receive enormous value from teaching each other new skills that are appropriate to our specific projects and tool mix. We hold a "teach-in" each Friday, where one developer trains the rest of the team on a specific skill targeted in advance as an area of current need.
Development Standards Precepts
LDF maintains that development teams should apply rigorous discipline to the creation and implementation of a uniform development style throughout the team, and if possible, throughout the organization.
The LDF position on the value of a consistent object naming strategy is made apparent in Chapter 5, "Creating Naming Conventions," Chapter 6, "Leszynski Naming Conventions for Access," and in Appendix C, "Leszynski Naming Conventions for Microsoft Solution Developers." One of the core principles of LDF is that any developer should be able to understand code and objects created by any other developer on the same team.
In addition to object names, development conventions can specify common standards for code layout (see Chapter 11, "Expert Approaches to VBA") and for coding techniques (see Chapter 20, "Applying Development Shortcuts").
Development team members must implement the architecture of a solution based on a commonly accepted model for the team. How objects are built, where they are located, and how they communicate with each other must not be determined on a per-object, per-project basis.
Here are simple examples of important architectural considerations:
These and other application architecture concepts are detailed in Chapter 7, "Understanding Application Architecture."
Companies should create a style guide that determines the standards for the look and feel of forms, reports, alerts, and other user interface elements. The guide should include specifications for the visual presentation of application elements. Here is an example of some areas that should be included:
Chapter 8, "Designing Effective Interfaces," and Chapter 16, "Presenting Data To Users," each contain detailed discussions of application interface element standardization.
Very few companies run on a single application or a single developer. Instead, multiple solutions are created by multiple coders. The challenge in this environment is for each application to work like each other one (as much as is practical). Companies and their users are both affected negatively if each application requires a significant retraining of users to understand the construction, navigation model, and usage.
LDF suggests that development teams create standards for how users interact with application objects and base these standards on generally accepted interface standards where applicable. See Chapter 14, "Navigating in Forms and Applications," for examples of this precept in action.
Many coding projects are executed in a state of chaos. Developers (and sadly, even development managers) are often so focused on their technology, the project timelines, or the budding solution that they forget to apply appropriate controls and techniques for smoothing development and deployment.
LDF suggests that development teams pay attention to defining organizational techniques that can prevent emergencies and distractions. A consistent operational model for the development environment that prescribes how to backup source code, manage ownership of objects, configure a development workstation, and organize a code repository can provide a critical layer of organization for the entire team.
Development standards must be written down or available in online resources like help files or Web pages. Create a standards document, index it, publish it, distribute it, and subject it to regular review and feedback. Treat is as your Developer's Handbook.
Your document should explain not only the What of the style, but also the Why-for each element of the style, note why that element is logical and necessary.
With the availability of inexpensive tools to create online documentation (viewers, readers, help compilers, multimedia authoring systems, and Office's new Web publishing features), development teams have few excuses left for not having their development policies and examples available interactively for the benefit of the entire team.
Team leaders and development managers must be charged not only with creating a compendium of policies and procedures for all developers, but with enforcing the policies.
Each team must determine which development conventions are important to enforce. Here are examples of standards that foster the objective of consistency across a team:
Other examples of development styles and standards are found scattered throughout this book.
Debates on standardization can go on almost forever; thus, creating standards as a team is not always practical. Nevertheless, a written draft of any proposed standards should be reviewed by all developers or a carefully-selected representative sample. Software developers are among the most apolitical of all creatures and many bristle when standards created higher up are forced upon them.
As defined in Chapter 3, "Preparing for Development," an application's useful life is usually measured in years, with multiple revisions occurring along the way. LDF maintains that half or even less of a total project's time and monetary outlay is applied to the first release. As a result, developers must stay committed to the success of a project long after the last line of code for version 1.0 is completed. The development team must shepherd or participate in the deployment and installation of the solution, and in its ongoing maintenance.
Deployment and refinement
Preparing to ship an application to users brings with it the elation of a milestone (code complete) achieved, but also the burdens of testing, documentation, setup, and training. Depending on the size of the development team, coders may not be involved in these efforts. In smaller firms, however, it is likely that the development and deployment teams include the same people.
Never, ever, let the person who coded a routine act as the only tester for that process. Developers in general are not very good testers, and a developer testing his or her own code should be the first line of defense only, never the last one.
Some people are simply born to test. They try the oddest combinations of interaction with the application; they seem to be able to sniff out bugs with their eyes closed, and they have a critical eye for consistency. People like this should be sought out, cultivated, and revered by development teams, because having a knack for testing is truly a rare gift.
Chapter 9, "Completing and Deploying a Solution," discusses this testing personality and the testing process in significant detail.
For any size project, involve some of the users in the testing process for the application. Many developers dismiss users as too unsophisticated to be good testers, or too difficult to manage as a test team. However, such developers overlook the many benefits provided by the participation of users.
Similarly, users can sometimes effectively assist each other with application setup and training, offloading some of these responsibilities from the development team.
Chapter 9, "Completing and Deploying a Solution," details the value of user participation in deployment, and how to manage the process.
Ten years ago, many Information Technology department workers tied their sense of worth and job satisfaction to the degree of dependence between the users and them. A phone constantly ringing with bug reports, training requests, and change orders was seen as a status symbol.
Today, most developers would rather focus on building new solutions and learning new technologies than maintaining old ones, and thus are motivated to minimize the distractions they get from users. A combination of good training, solid applications, a high quality design team, wise testing processes, and smart development policies and tools can make this happen.
See Chapter 8, "Designing Effective Interfaces," and Chapter 17, "Bulletproofing Your Application Interface," for more details on creating applications that educate and assist the user toward self-sufficiency. Chapter 9, "Completing and Deploying a Solution," provides general insights into useful testing and training approaches.
What we and many other developers used to call maintenance mode (a state where the application feature set does not grow, only bugs are fixed) is no longer an inevitable state for an application. With new releases of tools coming on an annual basis, and hardware upgrades following at an equally frantic pace, merely maintaining an application is not logical. Instead, significant periodic upgrades of major applications is an instituted policy in many companies.
Unless an application is so broken that users cannot derive any value from it, do not fix problems or add features each time a user request is generated. Software builds should be released at reasonable intervals, in response to a body of work rather than a single change.
For applications that are widely deployed, the internal cost of distributing and retraining a new release is high. This cost must be weighed against the benefit of a release in order to gauge whether the timing is right.
See Chapter 9, "Completing and Deploying a Solution," for more information on staging the release of application updates.
Writing reusable code instead of static code and creating reusable objects instead of canned objects adds very little extra time to a development effort, yet provides significant financial benefits to a company. As any particular application grows and morphs into new releases, developers should be able to leverage off of existing components in the application when constructing the new releases or other applications.
LDF advocates creating reusable code and objects as part of the development team's library. Additionally, however, developers should understand the growth plan for each object captive to an application, and design the object to provide the simplest possible upgrade path in the future.
This chapter provides the groundwork for every chapter that follows in the book, because the framework described here pervades the examples and practices in each chapter.
The chapters early in this book provide additional information derived from LDF on a conceptual level, including these:
The chapters later in the book move from theory to practice by showing how LDF, taken to its logical conclusion, becomes actual coding and development techniques:
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.