Reflections on a Quarter Century

This post is neither about Facebook applications nor Testing, but rather something of a more personal nature.

Today marks the day when I would have been inducted into the IBM Quarter Century Club had I stuck it out in IBM all of these years, and I would have earned the right to put this cool logo on my business cards. But the truth is, I left back in 1996 to join a small startup where I learned that I’d be much happier as a small fish in a small pond rather than a small fish in a big pond. Twenty five years is a long time, and I learned a few things along the way:

• IBM was a great place to start out.
  • I got to work with some really great people, and learned about developing software professionally in a great environment, something that they don’t (and really can’t) teach you in school. IBM allowed me to work on lots of different and interesting projects, paid for my Master’s degree, moved me halfway across the world, and actually paid me a salary the whole time. 
•  Leaving IBM was a good idea.
  • Towards the end of my tenure at IBM, the company wasn’t doing so well, so to turn things around management created this mass hysteria known as Market Driven Quality (MDQ). We were told that it “wouldn’t be one of those Quality programs where you get a coffee mug, and that’s the end of it”. Big mistake. It shouldn’t have existed past the coffee mug stage, but it ruled our lives for a few years. You don’t hear about it anymore, and there’s not even much on the Internet about MDQ, but an interesting description can be found here. One thing it did do was to start to convince me that IBM may not be the place for me. Fortunately, after John Akers was removed as CEO, much of this nonsense was gone and the company really did recover. Except …. without me.
• It used to be really hard to bring new ideas into IBM.
  • Back in 1992 I worked on an IBM product called BookManager, an early attempt at softcopy books (think Adobe Reader, but  a lot less sexy). It looked terrible, but had a very sophisticated automatic indexing and search facility so you could search through large stacks of IBM manuals. A friend of mine and I wrote a proposal to apply this indexing/search technology to the nascent Internet, so you could search for information there (although we weren’t sure why anyone would want to do this …). This is pre-Google, pre-Yahoo, pre-Mosaic! The management we spoke with asked compelling questions such as “What IBM platform does this ‘Internet’ run on – MVS, VM, or OS/2?”. That was the end of that, although I did read somewhere that those Yahoo and Google guys did fairly well for themselves with “Internet search”.
• There’s always something new to learn.
  • Over the past 25 years, I can’t even recall the number of languages, operating systems, scripting languages, IDEs, development tools, and protocols I’ve had to learn and have since forgotten. But that’s good as it keeps you fresh. Last week I learned Jersey, a cool system for writing RESTful Web services in Java. But I still refuse to learn Rails.
• Being a software developer is a cool thing to do.
  • I’ve been able to do it professionally in three different countries. I’ve started my own company. I get to work on something I like doing, and feel like I’m making a contribution to the world. I even wrote a compiler despite the fact that I refused to take Compiler Theory in university because I thought “How many compilers does the world really need anyway?”.
• We’ve come a long way.
  • My first job in IBM was working on this monstrosity for the US Air Force with hundreds of other developers. The team I worked with was involved with something called “packet switching”, kind of cutting edge back then but so ubiquitous today that you never even hear the term used. Sort of like turning on the tap and having clean water semi-miraculously pouring out, packet switching does the same with bytes. The fact that it’s so invisible and pervasive reminds me of how far we’ve come.

I have loads more stories to tell, but also lots of real work to do, so I better get on that. Let’s hope that the next 25 years is as good as the first.

Disclosure Agreements and the Like Button

A short time ago, a company that we’re doing some work with asked us to sign a Non-Disclosure Agreement (NDA). Things like this are fairly common, and I had no qualms about signing it or keeping things confidential. The truth is, we really do take these things seriously when we’re asked to sign. We even have our own NDA that we’ve asked others to sign in the past, but not recently. I started to think about why that was and I realized that NDAs do have their function and place, but in this Social Media-ized environment an NDA seems so dated. I was thinking about why that was and realized that what we really needed and wanted was a, well …

Disclosure Agreement

That’s right – what I’d really like is to have an agreement with everyone we work with that says that we’re legally bound to talk about each other. Something that forces us to tell at least 100 people about our  partner in the hopes that at least 1 or 2 of them will be interested enough to investigate further. Write blog posts, tweet, put links on the website, do whatever else is necessary to tell the world that we believe that those guys are doing something so innovative, valuable, and cool,  that you should also check them out. Isn’t that what all of this social media stuff is all about anyway?

