Youngster? Gee, thanks! I remember writing my first program on a Commodore Pet with 4K of RAM. Used peek and poke statements to draw the game field on the screen and loaded and saved the whole thing on a cassette tape.
The problem here is that you can argue this either way, so let me clarify. When we do systems analysis, we first focus on "happy path" scenarios. You want something, there's no exceptions, you push a big red button and it shows up. Life is good.
For those kinds of behaviors, say provisioning an entire linux stack on AWS, things are rocking. Want to code? Type in a couple apt-gets and you are on your way. There is a huge section of happy path scenarios where things are truly much better than before -- easily enough that many startups can totally stay on the happy path and do awesomely. (And that's exactly what they should do.)
But, alas, because of the dozens of layers of abstractions, and dozens more API, tooling, and hardware configurations, if you are doing anything technically difficult you can easily leave the happy path and get lost in the woods. It's very easy to get into a situation where you are using a combination of a dozen things in such a way as to be almost unique. Yes, each thing is awesome and easy to use, but the scenario you find yourself in is not. It's not called "sad path" A better name for it would be "terrible path of shame and destruction" Ever work inside a problem where you're dealing with multiple edge cases in several layers of complex system that has parts that are inscrutable? Ouch. I've plowed through complex and poorly-written C++ frameworks line-by-line and it's not as bad as that.
The author spun out one such scenario for writing iPad apps, but you could find a hundred of these cases easily. Boards are full of guys asking questions about combining A, B, C, D, E, F, and G into a situation where they are having problems, and responses are usually along the lines of "Hey, I know A, C, F, and G, and here's what worked." Sometimes that's helpful. Sometimes not.
I'm fairly new to linux, although I'm an old .NET/Win32/C++/COM hound. About a year ago, I thought about writing a mono app in F# to do functional reactive programming for the web as a side project. Basically Node. After poking around for a few days, I finally gave up. As far as I could tell, I couldn't find an entry point into a mono app such that I could load the app and hold it in memory, then re-enter from Apache (It probably could be done directly from the command line, but I didn't want to give up Apache) I wanted the speed associated with re-entrency.
Now perhaps somebody will reply and tell me the magic formula to make all of that happen. If so, awesome. But it was just too much bullshit. Finding stuff on Apache? Easy. Setting up a linux box? No problem. Loading up mono? Piece of cake. Getting F# up? A bit of a hassle, but I worked it out. Tying it all together in that unique combination in a configuration not commonly used? A very painful thing. I'm not saying it was impossible. I freely admit being a wus and giving up. But this kind of frustration is all too common any more.
Another example. I help teams a lot. Many teams I help are starting out on their project in a greenfield environment -- it's a new project and everybody is starting fresh. It's not unusual for them to spend a week just getting their environment set up. Now here's the deal: yes, you and I could cherry pick tools and such so that we could set them up in an hour or two, but many times the organizations they are part of have already made these choices for them. So no, it's not git. And no, it's not a plain-vanilla IDE. And so on. I really feel for these guys.
So sure, you can show all kinds of examples where things are a lot easier now than before, and I completely agree. But many folks do not live in that world.