When working with Suzi Edwards-Alexander and trying to find out what is good (and bad) about factor10, I've realised there are a few unconventional things about us that I'm proud of, but I don't think of much since I'm home blind. They’re things we’ve had since we started 18 years ago, such as flexible work time, transparent and equal pay, work time for personal exposure, …
Another of these unconventional things occurred to me last Friday when I wrote to a maybe-future-customer that we are technology agnostic for our customer's sake and ethical reasons. :)
How could that be the case? I think it becomes clear when describing the opposite. Let’s assume you only work with one vendor and the client is currently using tools from another vendor. You would then have to talk your client into changing, even though it might be for no valuable reason. Related, and perhaps even worse, is to have the agenda of a vendor involved in discussions that should be about what’s best for the client.
This decision to aim to be tech agnostic wasn’t something we ever fought about, if even discussed. It was just natural. We pick tools that we think are the best for the job, without holding on to a decision forever. When there is something better, we pick that instead. Assuming that the best tool would always come from one single vendor… Well, that just doesn’t make sense. It’s also riskful from a lock-in perspective, having all your vendor dependencies with a single vendor.
Somewhat related is to standardise on protocols rather than on tools/products/vendors. Those of us that were around when REST became popular might have forgotten the competition. Several large application server vendors told the world that as long as you built all your software for that vendor’s application server, you would be fine. The REST people rather said to look at the web. It’s chaos, everything is built with different products. But it works. The single application server world didn’t.
Even if we find this mindset to be natural, there are drawbacks of course. Those that specialise on a single vendor will typically get some benefits from the vendor, for example discounts and leads. It’s not a big drawback, though, to not get that.
Since we don’t limit ourselves to a single vendor, we might not be as good with all the intricacies of a certain tool as some that are specialising and we can never simply claim to be ‘experts’. (That’s not a word that I like anyway, but let’s not go there now.) On the other hand, even if we learn “all” there is to learn about a tool, we are always careful not to overuse it. It’s better to keep a healthy distance for dependency reasons. And as always, there is a diminishing return. As long as you know enough, other things make the difference. You will typically also evolve your skill in programming language A, by working with language B. It’s not a zero-sum game, it’s rather 1+1=3.
Talking about other things that make the difference, Test-Driven Development (TDD), Domain-Driven Design (DDD) and Theory of Constraints (ToC) spring to mind as extremely important for creating the most value for clients. Coincidentally, they are also tech agnostic. (By the way, I wrote about TDD (or rather XP), DDD and ToC as related in something like a stack form a few years ago. But to benefit from those, you need to have “enough” skills in the programming language you are using.)
Also, as a consultant in software development it’s important to learn fast. That might be the single most important trait to have. Aiming to be tech agnostic is a wonderful way of getting to learn a lot!
Finally, it occurred to me that it’s quite easy to explain why we aim to be tech agnostic since it connects directly to our values which are to excel, challenge, care and lead. A tight partnership with a single vendor and only working with their products puts an unnatural constraint on aiming to challenge or just doesn’t fit with caring for the customer for example.
As usual, there are pros and cons, but I will continue to aim for tech agnostic. What’s your opinion and what are my blind spots?
This article was originally published on LinkedIn. Join the discussion and read more here.