Services change. Get used to it.

Want to pick a little fight? Talk about football. If you’re in most of the world, the 2014 World Cup is already looming on your horizon. If you’re in the United States, then you’re probably thinking about next month’s Super Bowl XLVI, the big matchup between American Football teams. (This year, I’m rooting for my native New England Patriots. Prefer the New York Giants? Let’s take it outside.)

Sports. Politics. Religion. Those are all tiny little trivial fights. If you want a big fight, look at reactions whenever Facebook changes something. The vitriol flies as millions (billions?) of users rage against Facebook’s audacity, whether it’s something minor like friend recommendations or something major like the forced migration to the new Timeline personal profile. (I like Timeline. Disagree? Let’s take it outside.)

Commercial services change and evolve, whether their customers like it or not.

• Sometimes services change in order to attract new customers.

• Sometimes services change in order to fend off competitors.

• Sometimes services change in order to directly drive revenue.

• Sometimes services change in order to improve customer lock-in.

• Sometimes services change in order to reduce costs or improve profit margins.

• And sometimes services change in order to increase customer satisfaction. (In my experience, that’s rarely the driver.)

My neighborhood has a wonderful grocery store. About a decade ago, it was looking a bit rundown. A competing supermarket did a major remodeling – and shortly thereafter, so did our neighborhood store. The results were terrible. Too few shelves, a wide-open arrangement that was pretty but had less merchandise. A few months larger, the store remodeled again. It had no choice. But each time the store changes (and the owner continues to experiment and innovate) we find the disruption annoying — then can’t find our favorite foods. We don’t like the change. After a few weeks, we get used to it. And then we don’t like the next remodel. Hey, that’s just how life is.

While the owner may say that he’s remodeling in order to make the store nicer, most of the time he’s motivated to drive revenue or cut costs. As long as he doesn’t make the store much worse in the process, and thereby lose too many customers, it’s a good business move.

What about software? When we talk about products like Microsoft’s Visual Studio or the Eclipse JDT or IBM’s DB2 – you have a lot of choices when it comes to change. Since software is delivered as bits, you can choose to upgrade to the bits or not.

• You can choose to install the new bits as soon as they come out – maybe the upgrade solves a specific problem you had, swats a scary but or offers some compelling features.

• If you're nervous or on a budget, you might wait for first point release or service pack or even hold back for next major release.

• You might decide never to upgrade.

• Or, if the upgrade is sufficiently obnoxious, you might switch products altogether.

That only works when software is a product. What about Software-as-a-Service? When you use Facebook or the Google Calendar APIs or a hosted code repository or a hosting package, you aren’t using software. You are using a service. You aren’t buying or licensing software. Your ability to upgrade, or to sit back and wait, is totally at the whim of the service provider.

Some service providers, of course, give customers the option to migrate early to new versions of their service, or to temporarily delay the migration. Some do not give you a choice. When you buy bits, you are in control. When you use a service, you are not in control. Whether it’s Facebook, your code repository, the layout of your local supermarket or the television channels carried by your local telecommunications provider, you can either go along with the change or find a new service provider.

Sadly, few consumers understand or appreciate that services are services. They don’t understand why they can’t stay on Facebook 2008. They don’t understand why the changes don’t reflect their own desires.

That’s not how it works. Facebook isn’t making changes for the benefit of its existing customers. It’s making them in order to help its own bottom line by creating new money-making opportunities for itself and its partners, while also encouraging users to spend more time on the site (so they see more ads). The company is betting that while many customers will complain, relatively few will actually leave the service. Plain and simple.

Now, how about those Patriots?

Put away the forklift, I've got FORTRAN on my mind

The smell of fresh ink. The source-code listings. The structure. The structure! I am thoroughly enjoying my review copy of “Modern Fortran: Style and Usage,” by Norman S. Clerman and Walter Spector.

FORTRAN (or as it’s now called, Fortran) was one of the first programming languages I learned and later taught. In my mainframe environment, it was COBOL, FORTRAN and PL/1, plus a little LISP. Throw in some job control language and the occasional assembler, simply to break up the monotony. What a wonderful world.

Cryptic languages like C belonged to a parallel dimension inhabited by the VAX down the hall. Foreign. Alien. Bizarre. C was for programming telephone switches. It simply wasn’t part of my department’s business-oriented computing culture.

Did you learn FORTRAN in school? Use it for numerical or scientific work? Certainly the language was a delight to program, whether you coded in the immortal FORTRAN IV (my favorite) or that new-fangled FORTRAN 77.

