C H A P T E R  2

Agile and APEX

Delivery of high-quality working software to users on a fast and regular basis is a key goal of Agile software development. Oracle Application Express is a highly efficient rapid application development (RAD) environment. Therefore, it is not surprising that these two entities dovetail together extremely well.

This chapter steps through the Agile Manifesto with its Twelve Principles of Agile Software and highlights the areas where APEX supports Agile software development. The goal of this chapter is to give you insights into how you and your team (the people) can use Agile software development (the process) together with APEX (the tool) in ways that will enable you to reap the incredible commercial benefits that are inherent in these complementary environments.

The Agile Manifesto

The Agile Manifesto is short, simple, to the point, and incredibly wise. APEX can be viewed in a similar fashion. APEX’s declarative environment and simple underlying architecture make many routine software development tasks short, simple, to the point, and robust.

Individuals and Interactions Over Processes and Tools

Agile software development is a process. It is ironic, but noteworthy too, that the authors of the Agile Manifesto value individuals and interactions more than their brainchild, the process of Agile software development (see Figure 2.1).

Agile software development supports individuals and interactions by promoting a strategic set of processes that fit well with the natural way in which people work. The Agile processes are lightweight and require a minimum of bookkeeping and bureaucracy. This strategy gives developers more time for producing working software.

Figure 2.1. Although tools and process have value, we value people more.

APEX supports individuals and interactions by providing a set of tools that are lightweight and supportive of both individual work effort and team collaboration.

APEX wizards are one of the chief tools that support an individual developer. There are wizards that help you create most of the artifacts in APEX. Each wizard guides you through a set of pages that contain related properties. In this way, you create an artifact by entering data for the 20% of the properties that do 80% of your work. This method is far more humane and efficient than going to a single page that has all of the artifact’s properties. The single page with all the properties can be confusing because the important 20% of the items are mixed in with the 80% that are rarely used. It is easy to miss an important property, which means you must return to the artifact later to debug what you missed.

APEX’s Team Development module supports team collaboration. Team Development provides a light but rich framework that allows a skilled, motivated, and trusted team to self-organize. The feedback mechanism, features, to-dos, bugs, and milestones are used in concert by the team to efficiently and effectively communicate among themselves and outside stakeholders. Team Development is designed so that it is relatively easy for developers to keep it up to date in near real-time. Chapter 6 discusses this important APEX module in detail.

Working Software Over Comprehensive Documentation

Software developers produce working software; that is our primary job. Everything else merely supports the primary purpose and must be looked at as overhead. The overhead is always necessary, but it must be ruthlessly minimized and must never, ever become an end in itself.

APEX’s declarative environment is the tool’s main mechanism for producing working software. Most of the underlying tough coding is taken care of by the APEX engine. Developers rarely, if ever, have to worry about routine things like record inserts, deletes, and updates. The APEX engine does an excellent job of making these database actions safe, quick, and reliable. The safety, quickness, and reliability stem from three sources: the APEX team, the APEX team’s processes, and the tool used to create APEX.

Over the years, I have attended numerous conferences where the APEX team has presented technical papers on APEX. The formal presentations together with informal networking have clearly demonstrated that the APEX team has all the right stuff; they are highly skilled and motivated. They are an embodiment of the Agile Manifesto’s opening phrase, “We are uncovering better ways of developing software by doing it and helping others do it.”

The APEX team used the Team Development module to manage the construction of APEX 4.0 and continues to use it for the following releases. This fact shows that the team has a good handle on Agile software development processes.

Working software needs documentation. Documentation has value. This is true because no matter how hard software developers work to make the GUI easy to use and intuitive, there are always some parts that need explanation. This is true for both the external interface that is exposed to the end users and the internal code that the developers must understand in order to do maintenance work.

APEX provides hooks that enable developers to document all aspects of their work in the immediate context of the APEX Application Builder without resorting to weighty three-ring binders full of outdated paper. Websheets, team development, APEX utilities, and the help text features can be used in concert to efficiently produce practical and agile documentation within the APEX context. Chapter 8 covers Agile APEX documentation in detail.

Customer Collaboration Over Contract Negotiation

Customer collaboration that is ongoing throughout a product’s development is imperative if the product is to be practical and useful. One of the critical success factors of a software project is customer buy-in. Buy-in is almost always the result of positive collaboration with the development team.

APEX fosters customer collaboration through

• Fast delivery of working software
• Feedback

APEX delivers working software to the customer quickly. This enables the customer to start working with the product to test, debug, and evaluate the requirements.

