Continuing On Pre-built Or Custom

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.

Discussion [Participate or Link]

  1. It Is Really About You, Not The Tool | iface thoughts said:

    […] 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 […]

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.