Introduction
As APEX developers, we love to develop new applications and showcase the latest and greatest features of APEX (and its associated technologies). We also love to please our customers and show them what a great value APEX provides. These motivations (along with other factors) can sometimes lead to great applications that unfortunately leave behind a legacy of costly support and difficult upgrades. In this post I will discuss a middle ground where we can still give our customers the functionality they need and also consider maintenance, upgrades and most importantly return on investment.
How Does it Happen?
This post is really about avoiding un-necessary complexity when developing software in APEX.
Complexity can come from many sources, including:
Complexity can come from many sources, including:
- Designers over engineering the solution or not considering the development platform in their designs.
- The lack of a clear approach and design at the start of development.
- A lack of development standards and best practices.
- Developers showcasing APEX and using un-necessary features.
- Developers showcasing their own knowledge and using un-necessary features.
- A lack of frank discussion between designers, developers and the customers. The customer should be made aware of what they are signing themselves up for when certain approaches are taken.
Where Does Complexity Usually Occur in APEX?
APEX is a full stack development platform and requires at least an awareness of that full stack from all of its developers. When considering where complexity can occur, in my experience the following areas have the greatest potential for causing problems. These are the areas I will focus on for the remainder of this post.
APEX Architecture
Before deep diving into each of these, it is important to understand that APEX relies on a number of supporting front end technologies to achieve the results that it does. With each major release of APEX, the list grows. APEX 18.1 uses JavaScript, jQuery, jQuery UI and JET to name a few. Without these technologies, APEX would just be a bunch of htp.p statements. Each of these technologies have a development lifecycle cycle of their own. When a new release of APEX hits the street, the version of these technologies delivered with APEX is usually already one version behind the latest.
- JavaScript and jQuery
- Dynamic HTML
- CSS
- Plugins
APEX Architecture
Before deep diving into each of these, it is important to understand that APEX relies on a number of supporting front end technologies to achieve the results that it does. With each major release of APEX, the list grows. APEX 18.1 uses JavaScript, jQuery, jQuery UI and JET to name a few. Without these technologies, APEX would just be a bunch of htp.p statements. Each of these technologies have a development lifecycle cycle of their own. When a new release of APEX hits the street, the version of these technologies delivered with APEX is usually already one version behind the latest.
The reason this is important is that if you dip into these technologies with non-declarative custom code, you could be locking yourself into that particular version. When the next version of APEX ships with an updated version of jQuery (for example) your code may no longer work, and you have to spend time and money upgrading that code.
The APEX development team seems to be particularly conscientious in making sure the APEX upgrade experience is as painless as possible. Declarative code breaking during an upgrade is a rare thing. The more you stray from declarative code, therefore, the greater the cost you bear when upgrading APEX as opposed to Oracle bearing the cost. To illustrate its resilience to upgrade, I have heard tales of APEX 3 applications on apex.oracle.com being upgraded all the way to APEX 5.1 without needing any changes. What are the chances of the REACT code you are developing today working on whatever version of REACT is current 6 years from now?
JavaScript & jQuery
The APEX development team seems to be particularly conscientious in making sure the APEX upgrade experience is as painless as possible. Declarative code breaking during an upgrade is a rare thing. The more you stray from declarative code, therefore, the greater the cost you bear when upgrading APEX as opposed to Oracle bearing the cost. To illustrate its resilience to upgrade, I have heard tales of APEX 3 applications on apex.oracle.com being upgraded all the way to APEX 5.1 without needing any changes. What are the chances of the REACT code you are developing today working on whatever version of REACT is current 6 years from now?
JavaScript & jQuery
In my experience, JavaScript is probably the number one source of unnecessary complexity in APEX applications. What starts off as a couple of lines of jQuery to dynamically change some region text can all too easily freefall into hundreds of lines of JavaScript. The temptation with JavaScript is to make everything dynamic in order to avoid the ‘evil’ full-page refresh at all costs. Of course, a partial page refresh is preferable for user experience, but APEX provides a number of options to achieve this declaratively with Dynamic Actions. If you find yourself staring at more than 15 or 20 lines of JavaScript or jQuery when developing an APEX page, you should seriously consider two things:
Dynamic HTML (htp.p)
- Is there a Dynamic Action that could achieve the same thing?
- Would it be the end of the world if the user had to submit the page and have it refresh?
Dynamic HTML (htp.p)
If you have ever seen a dynamic region in APEX that is built completely from hundreds of lines of PL/SQL and htp.p statements, then you will understand why this could add complexity to your application. Code that mixes business logic with UI is not only confusing to read but is also fraught with problems when the business logic inevitably changes. With the power of the Universal Theme behind you there are less and less good reasons to go down this route. In short, don’t do it!
CSS
CSS has an allure almost as strong as JavaScript. Surely a few well-placed lines of CSS won’t hurt. In reality, CSS is more upgrade proof than JavaScript but not entirely immune to upgrades. From time to time, the APEX development team does change class names. For example, in APEX 18.1 the class names for mobile objects changed when they were moved from the mobile theme to the Universal Theme. There is also the inevitable change that comes with new browser versions. The APEX team spend hundreds and hundreds of hours making sure the Universal Theme works well with the current and prior major release of the most popular browsers. This is no mean feat. If you start rolling your own complex CSS, you are again at the mercy of other technologies.
I am not at all saying you should not use CSS, just use it judiciously.
Plugins
I am not at all saying you should not use CSS, just use it judiciously.
Plugins
Don’t get me wrong, plugins are an important and a vibrant part of the APEX ecosystem. Speaking personally, they have pulled my backside out of the fire on more than one occasion. What I would suggest, however, is that you keep plugin use to a minimum. The reason, again, is dependency. As soon as you load that plugin you are now depending on a 3rd party to upgrade it when the next shiny new version of APEX is released. If they don’t update it for some reason, then you are now stuck with replacing that functionality yourself.
Use plugins where they can really make a difference. Look at the track record of the developer and the underlying technology. Also note that plugins often make use of JavaScript libraries (e.g. SELECT2), in such cases you have introduced two dependencies in one plugin. I have used the SELECT2 plugin for a number of my customers and am not at all advising against it, just make sure you use plugins with your eyes wide open.
Use plugins where they can really make a difference. Look at the track record of the developer and the underlying technology. Also note that plugins often make use of JavaScript libraries (e.g. SELECT2), in such cases you have introduced two dependencies in one plugin. I have used the SELECT2 plugin for a number of my customers and am not at all advising against it, just make sure you use plugins with your eyes wide open.
How to Avoid Complexity?
These are not technology problems, they are actually people problems (aren’t they all!). Everyone in the SDLC needs to take some responsibility for avoiding them.
The Sponsor
Make sure you own the ROI for the project. You have two responsibilities to your company: one is to solve the business problem, the other is to make sure it adds real value (in dollar terms) to your company’s bottom line. If a specific feature can gain you a great return on investment but takes 1,000 lines of JavaScript, then I am all for it. Just make sure you really know what the ROI is and that you are able to prove it.
The Designer
You cannot design in a technology vacuum, you must design with the development platform in mind. Given that APEX was chosen to build the solution you should make considerations for it when designing the solution. If you build a design that you know will require the developer to jump through hoops, then you are just as culpable as they are in adding to the complexity debt.
Your organization chose APEX as its development platform. It is Oracle’s problem if APEX does not provide the features that your users need. If that should ever happen then your organization should switch to a different development platform instead of making APEX do unnatural things.
The End User
As much as we would like to say the end user is king, it is not always the case. I bring you back to the reason for building software which is to get a return for your investment. If that ROI can be achieved and the user must make an extra click, then so be it. Now that is not an excuse to deliver any old garbage. There is never an excuse for not delivering an enjoyable and productive user experience. Just don’t do it at the expense of the real prize.
The Developer
Code responsibly. If you want to show that you can build Pacman using pure JavaScript and CSS then do so on your own time. Also, don’t be afraid to speak up when the design does not smell right. If you think a particular design decision will corner you into writing 300 lines of JavaScript, then say so. Explain what the implications are and the potential downstream costs. Most of the time people will be receptive to your feedback.
The Sponsor
Make sure you own the ROI for the project. You have two responsibilities to your company: one is to solve the business problem, the other is to make sure it adds real value (in dollar terms) to your company’s bottom line. If a specific feature can gain you a great return on investment but takes 1,000 lines of JavaScript, then I am all for it. Just make sure you really know what the ROI is and that you are able to prove it.
The Designer
You cannot design in a technology vacuum, you must design with the development platform in mind. Given that APEX was chosen to build the solution you should make considerations for it when designing the solution. If you build a design that you know will require the developer to jump through hoops, then you are just as culpable as they are in adding to the complexity debt.
Your organization chose APEX as its development platform. It is Oracle’s problem if APEX does not provide the features that your users need. If that should ever happen then your organization should switch to a different development platform instead of making APEX do unnatural things.
The End User
As much as we would like to say the end user is king, it is not always the case. I bring you back to the reason for building software which is to get a return for your investment. If that ROI can be achieved and the user must make an extra click, then so be it. Now that is not an excuse to deliver any old garbage. There is never an excuse for not delivering an enjoyable and productive user experience. Just don’t do it at the expense of the real prize.
The Developer
Code responsibly. If you want to show that you can build Pacman using pure JavaScript and CSS then do so on your own time. Also, don’t be afraid to speak up when the design does not smell right. If you think a particular design decision will corner you into writing 300 lines of JavaScript, then say so. Explain what the implications are and the potential downstream costs. Most of the time people will be receptive to your feedback.
Return on Investment
Most of the time, the only reason systems are developed is to provide a return on investment. The same logic that made you decide to build the system should also be applied when deciding how you should go about developing certain features. When building an App, there is usually one killer feature, the App’s reason for being. The time to stray from the ‘code responsibly’ approach (if at all) is when it really counts. But, you should only do this if the killer feature sets you apart from the competition or has a known positive ROI.
If adding the feature is going to provide you a return of $20,000 over the next 7 years then go for it, otherwise, think carefully.
Conclusion
APEX is a fantastic development platform. It frequently produces applications that delight users and exceed expectations of project sponsors. It does not, however, prevent complexity (and therefore extra cost) from creeping in unless we are diligent. Code Responsibly!
RSS Feed