The feedback mechanism that is built into the APEX Team Development module is an ideal collaboration tool. It enables the customer to provide immediate and useful comments to the development team from within the context of the application. The feedback mechanism is embedded into every page in an APEX application. A customer who sees a bug or thinks of a design change can immediately capture the thought in the feedback page. The customer’s comment is captured together with all the underlying details, such as the APEX session state, the customer’s browser type and version, the customer’s computer operating system, and other data that is often invaluable to the developers.

This cuts out the need for longwinded e-mails that require a sluggish back-and-forth set of questions and answers. Chapter 6 comments on the feedback mechanism in detail.

APEX is not a contract-management system; however, the Feature mechanism in APEX’s Team Development module can be used to produce a high-level list of features that contains the start date, due date, and estimated effort in hours (see Figure 2-2). The features can be used as an input into the statement of work, which is a key component of the contract. Chapter 6 discusses the feature mechanism in detail.

Figure 2-2. APEX features can be used in a contract’s statement of work.

Responding to Change Over Following a Plan

Change is a fact of life. We are always living in a state of flux, and software development is no exception. Agile software development deals with change by expecting it and planning for it. It does this by putting working software into the customer’s hands as quickly as possible so that the team can iterate, multiple times if required, through these stages:

1. Design
2. Build
3. Evaluate

If you have a good understanding of the requirements and a good design, then why iterate through these steps? There are two primary reasons:

Bugs: Bugs are typically associated with the software; software bugs are fixed to make the software conform to the requirements and design. Bugs can also be associated with the requirements and the design; this type of bug can be scary because it can potentially involve a tremendous amount of rework. Delivering working software early is the only way to uncover requirement and design bugs that have not been identified during reviews of the requirements and design.

Knowledge transfer: During a project, the business users constantly learn more and more about the technology; the programmers constantly learn more and more about the business (see Figure 2-3). Knowledge transfer often causes “ah-hah” moments when someone on the team sees a much better solution to a business or technical problem. Planning for change allows the team to take advantage of these “ah-hah” moments to increase the quality of the end product. Sometimes the good ideas can come very close to the end of the project.

Figure 2-3. Knowledge transfer continues throughout the entire project.

How do you plan for change? You start with a high-level overview of the project. Senior resources look at the initial requirements and sketch in the major entities to form the initial design. Time estimates are the product of expert judgement and must account for the confidence that the team has in the requirements. The team estimates the time required to build the initial version of a module, and then a line item for change is added as a contingency. The team must be careful with this line item: programmers must not view it as a chunk of time to clean up sloppy code—adding error traps and global constants, for example. The initial production code must never be sloppy. The line item for change is reserved strictly for refactoring the product based on legitimate and knowledgeable feedback from the customer.

I recently attended a seminar given by a respected scrum master. The scrum master said that the correct answer from a programmer when asked how long an individual task will take is, “I don’t know.” This is scary when you are estimating the effort needed to complete a project, especially when a fixed-price contract will govern the work. Solving this dilemma requires expert judgment by senior personnel who can look at a high-level design and assign qualitative descriptions such as easy, medium, and hard to each entity. Quantitative units of measures, such as hours, are then assigned to the terms easy, medium, and hard to arrive at the final estimate. The quantitative units of measure are, in turn, affected by the computing environment and the skill levels of the available resources. As a project unfolds, you will come in under budget on some entities and over budget on others. The individual unders and overs usually average out if the initial quantitative estimates are reasonable. In other words, your overall estimate can be reasonably accurate even when estimates of individual line items are not precise.

How does APEX support responding to change and building a plan? First, APEX is an efficient rapid application development (RAD) environment. A RAD environment enables you to quickly build the initial version of the application. This environment also enables you to quickly delete a page and then re-create it. Second, the Team Development module can be used to build your initial plan and then evolve with changes as they occur. Chapter 6 discusses Team Development in detail.

The Twelve Principles of Agile Software

Agile’s Twelve Principles of Agile Software serve as stepping-stones between the somewhat abstract core values of the Agile Manifesto and the concrete world of software development methodologies. The Twelve Principles give developers a sense of how they can go about applying the Agile Manifesto’s values to the real world without getting into the details of the individual Agile methodologies. This section lists the Twelve Principles and points out the features of APEX that support them.

Remember that APEX’s primary function is to build a web-based graphical user interface (GUI) on top of an Oracle Relational Database Management System (RDBMS). The following discussion assumes that the database has been constructed and that it is relatively stable. In most cases, end users are content with a high-level overview of the database design; they generally need this information to help them understand the hows and whys of APEX GUI construction. End users are very interested in how their data is displayed so that they quickly get the information they need and clearly see what they must do in order to get their work done. The desire to see information instead of data, and the desire to quickly and intuitively step through workflows, drive a GUI through many iterations of