FORTRAN 77 was the most recent dialect from my life as a professional programmer. The object-oriented Fortran 90 (where everyone moved to writing the language as Fortran) was never part of my life, except as a spectator. But I’m fascinated by how the language has grown and evolved. The addition of generics to Fortran 2003, and now parallel processing with Fortran 2008, truly brings this ancient procedural language into the modern era.

Think about how programming languages come and go. In the big-box era, we focused on structured, procedural and imperative languages, like FORTRAN, COBOL, RPG and the rest. While BASIC was designed as a structured teaching language for timesharing systems, it caught fire with the microcomputing era. C evolved for the world of Unix and for close-to-the-hardware control systems like those phone switches. FORTH, LISP, SMALLTALK and APL were specialized tools for specialized projects.

The pendulum swing to objects. Inspired by Smalltalk, everything was about C++, Objective C and Java. And then it became about scripting languages like JavaScript, Perl, PHP, Python and Ruby. And then domain-specific languages. But in reality… we’re using a little bit of everything.

That’s the way it should be. We should update the best of the old, while also creating new tools with the latest concepts. Put away the forklift, I’m busy reading “Modern Fortran.”

Fast cars! Fast phones! And a new developer conference!

Toys, toys, toys. I love to read about new toys, especially sleek sports cars and nifty computerized gadgets. This week has been a bonanza – from two different directions.

You might think my focus would be on the big annual Consumer Electronics Show in Las Vegas. Actually, I’ve been more keenly following the happenings at the North American International Auto Show, which kicked off January 9.

Dozens of exciting cars and concept vehicles were introduced at the NAIAS, which is also known as the Detroit Auto Show. They include a smokin’ hot Acura NSX super car (pictured), the futuristic Lexus LF-LC, a new Mini Roadster, the four-door Porsche Panamera Turbo R, the fast-looking Mercedes SL550, the BMW i8 electric car… the list goes on and on.

A big part of the news from Detroit overlapped what was also talked about at the Consumer Electronics Show. Sure, CES features lot of “ultrabook” lightweight notebook computers, incredibly thin televisions, high-definition digital cameras, three-dimensional printers, even electric razors. But automotive computers were very much front and center.

There’s a lot more to computerized cars than iPod jacks or even streaming Pandora on a 28-speaker Bose sound system. Companies like BMW, Ford and Mercedes-Benz are integrating phone applications with vehicles’ onboard computers. The smartphone sends the car email and text messages. The car sends back real-time diagnostics. I’m told you can even make phone calls!

Soon, you will update your car’s firmware as often as you update your smartphone’s apps.

To change the subject only slightly: Let’s talk about developing smartphone software. You know that BZ Media – the company behind SD Times and News on Monday – produces developer conferences for Android and iPhone/iPad developers. We are proud to announce support for another platform at WPDevCon: The Windows Phone Developer Conference.

WPDevCon is coming to the San Francisco Bay Area from Oct. 22-24, 2012. We are currently assembling a full slate of workshops and technical classes, and the program will be ready in early March. However, we invite you to check out the website, www.wpdevcon.net, and of course, mark your calendar if you or your colleagues are interested in attending.

Want to propose a class? See the Call for Speakers and then drop me a line. Interested in exhibiting? Contact my colleague Adam Teichholz.

Which is more interesting to you, the latest cars at the Detroit Auto Show or the snazzy gadgets at the Consumer Electronics Show?

Securing the data

Whose fault is it when data is stolen? It’s rarely blamed on the programmers.

If a company executive leaves a laptop filled with confidential data in a taxicab, you probably wouldn’t blame a software developer. Instead, you’d presumably ask, why was that data on the laptop to begin with? I’ve often wondered why corporate executives have access to customer card information in the first place, and why security policies allowed such data to be downloaded to any end device, especially a not-locked-down laptop. But you wouldn’t blame the programmers.

If an unencrypted data backup tape disappears en route to a secure offsite facility, you’d yell at a sysadmin, not at a C++ coder. “Why wasn’t the data encrypted?” you’d want to know. “How could it be written in plain text?” That’s the fault of the backup software, or again, security policies – not programmer who wrote the applications whose data is being backed up.

Now, who do you blame when hackers violate credit-card terminals? My family’s local grocery store – Lucky’s in Millbrae, Calif. — was recently penetrated by so-called skimmers, who tampered with in-store card readers and grabbed up to 500 customers’ credit card numbers. As far as we can tell, our credit card wasn’t compromised – but you can trust that we’ll be scrutinizing the Visa bill extra closely from now on.

