Introduction

How Does it Happen?
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?
- 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 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

- 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)


I am not at all saying you should not use CSS, just use it judiciously.
Plugins

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?
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
