|
Development language choices and their place in the project scoping cycle |
The Register recently posted an interesting article on the most 'popular' development languages in use today, and a brief dissection of why they have been nominated by the community.
Selecting the right code base to develop your applications in has always been a tricky decision. There are many criteria involved in selecting the right technology, and picking the wrong one can have far reaching consequences for the project, and indeed the application life in general. The article above points out many of the good, and bad points of a range of different languages, but I thought I would explore some of them in more depth.
I've grazed over several major topics here but will be fleshing out some of these points into full discussions, hopefully over the coming weeks.
One of the points that they touch on is resource availability. This is increasing becoming an issue in many development circles. With an increase in the number of available development languages, what with older languages remaining in production environments for longer, and many new languages entering the market this is only set to become even more prominent. How many languages must a developer know to become a useful project asset? How flexible is a development team? Is there really such a thing as a .Net developer, or a php developer anymore? In the last few years development staff have had to broaden their horizons substantially, just to stay in a team.
Other 'new' factors have risen to prominence, such as the Kudos factor. Is it cool to develop in a newly to market language? What are the problems associated with being an early adopter? Lack of resource springs to mind, and the development of new languages themselves can be very rocky indeed. I personally have been involved with, or used late beta or early version 1.X languages and frameworks, just to have them take a radically different approach on the next iteration, simply due to their immaturity. Also with the growth of some popular sites (google/facespace etc) they have also popularised the development languages they use. Just bear in mind that a project does not live or die by the code base being used.
Of course there is always the ever present split over open source or establishment development environments. This may often be dictated for a project due to wider issues. If your server architecture is unix, then you are unlikely to try and develop that new application in .Net. Both bring their own plus's and minus's I will go into more depth with those here.
One point that isn't mentioned the differing costs associated with many of these languages. Using open source software may dramatically reduce the costs of production, but could lead to higher staff costs, as experienced technical resources can demand a premium. Similarly using enterprise level vendor products such as .Net may well expand your resource pool due to its relative easy of use, but the costs of both server and client development software soon climbs.
One of the most overlooked aspects of deciding the technology base for your next application is the interconnectivity with our in-house, or third party systems. Are you exposing any elements as external services? Having worked with both confused.com, and gocompare.com I've had first-hand experience of the non-standardisation of WebServices. Both companies use differing technologies (VB and .Net) and interface with a WSDL service in totally different ways. For an open standard remote services are a mixed bag when dealing with different platforms. The last thing you want is to be writing translation applications for your actual application.
There are no comments for this entry.
[Add Comment] [Subscribe to Comments]