Certainly, you can blame Lucky’s, for not ensuring the physical security of those devices. But what about the back-end programmers for the grocery chain? How about the embedded developers of the card reader’s firmware? Or how about any number of applications that were involved, from the credit-card clearinghouse to the bank? Could programmers be anyway responsible? Could they have done something, anything, to prevent this incident?

The reality is, well, no. It’s unlikely, especially since the devices were physically tampered with. But even so, it’s impossible for programmers to anticipate every possible scenario, or to model every type of threat to a complex web of applications developed by many companies, and administered by many companies.

No series of locks and alarms can truly prevent a home from being targeted and robbed by criminals – or burned down by arsonists. And there’s an increasing awareness that there’s nothing that developers can do to sure today’s modern interconnected application 100%. But that doesn’t mean that we shouldn’t try.

Remembering John McCarthy

Computer scientist John McCarthy passed away in October 2011. In an SD Times end-of-year retrospective, cryptographer Whitfield Diffie wrote a personal essay focusing on McCarthy’s work on the creation of public-key crypto.

Diffie’s presented a different side of McCarthy, whom I knew mainly for his pioneering work on artificial intelligence and the LISP programming language. The only time that I recall meeting John McCarthy was at the AAAI conference in 1991, back when I was the editor of AI Expert magazine.

Shortly after our retrospective was published, we received a letter from an irate reader, Peter Schow, who insisted that our tribute was all wrong:

I was stunned to read the John McCarthy tribute in the SD Times December 2011 and not see his foundational contributions to functional programming, Lisp, and artificial intelligence (he invented this phrase!) mentioned at all! His book "LISP 1.5 Programmer's Manual" (1962) is a classic in Computer Science and is still very relevant today, especially as functional programming is undergoing yet another revival in languages like Scala and Clojure.

The title should have been entitled "Father of Lisp and AI" but instead the tribute appeared to be hijacked for the purpose of highlighting the author's public key cryptography invention. It's mildly disturbing that we are forgetting our history, short as it is, and you owe it to yourself to investigate the subject of John McCarthy's lecture when he received the 1971 ACM Turing Award. I'm shocked that your editors could have let this been published and I think you owe your readers a true memorial to John McCarthy.

John McCarthy is a legend — and his work in crypto is no less important than his work in AI. He deserves to be recognized for his contributions in both areas. I’d like to thank Whitfield Diffie and Peter Schow for sharing two views of this incredible man.

(You can read another view in the SD Times obituary of John McCarthy, written by Alex Handy.)

Introducing AnDevCon III, May 2012

AnDevCon III – the third iteration of our Android Developer Conference – will be coming back to the San Francisco Bay Area from May 14-17, 2012.

We had some excitement scheduling this conference, as those who attended AnDevCon II in November observed.

At first, we scheduled AnDevCon III for April 2012 (and publicized that in the show program we gave away at the conference). But then in mid-October, Google announced that Google I/O – its two-day tech conference for all things Google, not just Android – would be on April 24-25.

“That’s not good,” we said. So our team went back to the drawing board and found some great dates in late June – and began gearing up for a public announcement.

But then Google decided that Google I/O needed to be three days – and they changed their dates to be June 27-29. Which happened to overlap the second set of dates we had selected for AnDevCon III.

In the words of the bowl of petunias in Douglas Adams’ “Hitchhiker’s Guide to the Galaxy,” we said “Oh, no, not again!” Back to the drawing board.

Unless Google changes its mind (again), AnDevCon III will be May 14-17, 2012. As before, the first day will be pre-conference workshops; the other three days will be filled with technical classes.

We are very excited about AnDevCon III. We aren’t anticipating many changes from AnDevCon II. However, there will be lots more coverage of alternative platforms beyond smartphones and tablets. Thus, you’ll see more embedded Android sessions, an expansion beyond the single class we had on the Android-based Google TV, and also a deeper dive into Arduino.

Mark your calendars, and we look forward to seeing you there!

Why is video conferencing so hard?

Video conferencing is difficult. Whether you’re using a phone, tablet, desktop or laptop, there are challenges everywhere.

• Video conferencing requires that all participants use the same service.

Whether it’s Skype, Oovoo, FaceTime, AIM, Tango, Fring, Google Talk, WebEx, GoToMeeting, AnyMeeting or whatever, that means a plethora of accounts – and of course, not all accounts work (or offer the same features) on all device types or operating systems. In order to get advanced features many services want you to pay for a premium subscription. When you need multiple services to be compatible with your friends, colleagues or customers, all those subscriptions can get expensive.