1. Analyze
2. Design
3. Build
4. Evaluate

The iterative cycles, over time, tend to become shorter as the development team learns the business and the business team learns the technology. In baseball terms, the teams start hitting more and more home runs as the game unfolds.

Customer Satisfaction by Rapid Delivery of Useful Software

From a customer’s point of view, software development looks somewhat like building a house. The customer first signs off on the architectural drawings. Then construction begins with lots of visible activity like digging the foundation, pouring the foundation, erecting the walls, and putting on the roof. These activities are highly visible and give the customer a concrete sense of progress. However, once the shell is built, it seems to take forever to reach the move-in date. The finishing work like plumbing, wiring, drywall finishing, and painting must all be completed before the customer can move in. The customer feels frustrated because no big and highly visible tasks are being completed. APEX software development is similar to building a house in that building the shell gives the customer a sense of rapid progress. The comparison breaks down during the finishing stage because in an APEX software development environment, the customer can start using parts of the application in production before the entire application is completed. In other words, they can move into the ground floor while the upper floor is still being finished; there is no paint smell or plaster dust to deal with.

APEX delivers useful software rapidly because it delivers a truly RAD environment. A typical delivery plan can include the following artifacts in quick succession:

• High-level navigation shell
• Administration pages
• Features/Modules

APEX’s simple architecture is another major reason that working software is delivered quickly. The architecture enables an application’s promotion from the development environment to the test and production environments to be automated. Typically, the promotion effort consumes much less than an hour. Application promotion is a low-risk activity that can be quickly done on a daily or weekly basis.

High-Level Navigation Shell

APEX uses lists and tabs to build the high-level navigation shell that knits the application together (see Figure 2-4). Buttons and report links are used for finer-grained navigation to the lower-level, more-detailed features.

Figure 2-4. High-level navigation shell

The high-level navigation shell takes only a few minutes to create, yet it has a great deal of value to the business users when it is delivered early. The navigation shell gives the business users their first hands-on experience with the application. It is the first concrete step in validating the requirements and design.

Business users and developers often have different visions as to how the requirements and design are translated into working software. The navigation shell is a great starting point to make sure the two visions come together in a spirit of collaboration. The shell is easy to change at this point, so the business users quickly get a sense of ownership when their suggestions appear in the application almost immediately.

The high-level navigation shell is the perfect place to refine terminology. Getting the terminology defined in the users’ language at this point enables the developers to use the same terminology in the underlying code as the detailed design and construction unfolds. Agreement between the high-level and low-level terminology is one of the key factors that make an application easier to build, maintain, and document.

Administration Pages

Building an application’s administration pages is a great second step after the high-level navigation is in place. The functionality in this area includes application support objects. Lookup tables are a good example. APEX’s declarative environment enables the developers to rapidly build the maintenance pages for the support objects. Typically, the maintenance pages are based on tabular forms and interactive reports.

Administrative tabular forms most often are built on top of a single table that has a small number of rows and columns (see Figure 2-5). Building a tabular form on a single table typically takes less than five minutes.

Figure 2-5. Simple tabular form that maintains a lookup table

Interactive reports can also be used to maintain support objects. Interactive reports are generally used for tables that have a large number of rows and require a search function that enables the user to quickly find an individual row or group of related rows (see Figure 2-6). The interactive report page contains links to a page where a new row is created or an existing row is edited (see Figure 2-7). The create and edit functions are both handled by a single APEX page that was created using the form on a table or view wizard. Building an interactive report together with its create and edit supporting page usually takes less than half an hour, assuming the support table has a small number of columns and no complicated dependencies.

Figure 2-6. Simple interactive report that maintains a wide lookup table with many rows

Figure 2-7. Simple from on a table that maintains a row in a wide lookup table

The main point here is that APEX is used to rapidly deliver useful working software to the customer. The customer quickly learns how to work with tabular forms, interactive reports, and data-entry pages in a small, simple, and straightforward environment. As the customer enters the support data, the developers start to learn and absorb the customer’s business terminology and get a sense of how the business operates. Two important things happen at this stage of development: an important piece of production code is delivered rapidly, and the two-way knowledge transfer between customer and developer begins in earnest.

Features/Modules

Agile’s iterative nature exposes itself when the features are built. At the beginning of this phase of the project plan, the feature designs are still at a relatively high level. The high-level design was adequate for developing the schedule and budget but lacks the nitty-gritty details.

Each feature is developed by iterating through one or more cycles of

