The old adage states that a good craftsman never blames his tools, but what if he knows there is a better tool out there for the problem he is trying to solve?

Consultants are constantly being thrown into different situations. Whether fixing up a legacy code base or starting a greenfield project, the challenges and outcomes faced can be quite different.

When joining a legacy project, the toolset is most often pre-defined and embedded into the product, not leaving much room for discussion.

With a greenfield project, however, there is generally more scope for innovation. Despite this, a client will sometimes still ask for a certain toolset to be used.

As a new project starts, what do you do if you find yourself thinking there is a better technology stack out there for the job at hand?

Empathise

There could be several reasons why a client wants to use a particular toolset.

• They may have a background in that technology, and feel they can discuss, manage the project, and assist the team more productively if it is used.

• They may have seen several successes in the past using their stated technology choice.

• Perhaps they had a great former career programming in it, and are now emotionally tied. It can be difficult to see why something might not be a great solution if you had so many personal successes with it.

• They may know experts already in that field and have a wealth of contacts or team members in mind to continue the project long after your tenure.

Evaluate

It is important to do your research before working with the client to formulate a solution.

• Don't make a judgement before giving their choice a shot. For example, if the client is adamant about using a particular language, get familiar with the syntax, testing frameworks, and limitations.

• Balance the human and technical needs of the project. Technical gains can be negated by a team's difficulty adapting or maintaining a project.

• Don't dismiss what the client wants. Dig deeper. Find out the factual reasons behind their choice. They may know more about the technology than you do, and it can be easy to dismiss an option if you don't know the finer details.

• As the client justifies their choice, it may become apparent that they have based their decision on past emotions or outdated information. Perhaps their budget only stretches so far, and hiring programmers with a certain skill is cheaper than others.

• If appropriate, ask the client if they would be willing to consider an alternative technology that you feel could meet or exceed the business requirements.

Educate

If the client agrees to consider alternatives, identify two or three technology options that you truly feel would fit the project.

• Analyse the business requirements; consider the technical and budgetary limitations in addition to customer priorities. Don't take your favourite language and tell them it's the only language that will solve their problem. Be pragmatic and gather evidence to back up your suggestions.

• There will be disadvantages to every choice. Show the pro's and con's so that the view is balanced and the audience will know the limitations of each option.

• Run diagnostics. If performance is a concern, then do some benchmarking in all of the proposed technologies. Present the results to the client. Let them see the tangible benefits related to the problems they are trying to solve.

• If the tools the client proposes are open source, take a look at their GitHub repositories. Compare the number of stars, issues, and contributors to get a feel for the community support. Compare this to your suggestions.

• Think of your own network. Are there others using the technologies the client has proposed? If so, seek them out and ask them about areas of concern.

• Use the client's technology of choice to create a small feature. Then create the same feature again using your choice. Compare the differences in the lines of code, the complexity of compilation, operational performance, and cost savings.

• Consider the tenure of the project. If you introduce an obscure language, it may be difficult for the customer to find a team to maintain it once you have moved on. Experts in that field may cost well above what they are able to budget for.

• Keep it real. If there is already a team in place who don't know the technologies you are proposing, the business impact could be huge, and it may not be possible for the client to take that hit.

People Matter

People are at the center of software development. If the toolset can't be changed, then respect that decision and help the client find the best solution.

For instance, if a particular language has to be used, identify the most popular tools in that ecosystem, and do the same small experiment with each one. Evaluate which of those tools was the easiest to set up, which had the clearest documentation, and the best error messages. This will help you select which one to use moving forward.

Trust needs to be built. If you have challenged the client's decision, they might think you are not on board. Remember, even if you are using a technology that you don't personally favour, you are still crafting code and helping the team. Don't let attitude or personal preferences get in the way.

Tools Matter

Being a great Software Crafter includes the ability to select the best toolset that can most easily and economically deliver the business requirements.

Take the client's constraints into account, and regardless of the outcome, show your enthusiasm and willingness to learn throughout.

Go ahead and challenge decisions, but offer alternatives, and stay professional. Communicate your concerns to your client. Listen to their response and strive to write excellent code within the constraints you have.