• Audio and video quality is really spotty.

Recently I did a video interview using Skype – I was on a T1 line in California, and the other participant was using ADSL in Florida. The images and sounds kept breaking up, synchronization was terrible, and every so often one of us would lose the picture entirely. That means breaking and reestablishing the connection between our PCs. The experience was pretty bad.

Another time I did a FaceTime chat between my iPad 2 and an industry expert using an iPhone 4. Audio and video was generally outstanding, but at one point the call dropped and we had to restart. Of course, FaceTime is only available on iOS or Mac OS X.

• Multi-party conferencing is a nightmare.

Some services only allow two parties on a video. Some can handle up 6 users sending video; a few can handle more. But again, everyone has to be on the same system. With most services, only user needs to have a premium account, but on others everyone must have a paid account.

• Ease of use and functionality is spotty.

Each system requires its own user directory. The means for users to sign into and sign out of multiple user chats varies. It’s a mess. Recording video calls? Some services have that built in, others don’t offer it at all. Some only allow the host to record. The user interfaces are uniformly terrible, and documentation is worse. I’ve never found a scalable, cross-platform system that’s truly easy to use.

Imagine if standard wireline or mobile wireless calls worked like this. “Sorry, Bob, we can’t add you to our conference call because you use Verizon.”

We are used to calling any telephone number from any telephone. Doesn't matter if it’s mobile or wireline or even Voice-over-IP; doesn’t matter who the carrier is; doesn’t matter whether it’s CDMA or GSM. Whether you are calling Boise, Bangalore, Brussels or Brazzaville, if you know the phone number, you can make the call.

Yet with video, there’s too much manual handshaking required, and hoops that must be jumped through. Shall we use Skype or Google Chat? Oh, we can’t do AIM because I have a Microsoft Messenger account. We can’t use FaceTime because you have an Android phone. We can’t do video at all because your company has a firewall.

Picking up the phone is better than email. A video call is better than a phone call. And a video conference call is better than an audio-only conference call.

I can’t wait for this technology to mature and work properly.

Was Apple right about Flash?

As you may have seen a few weeks ago, Adobe is giving up on Flash for mobile devices, and is embracing HTML5.

Flash doesn’t run on Apple’s iOS devices. That’s not news, of course. Flash has never run on the iPhone, iPod touch or the iPad. This was a big deal several years ago, especially when the iPad was introduced – how could Apple claim that the tablet provided access to the Internet when so many popular Flash-based websites wouldn’t work?

Pundits declared Apple arrogant in its refusal to install a Flash runtime on its iOS devices. In early 2010, Adobe claimed that the Apple was creating a closed ecosystem with its portable computers, and that Flash was an open technology.

In April 2010, Steve Jobs fought back with his thoughts on Flash. He argued (convincingly in my opinion) that the opposite was true: that Apple, by pushing Web developers to use HTML5 instead of Flash, was on the side of open standards, and that Adobe’s Flash was a closed proprietary system. Jobs further argued that Apple had never seen a Flash implementation that performed well on portable devices.

Since that time – a year and a half – iOS’s lack of Flash has become less and less of an issue. As a consumer who owns both a iPhone and an iPad, certainly I found fewer and fewer websites that relied upon Flash. And although you can run Flash on Android devices (and I own both Android phones and tables), to be honest, this was never a significant reason for me to pick up an Android device instead of an Apple one.

In large part, that’s because developers of popular websites did exactly what Jobs predicted. They either moved away from Flash entirely, or created parallel graphics display systems that sniffed out iOS devices and offered them an HTML5 experience.

Once a website starts down that road, it’s nearly inevitable that the site will abandon Flash altogether sooner or later. I won’t miss it.

It looks like Adobe won’t miss it either. On Nov. 9, the company’s official blog wrote that “Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5.”

The blogger, Danny Winokur, an Adobe vice president, wrote, “HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms.” Yes.

What’s the future of Flash? Adobe says that it is still developing it as a PC-based technology. Adobe has turned its Flex development environment over to the Apache Software Foundation. Flex has been open source software for some time, and while Adobe is expected to continue contributing to its development, Apache will now be calling the shots.

I wonder how long Adobe will hold out on Flash. As a desktop-only platform, it’s not very compelling. The future belongs to HTML5.

Picture-perfect software

A four-day weekend doesn’t mean four days without work, not in today’s modern economy. However, a holiday does offer a nice healthy opportunity for improving my life/work balance. Although I spent a lot of time in the office over this year's Thanksgiving holiday, it also meant time pursuing various hobbies – specifically photography.

