Convenience drives much of the world’s best technology, from Amazon Web Services to Web frameworks like AngularJS. But that “convenience”, which makes it easy to quickly become productive, often comes with a hidden price tag: to become truly productive, you’re going to have to sweat.
Great technology is often deceptively simple, allowing newbies to intuitively “learn” the system without much effort. The problem comes when people assume they have mastered the technology when all they’ve really done is the equivalent of coding a “hello world” app. Before you blame the tool, you often need to invest time in learning to use it correctly.
“Mixed Feelings” About AngularJS
The problem, as Anand Mani Sankar suggests, is that while it’s simple to start with AngularJS, that simplicity belies the power of the framework:
[AngularJS] also simplifies the application development process by abstracting a lot of the internal complexity and exposing only what the application developer needs to know.
While this sounds like a great thing, it can also lead newbies to think that they’ve mastered the system upon completing their first “hello world” app:
The AngularJS journey can evoke mixed feelings. The learning curve is very different from other JS frameworks. The initial barrier to get started is very low. But once you start diving deep the learning curve suddenly becomes steep.
Sankar then points to Ben Nadel’s humorous depiction of an AngularJS journey:
Some people, of course, get stuck in the troughs. George Butiri, for example, gets a lot of Google search love with his “The reason Angular JS will fail” post. Butiri argues that AngularJS is actually quite difficult, without giving much in the way of specific examples of why this is so, at least beyond “because I like jQuery more.”
It’s So Easy To Fail
Much of the best technology is like this. It’s deceptively simple to get started, but if you want to truly master it, you’re going to have to make a big investment of your time. Some people start strong, discover the complexity, and then complain that technology doesn’t remain mind-blowingly easy forever and ever.
Sorry, real technology doesn’t work that way. It always requires effort and will fail if not applied in the right way.
Take NoSQL databases, the world in which I spend most of my time.
Newbies to NoSQL, whether MongoDB, HBase or Cassandra, like to tout its schema-less nature. The old world of relational databases required a rigid schema but HURRAY! In this new world of NoSQL, gone are schemas that define your data’s structure, gone are DBAs, GONE ARE RULES! So easy!!
Which, of course, is complete nonsense. As my colleague Asya Kamsky likes to say, “NoSQL != NoDBA.” (That is, NoSQL is not the same as “no database administrator.”)
NoSQL does not mean “no DBA”. If anyone tries to convince you otherwise, they probably have something to sell you.This does not mean that you have a team or even a person who has the title “DBA”—however, if you have a database, whether it’s relational, or non-relational, then someone has the role of “DBA”—and if they don’t know that they do, then a whole bunch of things aren’t being done or thought about before problems happen.
Go through the hater posts about NoSQL databases or AngularJS or most any technology you prefer and I guarantee many, if not most, of them are written by people who feel cheated that the technology didn’t fit how the user wanted it to work, often with minimal to no real investment. Sure, sometimes technology fails. At times, spectacularly.
But far too often we complain when technology doesn’t magically remove our need to work.
Fewer Levers, More Happiness?
One way to get the best of both worlds is through managed services like Amazon Web Services’ Redshift. Redshift is a fully-managed data warehouse that runs in the cloud. “Fully managed” means that it’s easier to use, but it also means that users lose some of the knobs and levers they might have in Teradata or another enterprise data warehouse.
That, however, is precisely the point.
As Matt Wood, general manager of data science at AWS, told me recently, Redshift and other AWS services aim to improve ease-of-use for users by removing complexity. Giving users fewer “levers” means that AWS also gives them fewer ways to fail. The trick, of course, is finding the balance between product simplicity and user control.
Airbnb, for example, was elated by how easy Redshift was to begin with, but then required some trade-offs (and investments):
The first challenge we had was schema migration. Even though Redshift is based on Postgres 8.0, the “subtle” differences are big enough, forcing you into the Redshift way of doing things. We tried to automate the schema migration, but the problem was bigger than we originally expected and we decided it was beyond the scope of our experiment. Indexes, timestamp type, and arrays are not supported in Redshift, thus you need to either get rid of them in your schema or find a workaround.
Having put in the effort, however, Airbnb saw a minimum of 5x performance improvements over other systems and dramatic cost savings. Easy to get started, but also worth continuing to invest.
And so it is with a lot of great software that is deceptively simple to use. To get beyond newbie status with any great technology, you’re going to have to use it as intended, and you’re going to have to spend the time and effort to master it.
There may be free software, but there’s no free lunch.