Do you respect your platform?

If you work with a development platform enough, you develop some weird, imagined relationship with the platform’s development team, even if you never meet them. In working with the fruits of their labor day-in and day-out, you develop some mental picture of them, their general competence, and their mental processes.

Let’s consider two hypothetical platforms –

• Platform A is a never-ending pain-in-the-ass. It never works how it should, it constantly drives you nuts, and it makes you want to throw your computer out the window at regular intervals. It’s a mess of dead-end code, trainwreck APIs, and inexplicable architecture decisions that leaves you shaking your head in frustration a dozen times a day.
• Platform B is a joy to use. It’s simple, it’s powerful, and there’s a background elegance to it that you identify with. Every development decision slots neatly into the others, and the parts work together intelligently. The platform becomes a force multiplier for you – your talents and capabilities are magnified by the elegance and intuitiveness of the platform, and you have success after success developing with it.

With either platform, you start to have visions in your head of the people who developed them. The developers of Platform A are a bunch of barely-literate monkeys that couldn’t code their way out of a paper bag, and the developers of Platform B are Gods in Aerons – kings of programming that graciously cast their benevolence down on you.

I’ve worked with both Type A and Type B platforms extensively (sometimes both in the same day). It’s made me understand how much of development is what I’ll call “feasibility speculation” and what effect those platforms and imagined developers have on it.

With development, and with content management especially, a lot of what you do is speculating whether or not a goal can be achieved. So many conversations with clients start with, “Can we…” or “Is this possible…” You need to draw together everything you know about their platform and figure it out.

In doing this, you often sit around and think, “Would the developers of Platform X have thought of this requirement? Would they have accounted for it?”

With Platform A, your default answer becomes “no.” You just assume that the people who built the platform would never have thought of that. Their product has kicked you in the teeth enough times, and that you’re not even willing to put in much research time to find out. If you do decide to research the problem, much more likely to give up early, because you just don’t trust it anymore.

With Platform B, you’re default answer becomes “yes” or something along the lines of “I’m pretty sure we can do that…” because you just know it will work. You have this vision in your head of the developers as being competent and benevolent, so you just know they would have thought of just this situation. Furthermore, you’re willing to put in some time to research the situation, because you have a great expectation of success. When you do research, you’re very persistent because you know the decision is likely right around the next corner.

It’s this imagined relationship between you and the platform developers that drives success or failure. Once a platform betrays you enough times that you stop trusting it, that’s tough to come back from. They might make an improvement or two to the system, but there will always be this background uneasiness that the next disaster is right around the corner, and you should keep your expectations as low as possible.

It comes down to respect in the end. Your opinion of a platform is, in large part, a reflection of the respect you have for the people that built it. Once they lose your respect, your ability to do anything with their software is vastly reduced because your heart’s not in it anymore, and you’re not willing to give them another chance or the benefit of the doubt. Your attitude sours, your expectations drop, and you stop believing that the platform can ever make you happy.

From there, it’s an almost impossible road back.