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.
I've to admit I had a fun time reading this and a lot of it sounds so recognizable. It's also not very often you put so much sarcasm in your writing. ;-)
ReplyDeleteShhh! Don't get me in trouble. :-)
DeleteI can't see any sarcasm here. This is exactly how you have to talk to UI-developers.
DeleteHello All,
ReplyDeleteIt is interesting what Steven says about building the UI interface being a much more
difficult task than performing the backend database development tasks.
I think that is is ultimately a matter of experience, of what you are more accustomed
to do every day.
Tom Kyte used to say something very similar, namely, that he always found it strange that so many developers who were able to master the intricacies of a language like Java
find it however so difficult to understand the basics of how the database works
so that to be able to program correctly and efficiently the database part of their application,
while he himself, on the other side, found all the database knowledge much easier
to learn and understand than a language like Java or C.
The UI developers themselves also feel differently about the various UI development tools,
depending, of course and again, on their amount of daily experience.
For example, once a developer told me that "APEX is easy, unlike Oracle Forms !"
which I found extremely surprising, since, in comparison with my many, many years experience with Oracle Forms, I still find APEX hard to understand and master.
Sometimes I asked myself why is this so, and my only explanation is that everything
is a result of the way in which you were "educated" in what you are doing.
The fact that the database development principles "did not change" along all these years just underlines in my opinion the solid foundation and principles that the database side relies on, in comparison with the completely volatile UI-s.
For the database side development, we did have and still do have all the good teachers and teaching available, in all forms: professional people, books, web material, and so on.
On the other side, for the UI development, which is becoming daily more and more intricate,
practically everyone who pretends "to teach you", instead of starting from the very basic principles of how each new tool works, even from ground zero if needed,
is always starting from somewhere "in the middle" supposing that all the rest is already known,
while for many people, including old and experienced developers, this is not so.
Oracle did the very same in the last several years:
Almost every day they are introducing new technologies and making the Oracle database support them and/or interface with them, without including enough introductory material/education for complete newbies on those topics.
I don't think that there is any reason for a good developer to not be able to be prepared for any development environment, be it database or UI side, with the only condition that the foundations of that platform be set up properly in his mind.
Unfortunately, however, with new technologies popping up each other day,
it is not possible to expect high levels of experience to be accumulated with any one of them, before it is already replaced by another one.
And, also unfortunately, experience seems not to be really necessary or appreciated any more.
When introducing all these many big-data operations, the world discovered that data integrity is not essential any more ...
Just in the same way, it also adopts the optics that it is more important to have a colorful UI, with just a few simple operations, but operating from a mobile phone, regardless of how many flaws that UI interface might introduce into the database ...
The time of us, the older ones, seems to have passed ...
and it's really a pity that the "new world" mostly does not realize the high potential that still resides in the brains of the old and experienced professionals.
Thanks a lot & Best Regards,
Iudith Mentzel
"the world discovered that data integrity is not essential any more ..."
ReplyDeleteExactly what I thought when I started to read up on MongoDB. (Oracle Developer 20+ years)