1. Mockup
2. Prototype
3. Build
4. Test
5. Evaluate

The initial schedule and budget is based on the assumption that some features will require only one pass through the cycle; the baseball equivalent is a home run. Other features require multiple passes through the cycle before they can pass a critical evaluation.

The APEX declarative environment supports the prototype, build, and test portions of the cycle. The prototype is the APEX version of the mockup; it is rapidly built by using APEX wizards. The build process involves adding business logic to the application; much of this work is done efficiently by using the APEX wizards. Unit testing concentrates on the business rules, not on the mechanical aspects of transporting data from the screen to the database; the APEX engine is extremely reliable from a mechanical point of view.

Changing Requirements Welcomed, Even Late in Development

Conventional wisdom tells us that changes are expensive when they occur late in a project. The extra expense is required because a large change involves reworking many pages and reports.

The Agile and APEX combination significantly mitigates the cost of major changes that occur near the end of a project (see Figure 2-8). The cost mitigation is due to a number of Agile and APEX features:

• Agile’s emphasis on close collaboration delivers significant knowledge transfer between the development and business teams. The development team’s business knowledge enables them to code solutions quickly without having to pester the business team with lengthy questions and then wait for answers. The flip side of the coin applies to the business team. Their technical knowledge allows them to quickly and accurately communicate with the developers; late in the development process, they have a good idea of what the technology can and cannot do. The two-way knowledge transfer speeds the process of designing and implementing a change, even when the change is complex.
• APEX’s RAD environment is just as efficient in delivering changes as it is in delivering the initial application. I recently worked on an APEX project where the sponsor expressed a concern that the development team was spending too little time fixing defects and adding enhancements to a production application. The development team was delivering the changes on time but well under budget, a situation that the sponsor had trouble understanding because of a lifetime of experience where software projects were always late and over budget. In this case, the highly skilled and motivated development team delivered quality code on time and under budget by using a productive tool (APEX) and an effective process (Agile).

Figure 2-8. Conceptual illustration of the relative costs of change late in a project

Working Software Is Delivered Frequently

APEX directly supports the principle of delivering working software frequently by

• Enabling developers to quickly build and modify applications
• Enabling database analysts to easily deploy an application

APEX’s declarative environment enables developers to achieve significant results within relatively short development sprints. I have already spoken about APEX’s awesome RAD capabilities.

Deploying an application to the test and production environments is a relatively painless and quick process in an APEX environment. The process can be automated so it usually takes less than an hour to deploy an APEX application together with its supporting objects such as JavaScript files and scripts to update the database objects in the parsing schema. The mechanical details for this process are found in the books Pro Oracle Application Express 4 and Expert Oracle Application Express (both Apress, 2011).

Working Software Is the Principle Measure of Progress

The fundamental building block in an APEX environment is a web page. This fact makes it easy and simple to build a public graph that lets everyone know how an APEX project is progressing (see Figure 2-9). A graph that tracks completed pages over time is an effective project health indicator. A project that shows a consistent upward trend in the number of completed pages at the budgeted rate is healthy. An occasional downward blip indicates areas where iterative change has occurred or where significant bugs in the code, design, or requirements were found and corrected. The graph is effective because it is brutally honest.

Figure 2-9. Pages are the principle measure of progress.

At the beginning of a project, the total number of pages is estimated. Near the end of the project, the actual total number of pages is added to the graph to illustrate the completion of the project.

This approach of tracking only working pages as the principal measure of progress may seem simplistic to those of you who have been trained in formal project-management practices, where Earned Value Analysis is king. Earned Value Analysis is an elegant way of tracking progress, but it requires a lot of project-management overhead. Tracking working APEX pages is simple, is effective, and requires very little overhead.

Sustainable Development, Able to Maintain a Constant Pace

In the APEX environment, the principle of “sustainable development” is closely related to the principle of “working software is the principle measure of progress.” APEX web pages are built quickly by using APEX’s declarative tools. As each page is added to an application, it gives the developers a sense of accomplishment; and the customer gets visible proof that progress is being made.

Close, Daily Cooperation Between Business People and Developers

APEX supports the principle of close, daily cooperation between business people and developers through the feedback module that is built into Team Development. This feedback module is discussed in Chapter 6.

Simplicity

Simplicity is an area where APEX shines. APEX’s “out of the box” configuration contains very few moving parts (see Figure 2-10). There are only three blocks in the architecture:

• Web browser on the client computer
• Web server
• APEX engine

Figure 2-10. The APEX architecture is simple, with very few moving parts.

