I am quite certain that JavaScript developers feel this sentiment even more strongly. People like me (veterans of multiple decades of database-centric application development) are seen as dinosaurs, using ancient, uncool technologies.
The things we do seem distant, unimportant, even simplistic, compared to the tough stuff they deal with on a daily basis: asynchronous! streams! containers! microservices! promises!....and so forth.
Heck, I haven't even had to change my "framework" for years and years! :-)
But here's something we should all of us keep in mind:
Sometimes relatively simple tasks can also be critical tasks,Now, don't get me wrong. I am not saying that I think the task of UI developers is not critical.
in which case simplicity becomes a significant advantage (a feature, not a bug).
In fact, I believe just the opposite. If an application needs to interact with humans, then constructing (and maintaining) a intuitive and attractive user interface is pretty much Job #1, TMC: Task Most Critical.
I suppose that's always been true, but it's even more truthier today. And that's because what it means to be a user has changed so fundamentally.
Different Users, Different UIs
For much of my career in software, applications were sold to (or built within) companies. The employees of those companies constituted almost all software users, and they pretty much had to accept whatever they were given. They didn't get to choose which apps they would run. They also got training on how to use those apps.
Of course, they weren't called "apps" back then. They were called applications (or way meaner names, depending on the quality of the....user interfaces).
But now that the Internet has invaded everyone's lives, most dramatically via the smartphone, the typical (and by far most important) user is the consumer.
And that one change has had an extraordinary, outsized impact on the world of software and the people who hand-craft that software.
Allow me to list the ways....
1. Tiny Footprints
Small screens on mobile devices require completely different, and simpler, interfaces.
3. No Time or Place for Training
User interfaces are tightly connected to culture. Corporate culture is relatively stable and slow to change. Consumer culture is a whirlwind, constantly changing, driven both by changes in social mores, by companies seeking to sell more, new stuff, and by changes in what is possible via technological advances.
2. Users Choose
Users get to choose from a wide variety of apps in their app marketplace (Apple's App Store, Google Play for Android). They no longer having to simply accept whatever is handed to them by an uncaring employer.
3. No Time or Place for Training
The apps have to be usable without training, really without much of any thinking on the part of the user, 'cause who's going to pay for that or even sit still long enough to absorb the training?
4. If It's Not Free, I'm Not Paying For It
Ah, it could have been so different. Maybe it is in a gazillion alternative universes. Maybe in all those other universes, we haven't made a bargain with the devil. We haven't agreed to give away our privacy, our eyeballs, our brains to companies in exchange for "free" services: free email, free shipping, free searches, free, Free, FREE!
But we did and now advertising is the dominant model for revenue generation from both ginormous and tiny companies.
What difference does it make who "pays" and how? When it comes to databases, it makes an enormous difference! (as it does when it comes to the preferences and behavior of young humans who are assaulted daily by hundreds or thousands of ads).
5. Say No to ACID
Reliance on advertising leads to a higher value placed on aggregate data, in addition to (or at least in some developers' minds, as opposed to) transactional data.
For decades, data was collected in relational databases (and still is, of course), and collection was occurred as a series of business-critical transactions. When you saved your changes, baby, they were in there, right then and there, the gold standard of your view of the world.
But as the volume of data increased, the nature of that data also changed. Suddenly it was OK if the data was eventually consistent, heck it was even OK if some data was eventually found to be lost. Missing out on a tweet is a lot less critical than missing out on a deposit to your bank account.
6. Culture Drives Interfaces
User interfaces are tightly connected to culture. Corporate culture is relatively stable and slow to change. Consumer culture is a whirlwind, constantly changing, driven both by changes in social mores, by companies seeking to sell more, new stuff, and by changes in what is possible via technological advances.
The faster culture changes, the more rapidly developers must adjust their UIs to keep up.
7. Bye, Bye Monoliths
Apps are now built on a widely distributed network of services, rather than a monolithic "single source of truth." Apps and their data sources must be able to communicate flexibly, asynchronously, securely and quickly with each other.
The age of microservices, of bots, of APIs has arrived, bringing with it an enormous amount of confusion and complexity.
That's A Lot of Change
Is it any surprise, given this amount of fundamental change, that no one feels like they have the time to think through a data model, sort out referential integrity, define check constraints?
And why bother?
Two minutes after finishing version 25 of that model, you have to go back and work on version 26!
Well, we on the database side know why it's worth the bother, but you still have to find the time and away....
As we all ever more manically focus on UI design and simplicity, simultaneously
under the covers everything gets fantastically more complex....and the database is increasingly hidden from view.
Let Us Help You
But the database is still there. Well, actually, more likely lots of different databases are still there.
And the data inside those databases is still also absolutely critical, the lifeblood of every company.
So here's the thing: if the code you write to manipulate the data in the database is bad news (if, for example with the Oracle database, you write SQL that processes data on a row-by-row basis and pretty much avoid PL/SQL altogether), you will end up with performance problems, junky data, and security leaks.
And, consequently, really unhappy users. Regardless of the beauty of the UI.
So, really, it's OK if you scoff at the "old style" procedural approach of PL/SQL. And I get it if you dismayed at how hard it can be to adopt a set-oriented mindset and write great SQL.
No offense taken.
But please don't dismiss the importance of the database layer in your stack. Do maintain high standards and expectations for how your database supports your UI.
Make sure that your team includes database experts who know all about how the database can improve application performance and security, and make UI developers more productive:
Good news: you will likely find that a ratio of 4 UI developers to 1 database developer is sufficient to ensure that all UI developer requests for changes to the data API are satisfied smoothly. Again, the upside of our "simple" backend life: we can churn out PL/SQL-based APIs to SQL/data and wrap them in REST endpoints very, very quickly!
So, thank you, UI developers, for taking the brunt of the pain and frustration of working directly with users to sort out the user interface and functionality they need. And do look to us to help you with the database-centric heavy lifting, ensuring the best possible performance, security and integrity for your data access.
Some Resources
To help you get up to speed on SQL and PL/SQL and generally developing backend code, my team of Developer Advocates offers a whole boatload of videos and blog posts and scripts and quizzes and classes to help you. Check out the resources below.
Videos
Simply Smarter SQL
Magic of SQL
Practically Perfect PL/SQL
Community Sites
Oracle Dev Gym - Quizzes, workouts and classes on database development
Oracle AskTOM - Definitive answers to tough database questions, plus a new Office Hours program offering monthly, free, live Q&A Sessions
LiveSQL - Free SQL and PL/SQL playground on the latest version of Oracle Database + code library + tutorials
Working with JavaScript?
Check out Dan McGhan's JSAO.io site for all things JavaScript and Oracle.
Is it any surprise, given this amount of fundamental change, that no one feels like they have the time to think through a data model, sort out referential integrity, define check constraints?
And why bother?
Two minutes after finishing version 25 of that model, you have to go back and work on version 26!
Well, we on the database side know why it's worth the bother, but you still have to find the time and away....
As we all ever more manically focus on UI design and simplicity, simultaneously
under the covers everything gets fantastically more complex....and the database is increasingly hidden from view.
Let Us Help You
But the database is still there. Well, actually, more likely lots of different databases are still there.
And the data inside those databases is still also absolutely critical, the lifeblood of every company.
So here's the thing: if the code you write to manipulate the data in the database is bad news (if, for example with the Oracle database, you write SQL that processes data on a row-by-row basis and pretty much avoid PL/SQL altogether), you will end up with performance problems, junky data, and security leaks.
And, consequently, really unhappy users. Regardless of the beauty of the UI.
So, really, it's OK if you scoff at the "old style" procedural approach of PL/SQL. And I get it if you dismayed at how hard it can be to adopt a set-oriented mindset and write great SQL.
No offense taken.
But please don't dismiss the importance of the database layer in your stack. Do maintain high standards and expectations for how your database supports your UI.
Make sure that your team includes database experts who know all about how the database can improve application performance and security, and make UI developers more productive:
- Experts who will take full responsibility for that part of the stack, who understand that the main point of their job is to help you succeed.
- Experts who know how to work with JSON in the database, and build REST-based APIs on top of a hard-shell PL/SQL API (#SmartDB) for easy JavaScript (and Python and....) consumption.
Good news: you will likely find that a ratio of 4 UI developers to 1 database developer is sufficient to ensure that all UI developer requests for changes to the data API are satisfied smoothly. Again, the upside of our "simple" backend life: we can churn out PL/SQL-based APIs to SQL/data and wrap them in REST endpoints very, very quickly!
So, thank you, UI developers, for taking the brunt of the pain and frustration of working directly with users to sort out the user interface and functionality they need. And do look to us to help you with the database-centric heavy lifting, ensuring the best possible performance, security and integrity for your data access.
Some Resources
To help you get up to speed on SQL and PL/SQL and generally developing backend code, my team of Developer Advocates offers a whole boatload of videos and blog posts and scripts and quizzes and classes to help you. Check out the resources below.
Videos
Simply Smarter SQL
Magic of SQL
Practically Perfect PL/SQL
Community Sites
Oracle Dev Gym - Quizzes, workouts and classes on database development
Oracle AskTOM - Definitive answers to tough database questions, plus a new Office Hours program offering monthly, free, live Q&A Sessions
LiveSQL - Free SQL and PL/SQL playground on the latest version of Oracle Database + code library + tutorials
Working with JavaScript?
Check out Dan McGhan's JSAO.io site for all things JavaScript and Oracle.