Applying Design Pattern Ideas in the Transition of a Development
Organization
ABSTRACT
This organization overview describes a project to re-engineer a
company's information systems from mainframe, COBOL systems
to systems written in Smalltalk. We describe how design pattern
ideas were used to facilitate the team's adoption of OO ideas, and
their development of the applications. We list some observations
on this approach.
Context
A large, offshore company was under strong competitive and
customer pressure to make its information systems more flexible
and responsive to changing business needs. The current systems
were mainframe-based, written in COBOL. The IS organization
had a fairly rigid, hierarchical organization, low morale, very
high turnover (greater than 100% per year), a poor record on
delivery of new applications, and little respect from the business
divisions of the company.
Focus
The company decided to launch a project to re-build its entire IS
systems. The project was to be based in the US, using some of the
existing developers augmented by new, experienced personnel.
The project leader decide to implement the new systems in
Smalltalk.
In addition to learning the syntactic and semantic aspects of the
language, the team faced the problem of developing practices and
models to form a culture of use of the language.
Approach
The project team started at X people, and grew to 40 people. The
development team was trained in the language. At this point team
members were able to write small programs, but were not able to
address large applications. This, together with the team's
background in the IS organization, resulted in a lack of
confidence in their ability to achieve the re-implementation which
was the goal of the project.
The project manager initiated a series of workshops to maintain
and continue the team's training. An early (three day) workshop
in this series tackled the entire development of an application,
from beginning to end. This workshop proved to be a turning
point for the team. Their previous context of a hierarchical
organization meant that they had no clear picture of the complete
development process, and they were not responsible for the results
of the entire process. The workshop showed them all of the steps,
and showed them a development process which made them
responsible for their work. The team's confidence level increased
dramatically.
The increase in confidence did not resolve one of the major issues
facing the team, that of tackling the design of the systems they
were to implement.
Design Patterns
There has been a recent spate of interest in architectural patterns
for software systems. In the context of object-oriented design of
systems, these architectural models are expressed as object classes
and relationships that address common design problems. A recent
book by Gamma et al [1] presents more than twenty such patterns
for common design problems.
The project leader decided to use design patterns as a way of
extending the team's training beyond the Smalltalk language into
the design of the applications. A catalog of patterns was prepared
(and refined during the project). The patterns were taught to the
team who began to use them.
Several effects were observed. The first is that the design pattern
catalog became a daily tool used by developers. A cheat sheet of
the catalog appeared on the walls of the developers cubicles and
was referenced regularly.
Secondly, the patterns created a common vocabulary in the
development team. Developers described their applications in
terms of the design patterns they had used to construct them.
Listeners were able to understand the application structure very
quickly since they were familiar with the design patterns from
which it was constructed. There was much less time wasted in the
fruitless discussion to understand trivially different custom design
solutions.
Thirdly, most developers embraced the use of design patterns with
enthusiasm. The project leader adopted a policy of requiring the
use of existing design patterns when suitable, and this policy was
enforced as part of the review process. There was little resistance
to this policy of using existing, approved design patterns. Some
people did resist, wanting to develop their own design structures
for problems for which there was already a design pattern. These
people either adapted to conforming to the policy, or left the team.
Mentoring
The project was assisted in the process described above by a
consultant experienced in both Smalltalk and the use of design
patterns. The consultant mentored the team in its learning of the
language, and the application of design patterns. The availability
of the mentor was a critical success factor for the project.
The initial team of Smalltalk neophytes was supplemented by
more experienced Smalltalk developers. These also accelerated the
learning process for the team.
Current State
The project was planned for three years, with incremental
deliveries during that time. The project is still in progress.
Lessons
Design patterns provide a bridge that allows developers to go
beyond knowledge of a language to the construction of significant
applications.
References
- [1]
- Design Patterns: Elements of Reusable Object-Oriented Software,
Addison-Wesley, 1995. Gamma, E., Helm, R., Johnson R., Vlissides J.