Many times, students ask me why we use the languages that we use and why we don't take advantage of the latest scripting or language fad.
My answer - why should I? They seem to be stumped by my response.
Well, really, why should I? Why should my team be disrupted on a regular basis just to use the latest language fad? Why should I continually experience a productivity loss as team members shift between languages? Why should I take the risk of bugs being introduced into production systems because the developers are not experienced with the language/tools that they are using? Why should I risk customers being subjected to performance issues because the developers haven't figured out how to optimize the programs they're creating? Why should I make the on-boarding experience for new developers more difficult?
Look, there are a handful of languages that we've committed to within our organization. Four languages are used to generate all of our production level systems. A couple of additional scripting languages have been used to create internal tools that assist us in production setup, as well as assisting us in ripping through logs to find specific information when we are researching issues in our environment.
Programming languages are programming languages - if you're a good programmer, you can pickup any language. If you're a good developer, you understand that once you understand the various constructs of a language - learning a new language simply means translating the specific syntax of the language you want to learn to the languages you already understand. It's translating how to use an if statement, a loop, a case statement, etc.
Let's say it take you a month to become familiar with the new language - assume that your productivity drops by 50% and for 6 months after your initial learning period, you're running at only 75% productivity. That means that over a 7 month period - you're productivity has cost the organization 8 weeks of development time. Now multiply that across the entire team. Assume their are 10 members on the team - that's a total of 80 weeks of lost development effort. Assuming this same 10 member team and an average of 2 weeks vacation time for each team member - you have a total of 500 weeks that you can allocate to development efforts. The end result is that you've stripped the team of 16% of the overall capacity of the team for the year.
Now, the numbers discussed above don't even take into account the impacts down the line as we move through test, implementation and post-implementation support. How much more time will the Development Team need to create and execute unit tests? How much time will the Development Team need to perform integration and regression testing? How much time will the Development Team need to perform load testing? How much extra time will the Quality Assurance Team need to test the application? What additional issues will be experienced during the implementation of the code into production? Can you quantify the number of additional issues that will be identified post-implementation that will need to be fixed and how much additional time it will take to address those issues?
The impact on productivity across the organization is significant and material - that is real time that prevents projects from being initiated or completed. That's time that allows your competitors to either close the gap or get further ahead.
I don't mind taking on a new language when there is a need, or when there is a specific purpose. Over the last couple of years, we've actually brought in specific tools that have allowed us to move in to the mobile market. At this point, a select number of developers within the overall team have been exposed to these new tools. Over time additional developers will be brought in to the loop. Here, there is a specific need - our tools at the time did not lend themselves to creating cutting edge mobile apps.
Take a step back and look at the decisions being made within your organization. There's usually a reason that organizations aren't moving as quickly from one language to another as developers would like. To the developers that would like to get an organization to change - don't just go in and say that you need to be able to use a new language. Document what you feel the benefits are, and just as importantly recognize the impact to the organization and craft your discussion points to address the costs that the organization will incur.
Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making;
For more information on David L. Collison: LinkedIn Profile
Well, really, why should I? Why should my team be disrupted on a regular basis just to use the latest language fad? Why should I continually experience a productivity loss as team members shift between languages? Why should I take the risk of bugs being introduced into production systems because the developers are not experienced with the language/tools that they are using? Why should I risk customers being subjected to performance issues because the developers haven't figured out how to optimize the programs they're creating? Why should I make the on-boarding experience for new developers more difficult?
Look, there are a handful of languages that we've committed to within our organization. Four languages are used to generate all of our production level systems. A couple of additional scripting languages have been used to create internal tools that assist us in production setup, as well as assisting us in ripping through logs to find specific information when we are researching issues in our environment.
Programming languages are programming languages - if you're a good programmer, you can pickup any language. If you're a good developer, you understand that once you understand the various constructs of a language - learning a new language simply means translating the specific syntax of the language you want to learn to the languages you already understand. It's translating how to use an if statement, a loop, a case statement, etc.
Let's say it take you a month to become familiar with the new language - assume that your productivity drops by 50% and for 6 months after your initial learning period, you're running at only 75% productivity. That means that over a 7 month period - you're productivity has cost the organization 8 weeks of development time. Now multiply that across the entire team. Assume their are 10 members on the team - that's a total of 80 weeks of lost development effort. Assuming this same 10 member team and an average of 2 weeks vacation time for each team member - you have a total of 500 weeks that you can allocate to development efforts. The end result is that you've stripped the team of 16% of the overall capacity of the team for the year.
Now, the numbers discussed above don't even take into account the impacts down the line as we move through test, implementation and post-implementation support. How much more time will the Development Team need to create and execute unit tests? How much time will the Development Team need to perform integration and regression testing? How much time will the Development Team need to perform load testing? How much extra time will the Quality Assurance Team need to test the application? What additional issues will be experienced during the implementation of the code into production? Can you quantify the number of additional issues that will be identified post-implementation that will need to be fixed and how much additional time it will take to address those issues?
The impact on productivity across the organization is significant and material - that is real time that prevents projects from being initiated or completed. That's time that allows your competitors to either close the gap or get further ahead.
I don't mind taking on a new language when there is a need, or when there is a specific purpose. Over the last couple of years, we've actually brought in specific tools that have allowed us to move in to the mobile market. At this point, a select number of developers within the overall team have been exposed to these new tools. Over time additional developers will be brought in to the loop. Here, there is a specific need - our tools at the time did not lend themselves to creating cutting edge mobile apps.
Take a step back and look at the decisions being made within your organization. There's usually a reason that organizations aren't moving as quickly from one language to another as developers would like. To the developers that would like to get an organization to change - don't just go in and say that you need to be able to use a new language. Document what you feel the benefits are, and just as importantly recognize the impact to the organization and craft your discussion points to address the costs that the organization will incur.
Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making;
For more information on David L. Collison: LinkedIn Profile
