Sometimes we have technologies foisted upon us. Sometimes that’s bad. Sometimes it’s good. This post examines approaches we can all learn from when selecting technologies.
‘X’ is the preferred framework for ‘Client Y’. Their rationale is that they are already using X for ‘Project A’ so it makes sense to use it for ‘Project B’. Is that a valid argument or bogus would you say?
This type of question comes up quite a lot. Especially when we’re pitching for new work.
Are you using the right tool for the job?
Developers love constraints. We love rules. They make things easy to normalise, repeat, and save effort. We also love it when there’s a tool/framework/technology out there that ‘just works’.
However, we don’t love trying to drive a nail into a wall with only our bare hands when there’s a perfectly good hammer sitting on the desk next to us.
You have to stick to the rules
The main thing if you use a tool or framework is that you should try and to stick to the ‘rules’ of the framework. If not, you’re defeating the point of using it in the first place.
A tool should be used to help you. Not hinder you.
If we take the lead from the inherent features that a chosen tool provides, we can avoid having to try and fight against it when building. Having to implement something that goes against the flow of what a chosen technology does can cause frustration. It can negatively affect the end product, especially in terms of maintainability.
When there’s no choice
If a technology must be used for reasons of ‘internal politics’ and it isn’t really providing any benefits, a more commercial view is needed. One of our developers provided the following insight on what the decision then falls back to.
- “I don’t like working with X”
- “Here is a million pounds to work with X”
- “Thanks, I now work with X”
Generally, I think most developers are happy to ‘give it a go’ with any technology. But, my main point here is if we’re being told a specific technology must be used then it has to be main driver behind the project. If a project has to be technology led, then it should be technology led, not design led.
If a project has to be technology led, then it should be technology led, not design led.
If there’s one takeaway here then that’s it. But, it can be hard to get people to agree (or even understand) that the constraints a technology imposes can stop certain design or usability choices being made. We are rightly being told to put the user first. But, in this case, it may not be true.
Conclusions
Here are some questions to consider when choosing a technology:
- If you’re currently using it, how are you currently using the technology?
- What currently works well about it, or what are the perceived benefits to using it?
- Are there any parts of your current setup that could be reused to save time?
- Are there any parts of your current setup that must be reused that will require extra effort to integrate with a new technology?
It might be an unpopular – but mostly true – statement to say that no single (non-bespoke) technology can solve every problem. There will always be a little shoe-horning of certain things to get them to work.
Understanding project objectives is key to solving any set of problems. The better understanding we have of the reasons behind a decision, the better job we can hope to do in suggesting a technology to meet that need.
