Technology Agnostic
You know, it could be an awful lot easier if Box UK was a closed shop: competing for, winning and developing on a single platform in a single language. But we’re technology agnostic. And we are incredibly proud of that fact. Here’s why…
Smart and adaptable
Maybe there is something in the phrase ‘jack of all trades, master of none’, but does it apply to web software? Developers may think they are the master of just one web software development technology; however, if you look closely you’ll see that usually there’s more than one tech involved, even if they don’t self-identify as gurus in different languages. In addition to this, the best developers are always broadening their horizons and adding to their arsenal by exploring new tools and techniques on a regular basis.
You may indeed find companies who tend towards a single line of tech, but if I were running a business and wanted to prototype a new product line then I would be really disappointed if my lead engineer came back and offered me 6 months of work using something weighty like Java EE because that’s the only language they’re comfortable with. Being able to move away from what’s always been done before can help organisations find leaner ways to do things; ones that get a product to market quickly, keep development staff progressing and enable them to act as technical partners rather than just service providers. To achieve this all that’s needed is a smart, adaptable team and a culture of learning.
Company culture
I’m not simply talking about having separate tech-specific teams (e.g. Ruby on Rails, PHP, Java) within a single organisation. At Box UK we take flexibility as far as possible, with multi-disciplined teams that can (and do) get asked to work on projects involving languages that may be a couple of lines down the list of their favourites. While we are not likely to jump on a project that specifies using a language we have zero experience in, for example Ada (waits while the comments box gets filled with Box UK devs proclaiming their years of MoD service writing fly-by-wire fighter jet controls), we can take a thing that maybe one or two developers have worked with and get it spread throughout the company very quickly. This crucially means our efficiency is not hindered.
We can consistently achieve this because our developers share three important qualities:
- Pragmatism – a difficult word when talking about agnosticism; being pragmatic could mean opting for the familiar, as in ‘my workflow is already set up for [x]’. What we mean in this case is the ability to not apply that comfort in the familiar to the decisions you make, instead selecting technologies based on the individual conditions of the project.
- Craft – the best programming books are language agnostic; with the exception of the canonical K&R, the rest of my top five list (Code Complete, Clean Code, Pragmatic Programmer and the Wizard Book – if you are interested) are applicable to developers in all fields. These resources focus on teaching the craft of software development, and craft is the single most transferable skill you can obtain
- Passion – not zealousness for a language, but genuine passion for learning, improving and, most of all, developing
These three things (along with the countless other attributes our developers possess) mean we can be confident that anything we as an organisation can teach will be taken on across the board. This gives us both the confidence to challenge for work that appeals at an intellectual level and a vital competitive advantage in winning this exciting work.
The right tools for the job
I also believe an agnostic approach keeps developers fresh – certainly the calibre of developers we aim to hire – as they are always being encouraged to increase their knowledge and skills. I do understand why some individuals may feel that the best route to get to the top of their game is to specialise; but it doesn’t stop it being wrong. There are places where you should specialise, for example surgery or law (you would definitely want a medical negligence specialist representing you if your brain surgery was botched by a chiropodist); and then there are places where you should absorb as much of the entire ecosystem as possible, like plasterers (I really appreciate not having to hire a separate crew to do the walls after someone else has done the ceiling). For me, software development certainly falls into this latter category.
I was at this point going to present a hackneyed analogy with a toolbox; hammers and screwdrivers, that sort of thing. But web languages aren’t as different as screwdrivers and hammers and it would be an massive oversimplification. So I present this: you can drive a Pozidriv screw in with a Phillips screwdriver, but if you apply too much torque at the end, it will cam out, potentially ruining the screw head. Now that’s an analogy for failing because you’re using the only tool that you’ve got. Like using any screwdriver for a screw, web services can be built in whatever language you like, but only when it’s under stress will you really know if you picked the right tool. Having a greater number of screwdrivers / languages in your belt increases your ability to pick the one that’s ideal for your task.
Facilitating flexibility
Having a choice of technologies gives our architects and software designers incredible creative freedom. They can sit in speculative meetings without a strict agenda to steer potential clients towards our technologies – we can genuinely offer the best solution for the problem. It is incredibly liberating. It does, however, put us in a couple of difficult situations:
1. Recruitment can be a nightmare
Imagine how hard it is to find and win the best developers in the area. Expand your reach so you are competing for the very best in the country with all the relocation complications that brings. Now make sure the people you are hiring are capable of switching between 5 or 6 languages, 3 or 4 delivery mechanisms and a couple of development methodologies without crying. In fact, we want the people who cannot just cope with this changing environment but actually thrive on it. To make sure we’re hiring truly gifted and passionate developers we ask interview questions such as “Are there any languages/technologies that you find intimidating?” and “What features from other languages would you add to [interviewee’s favourite language]?”. Question one can justifiably be answered with many esoteric languages such as Whitespace and Malbolge, but I don’t expect to hear something separated from a preferred language merely by syntax. Not answering question two means you’re either talking to a zealot or someone with little experience. Both these negative points suggest a candidate who does not like to step outside of their comfort zone.
2. Infrastructure support is magnitudes more complicated
We support Windows and Linux, including RHEE, CentOS and Debian among others; PHP, Rails, Java, Python, .NET and more via a full range of web and application servers; numerous data stores; on and on it goes. Our brilliant DevOps and Infrastructure teams look at the likes of Etsy and Shopify with the greenest of green eyes. One product, one technology stack, one platform? No problem. We, however, demand continuous integration and deployment over all the things, making it super tough from an operations point of view. But at least they can never say they are bored.
Making it work
From a technical perspective, we have a Continuous Integration server with separate build slaves for each technology. With all the virtualisation kit at our disposal we’ve made sure the right things are specialised so we don’t have to try to battle mixed tech setups. However we continue to reinforce our principles through our wider working practices and company ethos:We talk, a lot. We expect our developers to pick up new skills continually and then share what they’ve learned with others. Our teams are small and fairly consistent in makeup, so day-to-day cross-skilling is instinctive. We then expect our developers to give tech talks to share their knowledge across teams. We attend conferences and similarly share what we’ve heard when we return, and our internal IRC server has general and project specific channels where developers teach and learn.Our hiring process is tough. We realise how important each hire we make is, so potential developers can expect to be grilled by heads of departments and directors. Sometimes our new starters say they were surprised we didn’t put them through any interview coding exercises, but our technique for finding developers has evolved to a point where we can decide if they’ve got ‘it’ without asking them to remember how to write efficient Fibonacci algorithms (plus we’ve already read everything they’ve committed to GitHub before it gets to that stage).We are not hierarchy-heavy. While we of course recognise experience and commitment, working across the variety of technologies that we do means it would be foolish to think that one developer could be the font of all knowledge. We currently have a number of principal developers (even if that is something of a contradiction) that cover *most* of the range of work we do, but we recognise that single points of decision-making tend not to be the most pragmatic.Our architects and software designers are briefed not to dictate technologies where possible. Of course a decision has to be made eventually but we always walk into a kick-off meeting with an open mind.
Partners to clients
Finally, one of the key reasons for Box UK’s growth is the way in which we partner with our clients. We want them to see us as an integrated part of their organisation, albeit an extremely flexible and agile part. For some of clients we may work on skunkworks projects, for others we may end up acting as their entire software department. The only way we can successfully do this for the range of wonderful clients we have is by being unbiased, authoritative, knowledgeable and truly technology agnostic.
At Box UK we have a strong team of bespoke software consultants with more than two decades of bespoke software development experience. If you’re interested in finding out more about how we can help you, contact us on +44 (0)20 7439 1900 or email info@boxuk.com.
