4 questions to ask before developing on new technology

Ashley Streb
Chief Client Officer, DEPT® Americas

Length

4 min read

Date

21 October 2021

There will be blood…

Whenever we start a new greenfield project here at DEPT®, with few or no constraints on what technology we use to build, we are inevitably faced with the question: “Should we use the beta version of xxx technology?”. This question is usually followed by someone suggesting, “It should be out of beta before we launch.”. Or we might even hear a more drastic format of this question: “Should we use xxx language, after all it’s where the industry is going?”.

This is what we call the ‘bleeding edge’, where a wrong move can lead to getting cut badly and a lot of bleeding. If you choose a nascent technology that doesn’t end up working out, it will cost a lot of money/time in the short-term and lead to a dead product or an expensive rebuild in the long-term. If you use an existing technology that isn’t suitable for your new project’s needs, then that will also lead to a lot of blood down the line.

Either way, there is always some blood…but how do you reduce your risk of using a less-than-fully-mature technology while also taking advantage of its benefits?

Here are a few questions we always ask when considering the use of new technology:

What improvements / advantages does xxx offer us?

This must be significant. If the advocate of xxx does not have a clear and articulate answer to this question, then either they have not done enough research or this technology will ultimately fail. Simply saying, “It’s the future” is not good enough…cough…docker…cough. (FWIW, we do believe docker is the future, but have yet to articulate exactly why…which keeps us suspicious)

Is this going to be the de-facto standard in the future?

There are times when it is a clear that a technology / standard is going to be the future. Fighting this is always a bad idea. A recent example of this was the release of Swift. It was clear that the Apple was putting their weight behind Swift so we immediately adopted the language, despite some of the pains of such a nascent ecosystem. In our opinion avoiding a migration / rewrite 12 months from now, along with the experience and knowledge we were gaining, outweighed the pains of the increased compilation time and minimal documentation.

Will this help with recruiting?

In the current macro climate of the tech industry, hiring good talent is really hard. We always keep this in mind for virtually all decisions we make. Whether to use bleeding software is no exception. However, knowing how the adoption of a technology will effect recruiting is often a bit ambiguous. As developers, we are always attracted to that new shiny toy, and in our experience the best engineers are the ones that are not afraid to jump into a new language. On the other hand, you also want to be wary of the ‘hipster’ developer that just jumps from on shiny language / framework to the next. (jQuery -> backbone -> knockout -> angular / ember -> react) The answer usually comes down to the actual developer, but we usually find that being able to advertise that we are using XXX is a great way to get other developers interested.

Can we help shape the community?

We find that contributing to a budding community spawns a great symbiotic relationship. We help to grow the community, and as an agency it helps cement us in the mind of companies. For example, back in 2011 we began using node.js for build tools and smaller services. At the time very few companies were using it. We established the node meetup in Boston, primarily so that we could compare experiences with other companies taking the plunge. Since then, this has been a great way to meet other developers as well as give back to the community via things like Boston node school.

In conclusion, we know that there will always be some blood when we develop on the cutting edge. But as long as we answer the above the questions honestly we believe we can make the correct decision for clients and ourselves.