Platforms and negative-space implications

A super common question in technology is ”what platform do I use?”

Usually answers have an implicit goal of “picking the technology that allows for highest velocity without losing maintainability or extensibility.” From there, you get impassioned debates about feature sets, development cycle speeds, performance, and other things that are considered “intrinsic” to the platform. Somewhere along the line, you might also get discussions about the talent pool that you gain access to. For example, I love OCaml. I would never start a project in it because it’d be unlikely for many people to join me.

Both of these are positive space arguments. Recently, I’ve been thinking about negative space arguments surrounding platforms. You get these for technology sometimes (eg, excluding dynamically typed languages because you want the compiler to ensure progress can be made through all static code paths). What’s less frequent is explicitly making negative space arguments based on a talent pool and communities that you wish to exclude.

Why in the world do you want to exclude a talent pool?

This is a touchy topic because it starts stepping into the realm of stereotypes and type-casting of engineers which runs counter to the published values of the modern tech community. Meh. I’m going to step on this landmine. Please try to read some nuance here. This kind of discussion is by nature grey and fuzzy.

Let’s take Java as a platform choice for an example. Java has its tradeoffs and I dislike it aesthetically but you can build very very large scale maintainable systems that work fine in Java. Need evidence? Look at Google serving infrastructure where Java is one of the primary languages. Or look at Amazon. Could the language and platform be better? Sure. Does it work well enough? Definitely. If you were to create start-up and tell me that you wanted to use Java I’d be overall fine with it.

However, if you worked in an enterprise with an entrenched enterprise XML ecosystem (SOAP, XML-encryption, ESBs, etc) that you wanted to move away from, then I’d become un-fine very fast. Why? Because there is one large segment of the Java ecosystem that is incestuously tied with the XML ecosystem meaning the Java implementation of a standard becomes the “defacto standard” with all the bugs and lack-of-updates that might imply.

Without the XML-blah-blah legacy, Java would be a fine platform choice. However, because large segment of Java that is tied with XML-blah-blah, choosing that as a platform basis for new project will leave you fighting a gravity pull back into the XML-blah-blah world.

In such a situation, picking non-Java platform is important. The argument here is a negative-space talent-pool one. You want to filter against people who are too tied to the XML world. Your platform choice away from Java, in a very coarse-grained way, reinforces this decision.

The insidious thing about making such a decision though is it runs against the values of conservative engineering which tell one consider legacy and integration concerns as a high level bullet.

Choosing a diverge platform thus isn’t so much an project-oriented engineering choice as much as is it as a technical vision move. As such, especially in a non-technical org trained to be make decisions based on technical fear rather than technical data, it takes energy to overcome legacy inertia. However, these sorts of decisions are also critical points for large organizations — much more so than in start-ups because you can’t really pivot a large organization as fast. In such a situation, it’s critical to consider the negative-space aspects of a platform choice.

** BTW, if you’re wondering why I’m picking on XML + Java, I am getting the sense that the enterprise java community is too insular to reap the benefits of an opensource community. Take XML Encryption 1.0 and how it it gets defacto entrenched in the Java community.

XML Encryption 1.0 is fundamentally weak to chosen ciphertext attacks (http://blog.cryptographyengineering.com/2011/10/attack-of-week-xml-encryption.html). Great. So you fix it in XML Encryption 1.1. Problem solved right? Wrong.

In XML-land, SAML is the most popular auth protocol. Never heard of it? Unsurprising. The industry moved away from it, probably at the same time they moved away from SOAP. This means that even though SAML is a written standard, the defacto standard is Java reference implementation in http://shibboleth.net/downloads/java-opensaml/archive/ whose latest release as of this writing was 2008–03–03, 2 years prior to the publication of the XML 1.0 exploit (uh oh).

This is really just a variant of the software update problem. However, when the published reference implementation 4 years after an exploit is published still defaults to bad behavior, we have problems. Luckily, I think most people default to TLS for SAML anyways (at least I hope) so the transport layer encryption (which is the only one that really matters) saves you. However…grr.