C H A P T E R  10

Summary

Agile is a process. APEX is a tool. These two inanimate things are brought to life and blossom in the hands of skilled and motivated software developers.

Agile software development was conceived in the 1990s. It was born in 2001 when the Agile Manifesto and its 12 underlying principles were written and published. Agile’s phenomenal uptake at the time was due to the software industry’s hunger for a new approach to governing software development projects; the classical project management techniques that grew up in hard industries like construction did not work in the software industry. The failure of classical project management techniques in the software industry was due to the extremely fast pace of change in the software industry and the inherent malleability of software itself. Agile explicitly recognizes that hardware is hard and software is soft.

Agile software development values “ responding to change over following a plan.” This is an important Agile value; however, Agile recognizes that the plan has value. Professional sports teams spend a huge amount of time practicing plays; plays are their plans. Successful execution of a play means success, so there is a huge incentive to devise and execute successful plays. A hard fact is that playing in a game is much different than practicing. In a game, there is an opposing team, there is a loud crowd making on-field communication difficult, the weather is always a factor, and then there is adrenaline flowing in the veins of each player. In this environment, many plays get broken. Highly successful teams are good at both executing planned plays and at scrambling to make the best of broken plays. When a play is broken, the team falls back on secondary and tertiary plans; if they are not an option, the players react and fall back on their individual training and conditioning to read the situation and respond. Championship teams excel at both executing planned plays and turning broken plays into successes. Agile software development explicitly recognizes this reality in the software industry by breaking a large project down into small iterations so that after each iteration, the team can evaluate its position and adjust to its current environment, which is often different than expected. Agile, in sporting terminology, means being quick on your feet.

Oracle Application Express (APEX) is a tool that is well suited for working in an Agile software development environment. The primary reason for the good fit is APEX’s declarative architecture. Almost all of its core features can be implemented by stepping through point-and-click wizards that build complete web pages that are intimately tied to an underlying Oracle database. All of the tedious insert, select, update, and delete SQL statements are handled behind the scenes by the APEX engine, leaving the developer free to deal with the business rules that are associated with the page.

The fundamental building block in an APEX application is a web page. APEX web pages are generally built within a short amount of time, making it relatively easy to break an APEX application down into small units of useful functionality, which are delivered within short iterations of two to three weeks. This strategy fits extremely well with Agile software development.

“Out of the box” APEX is a powerful and efficient software development tool. Like all tools, it has strengths and weaknesses. The weaknesses are addressed by enhancing APEX through using supporting technologies. For example, APEX has no built-in print engine for producing formatted reports. BI Publisher, PL/PDF, and Jasper Reports can be linked to APEX to fulfill this role. APEX applications that need a rich web environment may need the help of JavaScript libraries like jQuery and Ext JS. Enhancing APEX is often required to meet user expectations and to fulfill complicated requirements. Of course, enhancing APEX with external supporting technologies comes with a price: the tool becomes somewhat less Agile. This is due to a number of factors. The enhanced skill set that is required to implement the technologies forces your team to learn how to use the technologies or acquire new personnel with the requisite skills. There are more moving parts associated with your enhanced APEX application; risk is increased together with the cost of ongoing maintenance. More time is required to build and test the application. In general, when a team enhances APEX with supporting technologies, it must also move from a lightweight project governance model to a slightly heavier model; please realize that this can be done within an Agile software development environment.

The APEX “box” has grown significantly since its first major release as HTMLDB 1.5. Each major release has seen more and more external functionality being pulled into the APEX environment. For example, a lot of tedious hand-coded JavaScript is no longer necessary now that dynamic actions have been incorporated into APEX 4.x.

Does Agile software development ignore classical project management? No, it actually complements it. The only significant aspect of classical project management that Agile rebels against is a waterfall approach, in which detailed requirement gathering and design are done up front before construction begins. Waterfall, in a software development environment, fails in many cases. Agile promotes a strategy in which high-level planning is done at the beginning of a project. Detailed design is done in a “just in time” manner, in which it is left to individual iterations.

