This has been one of the most time-consuming and significant decisions in almost all software projects. It affects many things, with the maintenance getting affected the most. Sometimes hiring new people also revolves around the skills required for the third party tools (code blocks, libraries, frameworks, applications) used. And as with other things, there is no solution that works for all. It depends!
The difficulty has increased because of two reasons:
- The number of choices makes it a requirement to stay continuously updated about them
- It depends deeply on skills of the team, or at least of the lead designers and programmers.
The first one is quite clear. Open source has fueled an era with many options. The downside is that it takes time to take informed decisions. If you do not run a parallel thread that constantly evaluates them it becomes impractical to do it in a project’s time-space.
The second one is which, I feel, is commonly ignored. I have seen two types of good and productive programmers. There are ones who can adapt to a third party tool and there are the ones who believe that they can write better code than others out there. Each approach has its pros and cons, but not considering the team’s ability is calling for a failure.
I have seen that making a team skilled at writing their own code, to adopt other tools, can be unproductive. Without any negative connotations, it is not only their skill and ability, but their belief that they can build much better code than others, especially specific to the needs of the project. Similarly some are apt at understanding other tools, quickly adapt them to the project needs and develop a solution. Asking them to write their own code can end up in a disaster.
It is really at hands of the one or two project members, who can judge skill of the team.
For a team which is going to use third party tools, there should be at least one member who is abreast with the various options available and is conversant with pros, but more importantly with cons, of each of them. Applying them to the project needs should help in deciding which one to go with.
The team that wants to write its own code needs to have a member who can translate the needs into a good specification for rest of the team. It is also important that he/she knows the standards that will need to be applied. After all you are doing something that perhaps others have been at for longer time.
Next time you end up in a position of making this choice, look at your team before you make the decision. They can help you eliminate a lot of options and make it easier to decide.

September 24th, 2007 at 10:10 am
[...] tool is suitable for your problem depends on you and your team. I have seen a lot of arguments about explicitness versus magic in frameworks. I have realized that [...]