So what do you think about this? Is this a good idea or just really goofy? Are there any lawyers out there forward thinking enough to even try to draft such an agreement? If so, let us know at admin@testfacebook.com.

Until then, I guess the “Like” button will have to do.

Postscript

Two days after publishing this I received an email containing yet another NDA to sign. On the one hand, it’s very positive that other companies wish to talk to us. However, it would be even nicer if they also talked about us to others.

What’s up with deprecated functions?

Facebook has recently made some significant changes to the Platform, and in doing so has deprecated some functions from the API. Deprecation is a developer’s way of getting a do-over. A way to create something better than what’s there currently. However, if developers have applications that depend on those APIs, you can’t just yank them away. You need to to give some warning first, perhaps a transitional grace period, and then you can yank them away. Since the Facebook Platform is so volatile, it’s worth thinking about how to protect your applications in such an environment, and what we should be testing for.

Functions are deprecated for several reasons

There are generally 3 types of things that can have their features deprecated.

• Libraries – such as Java and Windows
• Standards – such as HTML
• REST-oriented APIs – such as Facebook

The owners of these things will typically deprecate their features for one of three different reasons:

There’s a better way to do it

Once upon a time, if you wanted to have something  centered on your page, you’d use a <center> tag to do it. With the advent of CSS, this is now considered to be very bad form, and so the tag has been deprecated.

The underlying implementation has changed which forces a redesign

The Java java.security.Certificate interface represents an abstraction to things like SSL and PGP certificates. As the world moves on and those objects change, holes start to form in this underlying abstraction until someone decides to create a whole new abstraction and deprecate the old one.

OMG! What were we thinking??

If you’ve been around long enough, you’ll be all too aware of the abomination known as the <blink> tag. Now the real truth is, this tag was actually never deprecated, but if any one deserves to be it’s this (well, and marquee too). Deprecated things like this allows developers to sweep their embarrassing stuff under the rug.

Enter Facebook

When a Java function is deprecated, life is pretty straight-forward for developers. The code will stop compiling, and alternate ways of doing things will need to be found (typically specified by the developer of the function). Deprecating an HTML tag is much more complex because it ultimately impacts the servers, clients, as well as the large amount of content that depends on the tag. Things will get broken, and there’s not much we can do about it – that’s the nature of things.

Facebook sits in the middle of this. Since Facebook APIs are ultimately just REST calls, there’s nothing to force your compilation to fail – hey, most Facebook apps aren’t even compiled to begin with. On the other hand, you don’t need to worry about every version of every browser out there. Your application deals with one Facebook server, and when that server’s interface changes, it’s important for you to take notice.

So what happens when you call a deprecated Facebook API?

Given that there’s a good possibility of apps out there that call deprecated functions, it’s important to ask what Facebook does when that happens. The short answer is that they return an error code – API_EC_DEPRECATED (= 11 for those keeping score). It is very important to check for this code and act on it if it’s ever returned. Remember, it’s Facebook’s sandbox, you just get to play in it so you better follow their rules. Calling a deprecated REST function is simply unnecessary, wastes resources, and ultimately will piss off the people who run the servers that your app relies on. Receiving an API_EC_DEPRECATED is akin to being told to “cut it out”. Of course, applications that don’t feel a need to follow the rules are always subject to the Developer Principles and Policies as well as the Terms of Use, things that we’re told are going to be increasingly enforced.

Protect your app

To protect your app, the correct attitude to take is to never be in a position where you receive an API_EC_DEPRECATED when you call a function. Here’s our 3 step plan for how to stay on Facebook’s good side:

1. Keep yourself informed. Know which functions are being deprecated by following all of the Facebook developer resources, and acting on the information.
2. Check your error codes. If there’s one thing that developers hate to do it’s checking the error codes. Make sure to do this, and if you ever get this, make sure the application does something to notify you.
3. Know your code. You may have written this app a year ago, but if it’s still available on Facebook, you need to check it. Get a list of all of the deprecated Facebook functions here. Use grep, or something similar to look through your code to see if you’re at risk.