This chapter is from the book
This chapter is from the book
This chapter is from the book
3. Skilled Team
Problem
How can you make sure that the framework is designed in a clear and consistent way?
Context
You are going to develop a framework in your project. You now have to assemble a team that can perform the requirements analysis for the framework, define its architecture, and ultimately design and implement it.
Forces
Framework development is hard. But when framework and application development are strongly interwoven, things are even harder.
First, you have only a little time to develop your framework, because the other teams of the project are already counting on it. If your team is either inexperienced with framework development or with the application domain, there is no chance for success. The team would need too much time for familiarization.
Second, the framework team will have to take care of not only framework development and maintenance, but coaching as well. A crucial part of the framework team’s job is to explain to the users how to work with the framework properly, which represents quite some time and effort.
Third, several applications are going to use the framework, so it is likely that many different parties would like to put their stake in it. You have to expect many different requirements and requests to influence the framework’s design and scope.
And while such influences can give the framework designers valuable input, there is also the danger that the framework evolves into more and more variations. If different parties are free to request functionality as they see fit, the framework is likely not only to become complex, but to also split into inconsistent variations.
Solution
One team of skilled individuals must take care of framework design and development.
A skilled team is important in every development project, but it is crucial to framework development and even more crucial if framework and application development happen simultaneously.
Check the following, carefully and in detail, when assembling the framework team:
- The team members must have the necessary skills to design a framework. Experience with framework design and managing abstraction are required.
- The team members must adopt a strategy to keep the framework reasonably simple and to avoid unnecessary complexity.
- The team must have the experience and the skill to ensure that the framework’s scope stays on target.
- The team must have the communication skills that are necessary to collaborate closely with the framework users and to incorporate feedback the users may have into the design.
- At least some team members must be familiar with the application domain.
In order to collaborate smoothly, the team should be large enough to accomplish the task, but no larger. Interestingly, a small team is sometimes more effective than a large team.
Examples
The Data Access Layer Framework
Five people were involved in building the data access layer framework, although some only with a small percentage of their time. A stable core team of two people worked on the framework full-time for more than a year. When it came to introducing the framework into the applications, these two people were faced with the problem of doing three things at a time: maintaining the just-released version, preparing a new version, and coaching. Though they eventually managed this, there were some delays.
In retrospect, it became clear that a team of three or four people would have been necessary for timely releases and appropriate user support. A still larger team, however, wouldn’t have done any good; the fact that only a handful of people designed the framework added much to its consistency.
The Web Portal Framework
The good news here was that framework designers brought the necessary skills; they had developed frameworks before on other projects. The team size was also appropriate; about five people worked on the Web portal framework, which allowed for efficient teamwork.
However, a number of ad hoc corrections were made to the framework by people outside the framework team. This led to some irritation, since at some point responsibility for the framework wasn’t clearly defined. After a major refactoring, the framework’s consistency was reestablished, and responsibility for the framework was reassigned to the framework team.
Discussion
If too many people work on the framework, it’s hard to develop one consistent architectural vision, which is what your framework needs. A small team can envision The Beauty of Simplicity (2).
Likewise, a small team can take responsibility for how the framework evolves by making sure only Multiple Change Requests (8) are accepted.
In his generative development-process pattern language, Jim Coplien explains that it is important to Size the Organization [Coplien1995] and to Size the Schedule [Coplien1995] when building a software development organization in general. The importance of having the right number of people, as well as the right people from the start, is even more true for building frameworks since the additional level of abstraction makes adding people to the project even more difficult.