On one level, photography is an artistic endeavor. It's little changed from my youth when I shot medium-format and 35mm film and developed the black-and-whites in my high-school darkroom. Composing shots, developing film, making prints and displaying my favorites was an analog, creative process.

Today, there’s obviously still an artistic aspect to photography. Taking closeups of butterflies at the California Academy of Sciences in San Francisco, or catching whales playing near Pacifica Pier, or shooting a fast-paced girls’ soccer game (AYSO under-14 – one of my best friends is the coach) is about having a good eye and feel for the photograph, not about having expensive technology.

Everything else about photography is about hardware and software, some embedded, some desktop, some living in the cloud.

• The proprietary microprocessor inside my Canon EOS SLR runs sophisticated firmware that couples the image sensor, auto-focus sensor and some AI to get the shot, while calculating exposure and stabilizing the image.

If you shoot RAW images (which I do), the bits are then transformed by codecs and then stored onto the camera’s memory card.

If you shoot JPEG images, there is more embedded software to apply creative post-shooting image transformations and real-time file compression before being written to the memory card.

Every so often, Canon offers firmware updates for my cameras, sometimes to fix bugs, sometimes to improve performance and sometimes to offer new functionality.

• My Mac accesses the same file system and copies the raw image files onto a hard drive. While the software there is not photography-specific, the operating system is essential for managing my digital images.

• Adobe’s Lightroom software helps me manage all the photographs in my library – tens of thousands of them, all indexed in a super-fast metadata-rich database. Lightroom also contains tools for manipulating the images files, using efficient algorithms, and can exporting them in other formats – or even upload to online services.

• Occasionally I need to do more sophisticated manipulation of the images, and in those rare cases the tool-of-choice is Adobe’s Photoshop CS5 – which is not only incredibly sophisticated software, but which also has plug-in capabilities.

But wait, there’s more:

• I often share my photographs on Facebook or upload them to Google’s Picasa service. Both those services are built around massively distributed databases with strong backup. Facebook uses a map/reduce-based system for distribution of metadata about the photographs, letting all my friends, friends of friends, and others see the pictures, see if they’ve been tagged, read and add comments, recognize faces, and so-on. My mind boggles when considering the data/metadata infrastructure within these social-media giants.

• If I want to print the images, my Canon ink-jet printer also has some pretty advanced algorithms to transform the bits into the 10 specific colors of its pigment tanks, and implement dithering patterns to create even more apparent colors.

Have I written any photo software? Nope. But between embedded firmware in my camera and printer, desktop software on my iMac, and Web-based software in the cloud… there a lot to think about while setting up that perfect shot of Thanksgiving dinner.

David Gerrold, Tribbles, cookbooks and more

You are undoubtedly wondering, “What’s going on with the SD Times team? What are those editors up to?” Let's find out:

• Do you like tribbles? Read our new online column by David Gerrold, a longtime programmer and writer of the landmark episode of Star Trek, “The Trouble with Tribbles.” See his introductory piece, “Looking Backwards,” here.

I had the pleasure to work with David in the early 1990s, when he was a contributor to Computer Language Magazine and its CLMFORUM on CompuServe. It’s a pleasure to welcome David to SD Times as a columnist and blogger. Hint: Keep off his lawn.

• You may have noticed that former SD Times columnist J.D. Hildebrand began blogging for us a few months ago. J.D., a long-time technology writer, is the former editor of Computer Language Magazine, Unix Review, Windows Tech Journal and Embedded Systems Programming. He was one of the debut columnists in the very first issue of SD Times, in February 2000, and we welcome J.D. back to the team. Read his blog posts here.

• Click here to see a new online section, Developer Cookbook. Assembled by Don Williamson, a marketing exec at GrapeCity – but, more importantly, a world-class barbecue chef – this fun new part of our website demonstrates that there’s a lot more to programmer cuisine than pizza.

What about events?

• We recently completed our fantastic Android developer conference, AnDevCon II. It was a huge success. I am delighted to announce that AnDevCon III will be June 25-28, 2012, back in the San Francisco Bay Area. We are building its website, and will share more details soon.

• If your organization uses SharePoint, please join us at the next SPTechCon: The SharePoint Technology Conference. David Rubinstein, editor-in-chief of SD Times and conference chair for SPTechCon, has created an incredible program of workshops, technical classes, keynotes and a lot more. It’s in San Francisco, Feb. 26-29, 2012.

Happy Thanksgiving to all of our U.S. subscribers from everyone at SD Times. May your turkey be moist, and your yams be sweet.