If some bits of Heroku seem to be up, but not others, it could be because those bits are running older versions of the infrastructure. Or are being used as test beds for newer versions of the infrastructure. Or are deliberately running on a separate platform so that, when the main Heroku infrastructure starts having problems, other bits of Heroku's domain are still around to dispense advice on how to work around those problems.
(The most extreme example is a company's "status" subdomain, which ideally should be hosted on a completely different server, in a completely different datacenter, on a different continent located on a distant planet with different DNS regulations.)
I don't have first hand knowledge of this specific incident, but I do have a very deep understanding how the Heroku platform as a whole works. It is incredibly likely for many service disruptions to affect a only subset of applications, and not the platform as a whole. The system is, in fact, specifically designed to isolate failures of individual components to as small a failure domain as possible. That doesn't always work, but implying that there's something nefarious going on or that Heroku is not eating their own dogfood with the devcenter site is dead wrong.
% host devcenter.heroku.com
devcenter.heroku.com is an alias for iwate-88.herokussl.com.
iwate-88.herokussl.com is an alias for elb002001-124710749.us-east-1.elb.amazonaws.com.
elb002001-124710749.us-east-1.elb.amazonaws.com has address 107.20.144.56
elb002001-124710749.us-east-1.elb.amazonaws.com has address 23.21.215.77
elb002001-124710749.us-east-1.elb.amazonaws.com has address 107.21.227.222
It's 100% on Heroku, it's just also using the ssl:hostname add-on (https://addons.heroku.com/ssl) which requires different DNS settings (http://devcenter.heroku.com/articles/ssl#hostname_based_ssl).
http://blog.warsocial.com/post/18262715784/mmmm-dog-food