APEX supports most of the common web browsers that are in use today. The user need only enable cookies and JavaScript in their browser of choice. Installation, when required, takes but a few minutes.

The web server handles the two-way communication between the browser and the APEX engine. The web server is responsible for security and file caching. Currently there are three web servers to choose from:

• Oracle HTTP Server (OHS)
• Embedded PL/SQL Gateway (EPG)
• APEX Listener

Choosing the correct web server for your environment is covered in detail in the book Expert Oracle Application Express (Apress, 2011). Installing the web server is well documented for both Linux and Windows platforms. Installation and configuration are usually relatively quick and straightforward for experienced operations personnel.

The APEX engine resides inside the Oracle database. It consists of approximately 500 tables and 300 PL/SQL objects such as packages, procedures, and functions. An Oracle database schema named APEX_ xxxxxx owns the APEX engine, where xxxxxx is the APEX version number. This schema is locked; therefore, APEX developers never need to interact with it directly. The APEX engine comes preinstalled in Oracle databases starting with version 9i. Upgrading versions is simple and involves running a few PL/SQL scripts that are well documented. The book Expert Oracle Application Express contains an excellent description of this simple yet powerful and extensible architecture.

Self-Organizing Teams

APEX supports self-organizing teams through its Team Development module. The team has the freedom to plan their sprint activities to the level of detail that suits their development culture. The detailed tasks, called to-dos in the Team Development module, can be self-assigned by any developer in the daily morning stand-up meeting. The team is completely free to hit their development targets any way they choose. Team Development allows them to efficiently plan and track who is doing what by when. Chapter 6 covers Team Development in more detail.

Face-to-Face Conversation as the Best Form of Communication

APEX does not explicitly support the principle of face-to-face communication; however, APEX supports the principle implicitly through its approach to documentation. Documentation, when it is created within an Agile and collaborative environment, encourages conversations between the stakeholders. Chapter 8 explores Agile documentation within the APEX context in more detail.

Motivated Individuals Who Are Trusted

Earlier, the chapter spoke about tools, process, and people. People were identified as the critical success factor. I feel strongly that this is true. APEX is not a human resources tool: it does not directly motivate individuals or directly build trust between stakeholders. Indirectly, however, APEX supports motivation and trust by being a good tool that works well. The act of building something that works well is motivating for most developers. Delivering something that works well within a reasonable amount of time builds trust among most stakeholders. APEX, simply by being a good-quality tool, supports both motivation and trust.

Continuous Attention to Technical Excellence

APEX is a tool. It can be used well, or it can be abused. Learning to use APEX well involves two fundamental steps that are true for any tool:

• Read the instructions.
• Hone your skills over time by using the tool and refining your techniques.

The basic instructions that come with APEX are short, concise, and effective. In my experience as a team lead and project manager, I have found that the 2 Day + Application Express Developer’s Guide is all that is required to get a junior programmer up and running with the basics of APEX development.

Expert skill comes later after building a few applications and reading some of the advanced APEX books, such as Pro Oracle Application Express 4 and Expert Oracle Application Express (both Apress, 2011). More important, teams must take techniques from the books and adapt them to the team’s environment and technical culture. Chapter 7 suggests a technique for installing a terse and flexible documentation framework for steering your team on a road toward the horizon of technical excellence.

Regular Adaptation to Changing Circumstances

APEX is a tool: an inanimate object that, by itself, cannot adapt to changing circumstances. In the hands of a skilled and motivated developer, it can be an effective instrument of change.

Oracle’s APEX development team has set a good example for regularly adapting to change. The team has released major versions of APEX on approximately an annual basis. Each major version has done the following:

• Fixed flaws
• Improved existing features
• Added new features, such as mobile themes, that recognize significant changes in the surrounding environment

APEX itself gives developers the power to change significant aspects of their APEX applications. The theme/template infrastructure enables an APEX team to reconfigure the look and feel of an application dramatically. This is useful in the context of web technology that is rapidly changing as HTML and CSS standards become more mature and user expectations become higher. Plugins allow developers to build their own widgets and interfaces to other systems. APEX plugins have given developers a tool that helps them keep up with changes in their corporate environments.

Summary

APEX is a software-development tool that explicitly complements the Agile software-development processes that are embodied in the Agile Manifesto and its Twelve Principles of Agile Software. Agile values fast delivery of useful software, responsiveness to change, and teamwork. APEX’s declarative rapid application development environment supports fast delivery and responsiveness to change. Team Development fosters a spirit of collaboration, cooperation, interdependence, and teamwork across the full spectrum of stakeholders. This winning combination of tool and process leads to the construction of business applications that are successful from both the technical and business perspectives.