Agile software development respects the five project management process groups and the nine project management knowledge areas that are put forward in the Project Management Institute’s (PMI) A Guide to the Project Body of Knowledge (PMBOK Guide). This complementary relationship between Agile and PMI’s view of project management has been formally recognized by PMI’s introduction in 2011 of the PMI Agile Certified Practitioner (PMI-ACP) certification.

Oracle’s APEX development team values Agile project governance and Agile project management. This fact is clearly demonstrated by the introduction of the Team Development module in APEX 4.0. Team Development is a lightweight project governance tool. It adheres to the Agile principle of “ simplicity.” Team Development’s elegant design makes it simple, extensible, and flexible; all of these attributes make it a good fit with Agile. The Features entity enables the team to capture and document a high-level plan for executing a project. Milestones organize the iterations by tracking release dates and the Features that are released with the iteration output. To Dos are used to help keep individual iterations on track; they are the tasks that are assigned to individual team members. Bugs track issues that are found by testers and end users; bugs, depending on their complexity, can be promoted to individual To Dos or Features. The Feedback mechanism pulls all of the stakeholders together by giving them an efficient way of recording any issue that they find with an APEX application. Feedback supports, in a big way, Agile’s principle of “ close, daily co-operation between business people and developers.” The existence of Team Development is a sure sign that APEX is rapidly maturing into a serious contender in the software development world.

Rules and guidelines, in an Agile software development context, are an effective format that can be used to efficiently capture a software development team’s standards. Software development standards are key to adhering to Agile’s principle of “ continuous attention to technical excellence and good design.” Often, teams get bogged down by writing standards in a verbose and wordy manner; this is very un-Agile. The rules and guidelines format that is recommended in this book gives developers a concise and very terse way of capturing their standards in a format that is easy to write and maintain. APEX’s Websheet module is an ideal authoring and publication mechanism for rules and guidelines. In a websheet, the rules and guidelines are easily accessible at all times to all of the developers. The websheet saves paper and is the single source of truth. At the end of each iteration, the results from the team’s reflective iteration review can quickly be captured in the websheet version of the rules and guidelines and are ready to go at the beginning of the next iteration.

The Agile Manifesto values “ working software over comprehensive documentation”; however, documentation has value and, in some regulated industries, is mandatory. Out of the box, APEX provides a number of ways to capture documentation within APEX’s Application Builder. APEX also provides a number of ways to extract and publish the documentation. The exact way a team documents its applications and APEX environment can be defined in its rules and guidelines document or websheet. The trick is to minimize the number of documentation artifacts to keep the documentation effective yet lightweight. Well-crafted working software can be self-documenting to a large extent; however, a few snippets of well-crafted and accessible documentation can save a lot of time and grief when it is time to maintain the software or explain to users how and why it works the way it does.

We are software developers; building quality software is one of our professional passions. This passion is embodied in one of the most important Agile principles: “ continuous attention to technical excellence and good design.” Applying this principle to our daily work is daunting because the word “quality” means many things to many people. We can, however, deal with quality by first defining it through another Agile principle, “ close, daily co-operation between business people and developers.” The initial theoretical definition is usually articulated in a product’s requirements document; the definition is then refined, if necessary, by adapting the theoretical definition to the practical needs of the individual product and customer.

Quality has two aspects:

•     Quality must, in fact, exist in the product.
  
  
•     Stakeholders need assurance that, in fact, the quality does exist.

“ Self-organizing teams” define quality through their rules and guidelines. Rules and guidelines ensure that the software is constructed in a consistent and well-defined manner. APEX plays a part in this by providing a robust declarative environment that helps developers build applications whose mechanical workings are extremely reliable.

APEX can give the stakeholders good assurance that the software is built to high-quality standards. APEX applications are defined using metadata in the Oracle database. APEX provides many useful views of this metadata through its rich set of utilities, which includes a debug repository and the APEX Advisor. The views of the metadata provide useful tests for quality. Testing tools are not yet part of the APEX development environment; however, there are a number of testing tools available that work well with APEX.

Both authors of this book have been working almost exclusively with APEX for well over six years. In that time, we have had the pleasure of working with a wonderful group of people, the APEX developer community, who truly live by the sentiment that is expressed in the Agile Manifesto’s opening line, “ We are uncovering better ways of developing software by doing it and helping others do it.”