I was recently tasked with writing an pretty useful extension for Chrome that would enhance Google Calendar so that room numbers on our campus would show links that would take you to campus’s internal map tool. Google Maps does not understand this campus, so the normal map link provided is not helpful.
This task took me the better part of a day and a half, and the whole time I was gripped by this awful feeling that in order to solve this simple problem, I had to learn a bunch of random stuff that would be mostly useless as soon as I was done.
For example, I needed to learn how Chrome extensions work. For that, I needed to familiarize myself with the Google Chrome API — at least enough to get this job done. I can say for sure that even in the small amount of time I spent on that task, I could tell that this API is not stable. They change it as often as they feel like, adding this, removing that, and most ominously “deprecating” some other things. Depracation is the worse. It means “we’re not taking this function way today, but we are taking it away, probably when you least expect it.” And, in any case, how many Chrome extensions is the average programmer going to write?
Furthermore, getting into Google Calendar enough to insert my links was an exercise in pure disposable hackery. I had to reverse engineer enough of Calendar to figure out where to scan for locations and where to insert links. And I needed to understand how Calendar works well enough to know when it is going to change up the document model and set event handlers for that.
This script works today, but it’s obviously going to break, probably very soon, because Google can and will change the internal guts of Calendar whenever they please. Unlike the extension API mentioned above, they are under no obligation, not even an twinge of guilt, to hold their internal implementation of Calendar to some fixed standard.
All this points to some rather sad facts about the future of coding for the web. You’ll absolutely have to work through the supported APIs, and when they change, that’s your problem, and if they are not offered or are incomplete, that’s also your problem, and if they go away, also your problem. Compare that, for example, to a piece of software on your PC. Maybe you wrote an ancient MSDOS .bat file that does something with the input and output of an old program you liked. If the company that made the program makes a new version that breaks your script, you could upgrade to it when you want to — or never, depending on what was convenient for you.
I’ve already been bitten by this. I made an alarm clock that interfaces with Google Calendar using a published API. It is a nice alarm clock with a mechanical chime handmade by hippies from Woodstock, NY. It worked, just fine for years, until, one day, it stopped working. Google had deprecated, and then dropped the API the clock was using. There was a new API. I had to go to my years-old code and rewrite it (to use a substantially more complicated API, by the way).
I guess that’s life, but people who make alarm clocks for a living may be surprised that users want them to provide active support and software upgrades forever. Or maybe we’ll just throw out our clocks after a year or so, like a phone.
But this is a mere annoyance compared to my main concern: unstable platforms discourage the development of knowledge and expertise. Why learn anything well if the entire API, or hell, the only supported programming language, or even the entire theoretical framework for working with the API (does anybody seriously think REST with PUT, GET, and POST is going to last forever?) is going to change next Wednesday? Perhaps that’s why in my interviews with Google nobody ever seemed to care one whit about any of my knowledge of experience.
I, for one, welcome the coming generations of ADD-afflicted software engineers and am excited to see the wagonloads of new “wheels” they’ll invent.
Yippee!
I was going to say “better you than me,” but once I read to the end of your post I understand the point that this actually has very high costs that are borne by the user of the product–kinda like scanning and bagging your own groceries, if you had to relearn how to do that every couple of times you went shopping. But if this is available across campus, then students will stop going to the Chemistry building when they are looking for Legal Studies.
The mapping function is certainly useful, and I hope it works well for people. I guess one solution, perhaps the best, is to get Google to be smarter about mapping within campuses. We’ll see.
But yes, the overall tendency towards recreating everything regularly, and the tendency towards software-as-a-service has some high costs that will be borne by the user, not the least of which is constant retraining, constant updates of interacting systems, and perhaps worst, the price mark-ups that come with lock-in to a system where saying “enough already” is never an option.
I also think this will create generations of computer programmers and users who, not knowing a stable system, will never feel control or mastery over their tools.
Funny you should mention the supermarket checkout problem. I was just ranting about that last night. The supermarkets have rushed in to bring us automated checkout with all its attendant costs for the shopper, but still has not adopted a single queue with dispatch to the next free checker at the end. You can file that under “WTF?!” and “why do supermarkets hate customers so much?”
Whole paycheck near my work almost uses the single que approach (two lines that feed into a single “go to this teller”).
I did not understand most of the technical terms (api?) but completely recognize the problem. At some point stability will become a flashy new product…
API is “application programming interface” and it basically are all the functions that are available for programmers to use. For example, an API for Google Calendar might provide functions for creating, deleting, and listing events. From that you could write you own calendar program that would always be synced with a Google Calendar.
Learning to program is probably more about learning the available APIs than it is about learning the language. Programming languages tend to be small potatoes compared to some of the more complex APIs. In fact, some APIs do not even care what programming language from which you call them.
Which is all fine, except APIs for things on the Internet seem to be largely sturm und drang.
Open source in general has a problem with unstable APIs. I did a Ruby/Rails app years ago and it’s still in use every day, but I’m stuck on a 5-year-old version of Rails with no cost-effective way to move forward. And nobody wants to support that. About the only time you find LTS open-source is when it’s corporate sponsored, e.g. Ubuntu. Opposite extreme, ddwrt doesn’t have stable versions ever — the developers say to use their nightly builds and report bugs.
OSS is simultaneously worse and better. Better, because worst case, you can keep running the version you have, and can even get the source to fix bugs or add features. It’s worse because of the reasons you suggest: volunteers code according to their needs and whims. But if you rely on external services that are also open-source, based, then, I agree, you are in for a world of hurt. Your program will break, early and often.
“If you like your API, you can keep it.” Uh huh…