Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

An Appreciation of UI Developers From a Database Developer

DZone's Guide to

An Appreciation of UI Developers From a Database Developer

I'm not saying that the task of UI developers is not critical. In fact, I believe just the opposite. If an app needs to interact with humans, constructing a top-notch UI is Job #1.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

From what I can tell, JavaScript developers write much more complicated code to handle much more challenging requirements than I do with my SQL and PL/SQL programming in the Oracle Database.

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, and 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, in which case, simplicity becomes a significant advantage (a feature, not a bug).

Now, don't get me wrong. I am not saying that I think the task of UI developers is not critical.

In fact, I believe just the opposite. If an application needs to interact with humans, then constructing (and maintaining) an 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 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.

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 have 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, and really without much of any thinking on the part of the user — because 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

(Or Atomicity/Consistency/Isolation/Durability.)

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 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 okay if the data was eventually consistent. Heck, it was even okay 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. 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 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

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


Get comfortable using NoSQL in a free, self-directed learning course provided by RavenDB. Learn to create fully-functional real-world programs on NoSQL Databases. Register today.

Topics:
database ,ui development ,sql ,javascript

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}