There are many good reasons why using a new library, framework, or programming language (later referred as a tool) is not worth it. However, for some reason the most common reason I hear is:
We don’t have time to learn how to use it.
It is easy to think that this argument is used by old fashioned idiots who just doesn’t want to get out of their comfort zones. This is not always the case.
Most of us work with intelligent people. We are a team which has a deadline to meet, and it is easier to meet that deadline when we use tools that are familiar to us. Mastering new tools takes time, and we don’t always have it.
Thus, if we want to convince our team members to use a new tool, we have to reduce (or eliminate) uncertainty.
Reducing (or Eliminating) Uncertainty
Let's assume that we have found a new tool (X) and we think that our project might benefit from it.
If we don't want that our proposal is rejected without giving it a second thought, we should do a short prestudy that either reduces or eliminates uncertainty.
We can do this by following these three steps:
1. Get Information About the Tool X
We need to understand what problem the tool X solves and identify its pros and cons. We can get this information by using some (or all) of these methods:
- If we have used the tool X in the past, we can answer to these questions ourselves. However, we must understand that this is our subjective opinion and not necessarily the whole truth.
- We can ask help from our colleagues / network. We should leverage the experience of the people we trust because they might know something we don't. Also, it so easy to ask for a second opinion that it is almost a crime to not do it.
- We can search information from Google. Google makes it easy (and fast) to find a lot information on just about everything. On the other hand, we must remember that not everything we read on the internet is true.
2. Verify That Our Information Is Correct
First, we have to decide whether or not we can trust in our data sources. We can do this by answering to these three questions:
- Do we know the people who shared their experiences with us, and do we trust them? It is obvious that if we got this information from people we trust, it has a lot more weight than information that is gathered from people who we have met once or twice.
- Did we gather this information from random blogs? Again, if the information is gathered from blogs whose authors are unknown to us, the information doesn't have as much weight as information that is found from the blogs of well known industry experts.
- Is the tool X generally recognized as a good solution to our problem or are there a lot of different opinions? If our data sources agree that the tool X is a good solution to our problem, and there are a few different opinions, it's relatively safe to think that the tool X could be the best tool for the job. Also, if we haven't found any negative remarks about the tool X, we should dig deeper. It is very likely that our research hasn't been objective.
Second, we should do a small prototype and see if our experiences support the gathered information. This is a good way to get hands-on experience from the tool X, and it is especially useful in situations where we aren't sure that our information is correct.
3. Decide If the Tool X Is the Best Tool for the Job
If we want to make an objective decision, we have to answer to these questions:
- Does it solve our problem? This is a pretty obvious question but sometimes people fall in love with the tool X because it is new and exciting, and it is not boring like their old hammer. This can cloud their judgement. We must be careful that this doesn't happen to us.
- Does it have a healthy community or is it maintained by only one person? I want to make this absolutely clear: the tool X can be great even if it is maintained by only one person. However, if it is maintained by only one person, we must have a backup plan in case he/she gets bored or something happens to him/her. Are we ready to maintain it ourselves? Are we willing to pay someone to do it? If the answer to both questions is no, we might have a problem.
- What are its strengths? The strengths of a tool help us to figure out the use cases we can solve with it. After we have done this, we can evaluate whether or not the tool is a good choice for us by comparing these use cases with our use cases. It is quite rare that a single tool can fulfill all of our requirements, but if the tool cannot fulfill our most important requirements, we have a problem.
- What are its weaknesses? The weaknesses of a tool helps us to determine the use cases that are hard or impossible to solve with it. When we compare this list with our use cases, we can see if it is a good solution for us. Also, if we decide to use it anyway, we can see what kind of problems we can expect.
- Are there other tools that solve the same problem than the tool X? Sure there are. If we don't bother to find them, how can we be sure that the tool X is the best one? If we want to do an objective evaluation, we have to compare the tool X with its competitors.
- Are these other tools worse or better than the tool X? Why? Obviously we aren't finding the other tools just for fun. We must to compare them with the tool X and describe why they are worse or better than it.
After we have gathered all this information, we must decide whether or not we should try to convince our team members to use the tool X.
To Propose or Not to Propose?
Technology selection is like a marriage. After we have made it, it can be very expensive to get rid of it. Luckily, if we made the right choice, we don’t want to get rid of it.
That is why we shouldn’t take this responsibility lightly. We must remember that introducing a new tool is always a risk, and we shouldn’t do it unless its benefits outweigh its drawbacks.
So, what has this got to do with technology evaluation? Well, evaluating new tools takes time and often time is our most valuable resource. That is why we shouldn’t waste time by forcing our team members to evaluate “too many” tools just because they were mentioned on the front page of Hacker News.
Once again, we can speed up this process by proposing the tool X only if the answer to all of these questions is yes:
- Is it the best tool for the job?
- Are its pros and cons are well known?
- Does it have a strong community (not necessarily a big one)?
- Is it easy to learn?
- Are the risks acceptable?
- If we don't use it, do we have to implement an in-house framework or library?
Not every story has a happy ending. We might have a strong case (in our opinion), but our proposal is rejected nevertheless. It is tough, but we can always learn from it.
Dealing With Rejection
When our proposal is rejected, we can deal with the situation by
- Getting angry
- Analyzing the situation
Although getting angry is a quite natural reaction, especially if we think that our proposal was rejected without a proper reason, it isn’t a very mature way of dealing with this situation. The problem is that often it causes unnecessary friction between us and our team members, and this can destroy the morale of the entire team.
That is why we should put feelings aside (for a while) and analyze why our proposal was rejected. We can do this by following these steps:
1. Find Out Why Our Proposal Was Rejected
It is important that we understand why our proposal was rejected because no doesn’t necessarily mean that we will never use the tool X. For example, if we think about the following answers, we notice that they all have a bit different meaning:
- We want to continue using the tool Y because training developers would take too long and would be too expensive.
- The other developers don’t want to use it.
- The risks are too big for this project, but we will try it in a smaller project. If our experiences are positive, we will start using it in our other upcoming projects.
In other words, we shouldn't take no for an answer. We have the right to ask the exact reason why our proposal was rejected. If none is given, we should assume that either the other developers don't want to use the tool X or that the person who has the final say didn't like it.
2. Figure Out If We Did a Good Job When We Made Our Case
It is possible that our proposal was rejected because it wasn’t clear enough. If we want to learn from rejection and do a better job next time, we should answer to the following questions:
- Did we explain the benefits of replacing our current tool with the tool X?
- Did we identify the downsides of the tool X?
- Could we improve our proposal? If so, how?
If this is the first time we have to criticize our work, answering to these questions can be tough and frustrating. However, if we want to learn how to make good proposals, we must do it because champions are made, not born.
3. Decide What to Do
We have four options:
- We can accept the situation and move on. If we choose to do this, we are not allowed to whine about our rejected proposal. It never happened.
- We can appeal. If we think that our proposal was rejected because it wasn't clear enough, we can fix our proposal and appeal. However, we shouldn't make this decision lightly because quite frankly, the odds are that our proposal will be rejected. Also, if there was nothing wrong with our proposal, appealing is a waste of time.
- We can use the tool X in our own projects. If we made the proposal because we wanted to learn how to use the tool X, we can use it in our own projects. However, this option requires that we are willing to invest our own time into this. This is not always possible.
- We can start looking for new challenges. This is a drastic action and choosing this path shouldn't be our first choice. Nevertheless, if we have become unmotivated because our current team has rejected too many of our proposals, maybe it is time to move on. It is definitely a better choice than doing work that demotivates us.