There is an interesting post on Javalobby this week about a growing trend in Java developers – the developer who is experienced in working with various frameworks, both open source and industry standard as well as proprietary to individual companies, but does not have a deeper understanding of what the framework is actually doing for them, or how they would achieve the same result if they had to code it by hand without using the framework.
The poster of this article is concerned that this is a dangerous trend, as we are developing a generation of developers who know nothing else but how to code using these frameworks. Although this is a valid concern, for some situations you need these developers working on your project.
On any project using freely available, standardized frameworks or own in-house frameworks you need two distinct groups of developers – those who initially select the frameworks to be used by the project or develop proprietary in-house frameworks to meet specialized needs, and the second group is the group that will be developing functionality using these frameworks. The reason why you need this distinction is simple – the developers who select or develop the frameworks need to have a wide understanding of the issues at hand. They need to appreciate the issues and be aware of what frameworks already exist that address these issues and simplify the development of the application’s functionality. If there are multiple possible existing frameworks available, they need to be able to analyze the pros and cons of the alternatives and select the most appropriate to address the current project’s needs. If there isn’t a suitable framework available, this type of developer should be skilled enough that they can develop a framework for this particular project that addresses the issues, and simplifies development of the project’s functionality.
Once the time the architecture frameworks are developed or selected, assuming that the design phase is complete and you are ready to start development, you will be handing over development of the functionality to the second group of developers who will be using the frameworks (the ‘Framework Java Coder’). Remember – at this stage you have functionality that needs to be produced. You need to get to the end goal with mimimal defects and an acceptable high level of quality. How do you ensure this process is as easy as possible? You select or develop frameworks that make the development of the business functionality as easy as possible. You want developers who can follow project standards and established patterns. You want developers who can follow guidelines. You want developers who are smart and can get things done, but at this stage in the project, I would suggest more emphasis on the ‘get things done’. This group of developers does not comprise of many developers who were from the initial first group of developers of the frameworks. The developer of the frameworks is likely to get bored working in this environment, producing ‘cookie cutter’ code – they want to tackle more complicated issues and get dirty writing lower level code. You may however want one or two of the framework developers involved in the functionality development, because you need to keep reviewing the suitability of the frameworks and identifiying areas for improvement, and to ensure that the frameworks are still addressing the issues and enabling rapid development of high quality code that meets the requirements with minimal effort. The problem if you have too many of the initial group of developers involved in the actual functionality development is that once they become bored with the cookier cutter approach, they’ll start to wander, questioning the approach, spending too much time writing other ‘clever’ code that although may be still benefical to the project, does not help with achieving the end goal of completing the implementation of the functionality.
This is a difficult balance to get right, but there is definitely a place and a need for these two types of developers, and both have a valid and valuable role in any complex project. I don’t see this as a concern, but it is essential to the success of a project that you indentify these two distinct types and staff them in appropriate roles. These types are not set in stone either – expect that over time some of your second group will develop their skills and will want to become involved with acticities by the first group – this is a natural progression for some of your developers, and something you will need to plan for.