5 Steps to Choose a New Software Technology

A green field project unfolds in front of you. Fresh software technologies, ripe for the picking, await discovery. You’re excited, engaged, and ready to embark on a new journey.

Then you pause.

Photo by Brett Jordan on Unsplash

How do you choose technologies to review? How do you start to learn them? How do you become sufficiently expert to make a choice?

Step 1 — Research Your Options

With so many technologies available, you need to narrow the beam down to a short list. Don’t make the mistake of just picking the latest and greatest. Technologies come and go and what is trending today, maybe tomorrow’s also ran.

How do you choose in such a crowded marketplace? A few key questions I ask are:

1. Is it open source with a permissive license? Modern open source stacks are excellent and there is little reason to risk vendor lock-in.
2. Is it established, mature and under active development? If I’m looking at an application which can be maintained beyond the length of the project, this is very important. If it may be me or my team returning to it in the future, even more so.
3. Does it do everything you need? There is little point in using a new technology which won’t help you to deliver your application. Moreover, if the technology does far more than you need, the learning curve and ongoing maintenance may be undesirable. Bare in mind, a hotchpotch of differing technologies strapped together, may also lead to trouble; think ahead, consider the medium to long term requirements, rather than just what you need now.
4. Is there good documentation? If the developers of the technology are unable to easily explain how it works, what hope do you have as an outsider? Good, foundational, documentation, and simple tutorials are worth their weight in gold.
5. Is there an active community? As any developer knows, search engines are your friend. Stack Overflow is littered with fallen comrades seeking help, with others lifting them back to their feet. It is easier to learn from those who fell before you, than being the person who falls.
6. Is there a pool of experienced developers available? If the application becomes a success, the team will need to grow to maintain it and support new features. If you pick an esoteric solution, this could lead to an unmanageable application in the future. Some applications may even need to be rewritten to keep them moving forward.
7. Is the technology opinionated or highly customizable? I’ll be controversial and say I only have time for opinionated technologies, unless there is a very good reason to go with flexibility. I’m experienced (old?) enough to have seen many applications become a mess of yesterday’s technologies and it just isn’t worth it. Unless there are killer features that are needed, trust those who came before you — their opinions were likely based on experience.
8. Does the technology fit around the core application technologies? Depending on just how ‘green field’ the application is, this may apply to a lesser or greater degree. For example, you may decide that Java and TypeScript are a necessity, which will rule out many other options.
9. What do your fellow developers think? You may know others in your network who are specialists in the field. They may have very strong opinions on what is good, bad or ugly. It is often flattering to be asked for your opinion — it is nice to know it is valued — and you may learn something key.

This checklist should narrow the options down to a small handful, your shortlist. Maybe even one, if you are lucky.

Step 2 — Complete a Tutorial Application

Nothing gives you a better taste for a new technology than following a basic tutorial. You gain insight into how easy it is to get something basic off the ground.

I’d recommend configuring your favourite IDE (or your new IDE!) to see how well your tooling fits. There may be native support, which will help you to complete the tutorial. This could be anything from a language template (colour coding, indenting, etc.) to helpers to create modules, add boiler plate and so forth.

Once you have completed the tutorial, you should have an idea of how well things fit together. Did it feel familiar? Did it feel overly complex? Did it feel too rigid or too relaxed? Write some notes about the technology, capturing the salient points.

Step 3 — Customise the Tutorial Application

A good way to test your understanding and the capabilities of the technology, is to make it do something more complicated. Using the foundation built in the tutorial, you can quickly tack on new functionality.

Green field development has many routes

The new functionality can be anything you like. Make sure it is complex enough to push past the perimeters of the tutorial. It needs to be meaty enough that a solution is not obvious, but I wouldn’t spend more than a few days on it. Your creation doesn’t need to be super refined either, as you are just proving the concept.

This is where the technology’s documentation and community will face its first test. You will be straying off the beaten tutorial track.

I usually start by reading the first few chapters of the documentation. This will give me an understanding into the background of the technology and an overview on how it is glued together. From this, I can start referencing key points, either through other specific chapters or search engines.

Depending on how much experience you have, this process may be long or short. You may quickly see parallels with technologies you are already familiar with. The architecture may be similar and well trodden design patterns may be present. This will give you immediate comfort, allowing you to make useful assumptions about how it ticks.

If everything feels alien, all is not lost — it may just be something new to crack. If you are relatively experienced and it still feels awkward, perhaps it is time to consider another technology on your shortlist? You can always come back again.

Was it easy to add your custom functionality? Did you get stuck often? Was it easy to get unstuck after reading the documentation? Did you fall back on the community? Was it evident that people had solved similar issues or was it tough to find answers? Take notes on these points too.

Step 4 — Deploy the Application

While an application may be a walk in the park to write, some can be a pain to deploy. What better way to find out than by doing a test deployment?

I start by looking at how easy it is to package and containerise. If there is a back end component, is it easy to put it in a Docker container? This will immediately open up a world of cloud options. Once containerised, I know that I can slot it into a CI/CD pipeline easily too.

If the deployment process is arduous, can’t be scripted nor containerised, I will likely move onto a different technology. I prefer to spend more time writing applications, rather than installing and deploying them.

Photo by Oliver Roos on Unsplash

Step 5 — Review Your Technology Shortlist

By this point, you should have at least completed the tutorial and tried to extend it in some way. You should have lots of notes too. You have probably already picked a winner and are looking forward to getting stuck into application development.

What if it is too close to call? Take another look at the original list in step 1. Are there any differences here that could split the pack? Perhaps your network of contacts can help you decide?

Once you have reviewed the options, you could opt to convert your notes into a formal review document. Your company may have internal processes for evaluating new technologies. Perhaps your direct client wishes to understand your decision instead. Showing your working will give them confidence that you have been duly diligent.

Summary

You will need to recommend, choose or use new technologies frequently in your software development career. I recently found myself doing this again and thought my approach may be worth sharing. Thanks for reading!