Received: 07/29 9:55 AM
Norm,
Please find my position paper and biography attached. I've attached them as a MS Word 7 document, and as text only below the dotted line. Could you please let me know that you have received my submission.
Regards, Steve Hayes
Khatovar Technology
One of the advantages of object-oriented languages is (particularly Smalltalk) is that they encourage concise expression of ideas. Individual methods are generally only a few lines long. Good reusable constructs usually have small interfaces. Structured languages often require long-winded code to achieve the same ends.
Removing vast volumes of code changes the work breakdown. When structured developments finish design there is still quite a lot of work to do implementing the design. This has created a hierarchy of roles, with distinct analysts, designers and programmers. Traditionally this provided training grounds and career progression.
By the time an object-oriented project finishes design there isn't much left to do. There certainly isn't any need for armies of programmers to turn the design vision into code. Many object-oriented projects adopt an iterative approach that makes design and implementation cycles short and frequent. All these factors make it hard to make analysis, design and implementation the responsibility of separate people.
At the same time competent design is a skill which only normally emerges after a person has experience with implementation. Our historical reliance on on-the-job training is no longer appropriate.
Maintenance of structured code often relied on adherence to standards. Most standards document rules without explaining the rationale behind the rules. They rely on simple, easily verifiable statements. This is appropriate in a production-line, high volume environment where most components were developed from scratch. Object-oriented projects are often trying to develop reusable components. These need to be well-crafted, highly cohesive. Method names need to be carefully chosen and accurately reflect the purpose and actions of the method. Standards are not an appropriate way to address these issues. Well-crafted, reusable components require skilled, well-trained developers. The emphasis needs to be on skill and professionalism rather than compliance to standards. We need to trust developers to do the right thing, but we need to provide the support structures to get them there. This is a major change for most organisations, and for most developers.
To achieve these outcomes we need to consider new models for skills transfer. We certainly need to have more resources focussed on improving skills. This will change traditional ratios between novice and experienced staff. We need to put more emphasis on adult learning. At the moment there are very few object-oriented technology practitioners who have this combination of skills.
Both organisations and individuals need to consider software as a reusable asset. They need to make the appropriate investments. This means that they need to appreciate that object-oriented components have qualities other than "it works". They also need to be more demanding of the components they consume - providing feedback on existing components is a crucial way to improve the quality of the code base. These attitudes often don't come easily to organisations and individuals that are accustomed to a throw-away, non-reusable culture.
Many organisations who introduce object-oriented technology do so without changing their approach to projects. Projects generally remain deadline driven. Developers recognise that their success depends almost exclusively on how often they meet deadlines. Organisations that judge individuals against this standard but still expect projects to deliver high-quality reusable components induce considerable stress amongst developers.
Organisations need to adjust their reward systems to encourage the outcomes that they expect to achieve from the transition to object-oriented development. They also need to understand that staff skilled in object-oriented development are a valuable asset. Organisations transitioning to object-oriented technology need to put some sort of staff-retention plans in place. This will create tension between staff working on different technologies.
Larger object-oriented projects also introduce strong interdependencies between development groups. Structured developments are often stand-alone. If there are dependencies they are normally "once-off". The dependent group expects a delivery of a component on a certain date. In iterative developments groups may be dependent on frequent deliveries from a number of different groups. We need to provide developers with the inter-personal skills to deal with conflicts between the groups. This means adjusting expectations (and behaviour) on both sides of the relationships.
The transition to object-oriented technology can also change the power structures within an organisation. The set of people who have proven highly-skilled at structured development almost certainly won't be the same as the set of people who quickly acquire object-oriented development skills. We need to provide a safety net for people who start to get left behind. This may be either extra mentoring or transfer to another technology area. This can be an issue for both managers and developers.
Organisations who consider all these issues and manage positive outcomes will be radically different from their pre-object-oriented selves. They will be very similar to the "learning organisation" which has been popularised by Peter Senge. Staff will be productive and satisfied. Very few organisations are making this transition right now.
I have 12 years experience in developing technical solutions for business problems. I have worked in petroleum retailing and point-of-sale systems but most of my work has been in the finance industry. This has included developing trading and risk-management systems for wholesale banks and sales support systems for retail banks. My involvement with object-oriented technology began in about 1990. I developed my first Smalltalk system in 1992 and have been involved in Smalltalk since then. Since 1994 I have been involved in the development and delivery of a framework for retail banking applications. Delivery of this framework has involved substantial work on customer sites for periods of six months to a year. For most customers this is either their first object-oriented development, or their first significant object-oriented development. My contributions have included technical support, quality assurance, mentoring and process advice.
Received: 08/06 8:09 AM
Norm,
Since I started work in the late 1980's sports analogies have been prevalent in business. In no work that I have done has the analogy been more fitting then in Object Technology. I have played on and coached many athletic teams. In working on Object technology projects I feel that I am truly part of a team. In managing object technology projects I feel that I am a coach more than a manager. As a result there are a lot of lessons about picking and coaching teams that I feel apply to object technology.
In many shops, especially large companies, systems development is a war of attrition. We take large teams of programmers and through brute force build large applications. Fortunately, this approach does not work in Object technology, because of the promises of smaller teams and quicker development coupled with the physical difficulties of supporting large OO programming teams.
As a result, we have been forced to find alternative/better ways of working. The method that I have seen used most often is that of small teams of developers. You can say a lot about the success of a project and the design of an application by examining the make up of the team that developed it.
I have worked on 4 large scale Smalltalk projects for different companies. At least 2 of these projects were startup projects where the best and brightest technologists were brought together to accomplish a large amount of work in a short amount of time. Just like when a competitive sports team is formed, these people are used to being the superstars on the teams they used to play for. There is often quite a bit of collision before this group of people can perform as a team.
For example, a project that I worked was a lot like watching an all-star game. When an all-star team plays they rely on talent and ability. They have not practiced much together, if at all, and it shows. In this project there was no doubt that we would succeed through sheer ability. Yet, we never came together and performed like a team. You could see that in meetings. You could also see that in the way that the application was put together. There were a lot of very elegant, yet very different, solutions to problems that were patched together and made to work.
Additionally, as object technology continues to grow at a company, the elite team of superstars is usually disbanded. This happens through normal attrition as well as the necessity to staff additional projects. This is one of the most critical junctures for being able to judge the abilities, both demonstrated and perceived, of the people involved in object projects. Who will be able to step up and lead the team? Who will continue to be the star technologists? What new people are bright enough to keep the team competitive yet humble enough to realize they are the "new guy" and accept the new role.
As sports teams come together over the course of a season they become like families. There are fights and there is fun. In object technology, more so than other technologies, I find that being part of a project team is like being part of a family. Just like with my brothers and sisters, I donít always agree with them, we sometimes fight, and there are times I really donít like them. In short, I have never been so emotionally involved in a job as I am now. I think this is partly because in order to accomplish what is often asked of us we need to come together.
There are really two behaviors that can be learned from by examining this analogy:
My name is John Heidelberger I have been designing and building object oriented applications for over 4 years. I have worked in the management of these projects for the past 3. I currently work for American Management Systems where I was forced to integrate myself as a leader on an existing project team. Previously, at Prudential Insurance, I started on a level playing field with other programmers and rose to lead two highly successful projects in Object technology.
I apologize for the haste with which this was composed. I received the conference program on Saturday August 3rd and today is the deadline for submissions, August 5th. If you have any questions or would like further clarification, please let me know. Thank you.
John Heidelberger
American Management Systems
john_heidelberger@mail.amsinc.com
(212)612-3665
1 Chase Manhattan Plaza
36th Floor
New York, NY 10005
Date: 10 Aug 96 19:49:47 -0500
I've decided this is my favorite workshop and have succumbed to your plea.
I don't know if I'll be available Sunday or not -- I've never had chair responsibilities at the conference before, so I don't know what's expected of me once there. Unless I'm conscripted into other important business, I would make it a priority to be with your folks.
This is a draft that I hope to revise, if your deadlines permit that.
Thank-you for your consideration of my submission.
-- Jim Coplien
The premise of the workshop is that objects somehow affect the way teams form and behave, right down to the location of furniture used by team members. I have long held an opinion that the structure of a development team would not telegraph its use of the object paradigm. [1], [2] Furthermore, I believe that successful teams build on organizational structures that are independent of the object paradigm. This has been borne out in empirical studies of dozens of software development organizations.
While I believe that there are behaviors, cultural norms, and practices that often accompany the object paradigm, and which affect the team structure, I believe that 1. Such factors are rarely examined in their own right, but are lumped into "OO stuff" without acknowledgement; 2. Such factors are neither sufficient nor necessary to the object paradigm; and 3. There is little understanding of how these principles work together to bode for the success we wrongly attribute to objects.
I cast the primary observation in light of the following informal definitions:
Define the structure of a development team in terms of its sociogram: the graph of empirical interactions between team roles.
Define the object paradigm as the use of software abstraction and programming methods that build on run-time type support, usually in conjunction with encapsulation, and with inheritance or delegation.
One might include "deep structure" in the definition of "structure," including the processes, value systems and principles of a social community. [3] However, our research has found that processes have little regularity [4]. Our informal observations suggest that principles (like coupling and coehsion) and values (like time to market and customer focus) can be independent of paradigm. We propose that the structure is more closely tied to principles and values than to the development paradigm.
I do not include "application domain isomorphism" as a hallmark of the object paradigm, as this characterizes other software paradigms as well. And I do not include method as a factor. While a software method has a clear and dominant influence on the formal structure of an organization, and to a degree on the instrumental structure, methods correlate in unpredictable ways to the above definition of "object oriented." Calling something object- oriented does not make it so.
If not paradigm, then what factors do contribute to development structure? An ongoing research program at Bell Labs examined structural solutions (in all of the above senses) to common and non-trivial problems of software development. These solutions can be expressed as patterns, and have been documented as such. [5] Many of these patterns reflect principles that are not unique to the object paradigm:
Other development practices, which often support the object paradigm, but which are neither sufficient nor necessary to its use, seem to be important organization drivers. These practices include:
What does this portend for an organization that wants to move to the object paradigm? There are the obvious technical issues -- basic training, competence, and tooling -- that accomanpany any paradigm shift. Are there important and unique organizational challenges? Important: yes; unique: no. These include:
I believe it is important for this community, that is, those who use objects and patterns, to embrace other communities to seek common trends in organization structure and their causes. I'm sure such studies will take us beyond objects into deeper structures of social organization and behavior, many of which can draw on decades-old theory and practice.
[1] Steven Fraser, Kent Beck, Grady Booch, Derek Coleman, James Coplien, Richard Helm, and Kenneth Rubin. How do Teams Shape Objects? - How do Objects Shape Teams? In OOPSLA 1994 Proceedings, October 1994, 468-473.
[2] Steven Fraser, Honna Segel, Kent Beck, Grady Booch, Derek Coleman, James Coplien, Richard Helm, and Kenneth Rubin. How do Teams Shape Objects? - How do Objects Shape Teams? In Addendum to OOPSLA 1994 Proceedings, October 1994, 63-66.
[3] Senge, P. The Fifth Discipline. New York: Doubleday, 1990.
[4] Brendan G. Cain and James O. Coplien. A Role-Based Empirical Process Modeling Environment. In Proceedings of Second International Conference on the Software Process, February 1993, IEEE Computer Press, 125-133. See http://www.bell-labs.com/people/cope/berlin.ps.Z.
[5] James O. Coplien. A Development Process Generative Pattern Language. In Pattern Languages of Program Design, Addison-Wesley, Reading, MA, 1995, 183-237. See http://www.bell-labs.com/people/cope/Patterns/Process/.
Received: 08/14 10:42 PM From: DMWEST@STTHOMAS.EDU
Mr. Kerth:
Much to my dismay the following submission was not sent to you three weeks ago when it was supposed to have been - I have been away and did not notice the oversite until my return this weekend.
I do not ask any special consideration regarding this submission except possible inclusion if there is space available and if you find the position statement to have any merit.
It would not surprise me if you are overwhelmed with hopeful participants, this is a very important and too often overlooked area of interest.
Thank you in advance for any consideration you are able to give to my being included in the workshop.
Sincerely;
Dr. Dave West University of St. Thomas dmwest@stthomas.edu
The problem with culture is that it is all-encompassing and thick with inter-relationships. All of the problems addressed by individuals at this workshop are potentially fascinating and critical to an understanding of the overall problem. To make an effective contribution, however, it is necessary to select a single perspective or problem as a focus while striving to note and point out the links to other perspectives and focal issues.
For me the focal issue is cognitive - how to people come to "think like an object?"
Thinking is not an internalized cerebral activity - it is clearly social. Thinking is not the "formal manipulation of defined tokens" as envisaged by Descartes - it is context and environment dependent. Thinking like an object therefore requires far more than the internalization of a set of concept definitions, a modeling syntax, and a programming language syntax.
Thinking like an object requires a rich set of metaphors (we are dealing with the strange and unfamiliar and metaphor is the tried and true method for making such transitions). Individual metaphors like, "Objects are like humans," that encapsulate important object principles like anthropomorphization; and, "everything is an object," that voices a central object premise - simulation.
Also required are "myths" or stories that illustrate by analogy the world of objects. One example: "objects are like ants - not autocrats," leads into a story of how objects collectively capture and realize behavior that is independent of any given object, just as ants build complex warrens without the help of "architect ants" or "supervisor ants." Another example, "objects are coordinated but not controlled," the title of a story about how automobile traffic is coordinated by a traffic signal that knows nothing more than its own state and the passage of time.
Enabling people to think like objects requires a supportive environment. A certain willingness to "suspend disbelief" - like you do when you go to the movies - and a willingness to "appear foolish" - like you might during a good game of Charades is required to effectively make use of the object concepts, metaphors, and myths. One of the reported strengths of CRC cards as an analysis method derives from the ability to create precisely this kind of environment - "OK, I'm an integer; what are my responsibilities?"
Thinking like an object requires an individual to cease thinking like a "software engineer," or a "C programmer," or a "structured developer." (This is not to say that everything we learned from these other realms must be discarded - it does mean that we must recast our understanding in terms of objects and out new mental perspective.) Shedding old habits and mental structures is a lot harder and more frightening ("after all, what am I if not a software engineer?") than might be supposed. Here we need heros and heroines and inspiring tales of object triumph over the forces unnatural complication.
James Martin (among many others) has pointed out that the "structure of a software system will reflect the structure of the team that developed it." Hierarchical team - hierarchical software. Object team(?) - object software. Dorothy Holland, Naomi Quinn, Jean Lave, and other anthropologists provide an interesting theoretic and empirical foundation for understanding how and why James Martin's observation is correct. More recently Edwin Hutchins (Cognition in the Wild, MIT Press, 1995, ISBN 0-262-08231-4) has provided a highly insightful analysis of how cognitive tasks are performed in a social and team setting.
Hutchins' examines how navigation (a complex technical task performed by a group of individuals) is done aboard a modern naval vessel and a Micronesian canoe with no instrumentation. In both cases he shows how the "thinking" required to be successful is a mixture of cognitive properties of individuals and cognitive properties of the system - the collectivity of individuals, their culture, and artifacts at hand.
Current cognitive anthropology might provide a template for discovering and describing a "culture of objects." The work of Hutchins in particular might be used to provide a "pattern" for thinking about the problems involved. Given the opportunity to participate in this workshop I would set a personal task to abstract a tentative pattern from Hutchins' book and share it with the other participants for discussion.
None of the above deals directly with the problem of transition - how do we move people from one cultural milieu to another? (Assuming of course that we have a clear object culture to move to.) Here we might seek a pattern in the classic work of von Gennep on rites-of-passage and the modern anthropological work of Victor Turner on "liminality."
There is much to discuss and much to absorb from other disciplines if we are to advance the goals implicit in this workshop.
Ten years ago I was a successful software systems developer (and senior manager) confronting the peculiar fact that almost every system with which I was familiar failed (or succeeded) as a result of non-technical, human, factors. Hardware, software, methodologies, and even management techniques seemed almost irrelevant. Seeking answers (though finding, more often than not, more questions) I returned to school to pursue a Ph.D. in Cognitive and Cultural Anthropology at the University of Wisconsin at Madison. Concurrently I worked on and received a Master of Science in Artificial Intelligence from the same institution. Currently I teach OO Development with an almost exclusive emphasis on Smalltalk implementation in the graduate software engineering program at the University of St. Thomas (Minnesota - alas, in January - rather than the Virgin Islands). I am also Founder and Director of the Object Lab at that University. My interest in the "object paradigm or metaphor" extends beyond the world of software development to business engineering and, beyond that, as an approach to understanding complex self-organizing systems - the subject of my current sabbatical research.
Received: Wed, 14 Aug 1996 11:00:31 -0400 bachmann@fr.bosch.de
Revision Received: 08/22 2:03 AM From: Bachmann, Felix.Bachmann@fr.bosch.de
This paper presents a lesson that we, as members of a central group within Bosch responsible for introducing Object-Orientation to development departments, learned through two large projects within the telecommunications field. The lesson is that correspondence between the role of the catalyst and the goals of the project can be decisive for the success of the project.
Five years ago, Bosch established a software center (SWC) to support Business Units in developing products with increasing software content while lowering costs and maintaining high quality. Two of the initial projects of the SWC were to replace the traditional development methods in two of the Business Units with Object-Oriented analysis, design and development. The first project was the development of PBX software, the second, the development of a private mobile radio system.
Although the conditions at the start of both projects were comparable, the PBX project came to a less than successful end while the radio system project was very successful. In both projects the developers were to be trained to use object oriented technologies. The members of the SWC also had the implicit goal of ensuring that the projects produce competitive products.
In the PBX project, the SWC team encountered a group of developers that were not completely committed to the new technology, and also because of lack of experience, not particularly able to articulate their opposition. The project did not progress as quickly as expected and the SWC team decided to "help" by ironing out the concepts for the deliverables themselves. This quickly led to the SWC team members becoming opinionated and to the perception that it was the SWC's product.
In the end, the developers had received their training, most had a good understanding of object-oriented development, some had an adequate understanding of object-oriented design and a few understood object-oriented analysis.
In the private mobile project, the SWC team focussed on training the developers and letting them make all product decisions, whether the team found them appropriate or not. Analyses and designs from other projects were used as examples, but the team did not attempt to force the developers to use the same approaches.
In the end, the development department not only produced a good product design, the development team were excellent in all aspects of object-oriented analysis, design and development, and as such, represent a very valuable asset to the company.
There are two possible approaches experts can choose to support the Business Units in using new technologies for developing the software. The first approach is that the members of the SWC build products themselves, typically prototypes, to show the applicability of new technologies. We call this 'product-oriented'. The second approach is to train the members of the Business Units to use new technologies. We term this is a 'personnel-oriented' approach.
When external experts are brought in to introduce Object-Orientation within Business Units, they will always be confronted by two fundamental things: the product and the people who develop the product. The experts and the Business Units must have a clear understanding of what the task of the experts is. Is it to demonstrate the applicability of the technology by developing a prototype or to train the people? Both approaches are possible and valid, but they differ with respect to the approach to the introduction of the technology that should be taken.
When the task is to develop a product, then the development team should be principally composed of experts in the new software methods (members of the SWC). It may be appropriate for Business Unit personnel to act as experts for the application domain. Effort must then be expended to prepare the Business Units to accept the product (prototype) after it has been developed and to further develop it. In this case, the project personnel are the means to the end.
Indicators that the emphasis lies on the product:
a) The experts make the product oriented decisions
b) The experts cannot leave the project without great difficulty.
c) The time to develop the product is short, as the development team is already well-trained.
When the assignment is to train, then product considerations should be forgotten and the trainers (member of the SWC) should employ the usual pedagogical and motivational techniques. The product could certainly be used as an example for learning, but it should always be kept in mind that the product is a means to an end and nothing more. Normally the trainers are (and must be) technology experts and it is hard for them to distinguish between the product-oriented and the people-oriented roles.
Indicators that the emphasis lies on the project personnel:
d) The trainer prepares the groundwork (contrasts the advantages and disadvantages) but the project personnel make the decision.
e) The trainer could leave the project at any time without causing a major upheaval. The project personnel would continue working with the skills that they had acquired up to that time.
f) The time to develop the first product is longer, as the learning process is operative.
Note that in the first case, the responsibility remains with the developers of the prototype, at least until a Business Unit adopts the product whereas in the second case the product is always the responsibility of the Business Unit personnel.
Note furthermore that experts are normally hired who excel in computer science and can therefore competently assume the first role, but other than in exceptional cases, that they do not have pedagological training. Such skills are necessary, however, in order to successfully fulfill the second role.
There lies a dilemma. In the second (and in our experience more successful) case, the goal is to raise the skill level of the Business Unit personnel through training but in order to be accepted by the developers, the trainers should be also experts with product development skills.
A firm that wants to establish something like the SWC described in this paper must recognize that both approaches (product-oriented and personnel-oriented) exist and are needed. It must also be clear to the Business Units which job the SWC has or should have in each particular case. Moreover, each member of a SWC must decide which type of activity is appropriate for him/her as no one can assume both roles equally well.
Those who support the project personnel must receive pedagological (moderation) training, possibly with repetition every year.
Those who specialize in developing prototypes must receive technological support, but also especially support for the introduction products in appropriate Business Units.
Felix H. Bachmann Diplom Informatiker (FH)
In 1977 Felix Bachmann began his career to educate service staff how to determine and rectify software errors in the first computer controlled telecommunication systems. On the basis of his activity the company (former Telenorma, now Bosch) was able to quickly accommodate special customer requests.
By virtue of this experience Mr. Bachmann was able to use the ensuing nine years to contribute to several software development projects aimed at improved service efficiency and customer friendly telecommunication products.
As was evident at the time, it was clear that the dynamic growth, competition and complexity of software development demanded exceptional and creative software engineering.
In response to the market trends of 1990, Mr. Bachmann addressed the quality assurance issues and aligned them with the goals of high-quality and excellence in customer support. After his transfer to the Robert Bosch research institute he worked with the software development departments to address the issues of the 'call-control software', the core of telecommunication products. This is where he developed the foundation for the next generation of telecommunications software. As a result of these efforts Bosch developed the method OTES (Objects Through Essential Services) in which Mr. Bachmann played a decisive role. The goal of this method is to find a stable domain-specific architecture where new features can be easily imported. Two important projects in which Mr. Bachmann defined and tested the method are:
The software for private telecommunication systems (PBX-system) and The software of a digital private mobile radio-system (radio-system for police departments, fire brigades etc).
Mr. Bachmann also defined the corresponding software development process which describes in three levels how to develop high quality software in a timely fashion. Here a "Use-Case" driven approach (see Ivar Jacobson) is used.
Presently Mr. Bachmann is working on the solution to resolve the consequences of the developmental process. A second endeavor is to coordinate and facilitate the sharing and exchange of information among geographically dispersed locations.
Robert Bosch GmbH
Research and Development FV/SLD Fax: +49-69-7505-6320
Felix Bachmann Phone: +49-69-7505-6308
Kleyerstr. 94 e-mail: Felix.Bachmann@fr.bosch.de
60326 Frankfurt - Germany
Received: 08/14 10:42 PM From: Dave W. Smith, dws@best.com
Ward, Norm,
It would be a pleasure to help out with the People Side of Objects workshop. I have an idea, which I'll sketch out below, but also have some near-term time commitments that kill an August 15 deadline. Saturday the 17th is doable, and I hope that the idea is sufficiently intriguing to permit a slight stretch.
The flip side of today's increasing rate of technological change is a decrease in the half-life of technological skills. To remain active and competitive, people need to aquire more skills faster. But this means less time on learning "plateaus" [diagram], where new skills have time to gel, and more time in uncomfortable "transition" states [diagram]. With this discomfort comes fear. Succeeding in our projects requires dealing with fear within ourselves, and providing a safe environment for our team members to acknowledge and work through their fears.
Informal studies into the psychology of skills acquisition [George Leonard, "Mastery"; Buzan and ?, "Lessons Learned from the Art of Juggling"] and into organizational transitions [Bridges, "Managing Transitions"] suggest some ways forward.
(a couple of slides, one per point)
Present the model of skills aquisition [diagram] to help people be comfortable with being unfortable.
Conclusion (needs work): Change is inevitable. Change means transitions, and less time in our old "comfort zones". Fear is normal, and we help ourselves and our teammates by acknowledging it. To survive we'll need to learn to navigate transitions and acquire new skills more rapidly. There's leverage to be had by being deliberate about real teamwork.
Revision: Mon, 19 Aug 1996 12:05:17 -0700 From: "Dave W. Smith" <dws@best.com>
The drumbeat today in many industries is "work harder, work smarter, work faster, or the competition will have you for lunch." Couple this with rapid advances in technology in our industry, and we have a pretty scary situation. The half-life of a technical skill set is decreasing. To remain competitive, we have to acquire new skills quickly. But this means less time on learning "plateaus", where new skills have time to gel and get exercised, and more time on uncomfortable learning curves. For those of us whose professional self esteem is based largely on our ability to exercise our skills, this presents a problem. As time in the comfort zone decreases and discomfort becomes the norm, fear can creep in. That nagging little voice tells us that it's all getting too complicated, that the next curve in the road is the one we won't be able to negotiate, that our careers are about to be toast.
Continued success--even survival--in our professional lives may require that we give this issue serious attention, both to deal with fears within ourselves, and to better serve our teams by helping them acknowledge and come to terms with their fears.
This aspect of the "people side of objects" hasn't gotten much play yet. In my search for answers, I've found two promising sources of short-term relief:
These are near-term avenues worth pursuing, but are not likely to be long-term solutions to the problem of rapid-change induced fear. I raise this issue primarily to get it out in the open for discussion.
Dave W. Smith, Presidio Systems <dws@presidio-systems.com>
Dave Smith is a practitioner with 15 years of product development experience in small organizations, including 8 years as an architect, project leader, and manager in various object-based projects. He currently leads a distributed data collection project at Presidio Systems. Prior to that he managed the database group at ParcPlace-Digitalk, and the user interface group at DB Software/Cadre Technologies.
After puzzling over why some projects succeed against all odds, while others fail when success seems assured, Dave became a student of project leadership, first on the process side, and more recently on the people side.
Date: Thu, 15 Aug 1996 13:15:32 -0400 From: ACockburn@aol.com
Alistair Cockburn
Humans and Technology
7691 Dell Rd
Salt Lake City, UT 84121
arc@acm.org
I sometimes hold this position:
"OO is so like other programming that very little changes as regards people issues."
I consider that this statement is sound to the first approximation, which is where most casual discussions stop, not true at the second approximation, and I don't know the answer at the third approximation.
The first approximation is this: do we have to rethink how we run a software project if OO is being used? My answer is No. All the fundamental issues are the same now as before:
Therefore, be enlightened about handling people now, or be unenlightened - the issues and responses will be the same. The enlightened non-OO methodologies of yesterday should be carried forward to become the enlightened OO methodologies (we should not flagelate them for being non-OO, we should celebrate them for treating humans well).
The second approximation is: Well, then, is anything different to take into account? My answer is Yes.
I don't know exactly why OO seems to require much more interpersonal and interteam communications, whether that is necessary or an artifact of immature design processes. I can argue that objects, by virtue of their encapsulating a set of capabilities rather than a simple function, have a wider range of clients, and hence a more complex interface. At the same time, I am beginning to see OO designers pay attention to the thickness of the interface, weighing designs to reduce that complexity. Whichever it is, the end effect is more interteam communications, which is an aggravated people issue, especialy since programmers are not a very communicative bunch.
Current projects seem to need people with a tolerance for ambiguity. I actually assign this to the iterative process, not on objects. But objects are abstractions, and the very concrete/specific developers I have met are the ones who have had the hardest time producing an OO design. So I take abstract thinking ability as a requisite OO trait.
Associated with abstraction, but much easier to learn, is "OO think". This is a rethinking as is needed to shift into any new paradigm, as it would to work in functional or logic languages. The structure of the problem, the structure of the solution, the structure of the thinking, must be altered. I have made the shift from hardware design to linear programming to object programming to logic programming, so I have a visceral sense of that shift in thinking. Each time it took numerous months, after which there was a different muscular sensation about working in the paradigm. While it is different, it is learnable (I do not say "teachable"). A relevant topic to study is how to shorten the time to think that way.
The third approximation is: how many of these differences are truly object-related, as opposed to a secondary symptom of another driver? I don't know. I suspect the abstraction part is essential, even though the best designers I have met always work at high levels of abstraction and design based on abstractions, even in non-OO languages. I think the everyday designer has to be comfortable with abstractions to make objects work. I also suspect that interteam communications will always stay high, but I shall wait for further developments in that.
The net position is: don't overexaggerate the differences between OO and non. Attend to the few differences.
Maybe I can continue to contribute by bringing over some conversation from the Education workshop. Rick Mercer is trying out my teaching ideas in his current class, taught to sophomore business majors. We discuss the needs of his students plus the idea of design.
Leaving out lots of things, one of the points we are exploring now it that:
It is not that you teach good design (i.e., that after the course, the
students
can produce a "good" design), but that you teach how to talk
about designs.
Doing the latter means that the student is open to continuous learning over a long time. My goal is to teach both my students and my team members to talk design. I have learned not to expect design subtlety from the novice developers in my class; the older, sophisticated developers in my OO class still produce the most subtle designs. However, on the project, if the people start talking and comparing designs on a daily / weekly basis, the entire quality of design starts to move up over months.
This is a people issue and relevant to the people workshop.
On the last project, after oneyear, the head Smalltalk developer left and I took his place. There were eight Smalltalkers in the room. My predecessor was a non-communicator. He would come in at night and change the novices' code.
Almost immediately, I changed the conversation in the room. When anyone would ask a question, my answer was directed to the issues in their design and why they wanted to do something. A couple of weeks later, my happiness was when the guy in the back corner calls over, "Hey, Alistair, could you come and look at these responsibilities and communications patterns over on the board here? I am having trouble deciding which one to choose." Each of the designers developed a preference of how to move into a design, and how to talk about it. But they talked design, and they learned their craft.
Alistair
Bindu Rao writes:
Alistair's Position: OO seems to require more interpersonal and interteam communications.
Remarks: Does this imply that OO introduces too many unnecessary dependencies? If so, why? Then,how do we go about decoupling the dependencies? The roles and responsibilities of participants in an OO project must be properly understood by all participants. The deliverables from each must be neatly laid out. Thus, communications will be limited to necessary interactions.
Alistar replies:
Hi, thanks for writing. "...seems to require..." is an odd phrase, isn't it? "Seems to" means that my experience points that way, for no known or given reason. "Require" means that it is unavoidable. Can this be true? I don't know, but it is my experience.
Then "unnecessary dependencies". What is an unnecessary dependency, and how do you know if you have it? I don't know whether I have one, so this is a hard question.
Finally, "roles must be understood". Yes, even if there are unnecessary dependencies, so this an independent issue and we can leave it to the side.
A messy business, and quite natural you call me on it. My current thinking runs along these lines. "Structured Design" claimed to minimize interfaces by minimizing coupling, maximizing cohesion. A possible implication of that is that you also minimize the communication needs between teams - they each work on separate modules, and the modules have minimal interfaces, therefore the teams have minimal interfaces.
OO never claimed to minimize interfaces. Therefore it is plausible that the intermodule interfaces are "fatter" than a structured design's, and hence there is more interteam communication. That is what I mean by "more interteam communication" - more than, say, a structured design would require.
I can also argue that this is good and necessary. The modules have more clients, and rightly so, since each design module encapsulates a capability. We minimize (modules affected per requirements change) at the expense of (interteam communication). Basically, we have to hack out all the implications of a capability early on, which takes a lot of talking and examining and shifting around. The structured design does not need that, but then it requires more rewriting later on.
So I do not mean that the extra communication is "unnecessary". Quite possibly it is all necessary. It is "more".
(Norm, Ward, I copied you on this since these notes have to be my presence there on Sunday. I would appreciate your making them available to the other workshop participants. Thanks -- Alistair.)
Recieved: Sun, 18 Aug 1996 20:45:02 -0400
Norm, Ward
I just got myself set up to attend OOPSLA this year, and would much like to attend your people workshop if space permit. I know it's late to apply, but here's my info, offered in hope.
I'll set down a summary of what's on my mind with respect to the people side ... if I'm accepted to the workshop, I'll revise these thoughts into a more formal paper for the participants. (I'm guessing that's what you'll want for the workshop ... if not, I'll provide whatever is needed.)
I've been a systems developer, at the technical and management (even executive) level for over 30 years. In that time, my best results have been when I was close to the people actually doing the development, and actively involved in that effort.
In OO, my experience has been mostly with Smalltalk.
I was at Allen-Bradley for a bit over three years, as part of the Advanced Technology Development group, whose responsibility was to learn technology, build prototypes, and transmit the knowledge to the product organizations. At A-B, I led the OO technology team, who were working on definition and description of automation systems, using Smalltalk. The people side of things had to do with introducing the technology to the product organizations, where we tried to help them in the face of the natural resistance of non-OO people to adopting a new technology.
I worked at Oak Tree Software (with Cold River Software) in Ann Arbor, where we were building a framework to allow tax domain experts to build a professional product for personal income tax preparation. That was where I met Ward, who helped us with system performance and our own process issues. We were successful in releasing the product, but were not successful in the marketplace. Many of the issues in this, um, non-success, were people ones. We never forged a good working relationship between the customer, the OO developers, and the tax developers. The fundamental issues had to do with correctly determining and communicating what would be done, and when. From those difficulties arose other ones, resulting in lots of heat and little light. I learned a lot, if not in time.
Since March, I've been working as Kent Beck's on-site coach on a large IS project to produce a payroll program capable of supporting all the functionality of the company's (five?) existing payroll systems. The project is being done in Smalltalk, and is a recovery project after the initial project was found to be on the edge of failure.
On the payroll project, we've been applying the principles of team programming, CRC cards for communicating design among developers and with the customer, Kent Beck's Smalltalk programming "Best Practice Patterns", and a project estimation and management scheme that is a synthesis of Ward's work, Kent's work, and lots of other experience as well.
The project is based on stories written by the customer (with questions and feedback from developers). We have divided up the stories into ten three-week iterations. Each iteration begins with a planning session where the developers sign up for the stories to be done, and estimate the "perfect" developer days to implement them. We factor developer time, currently using a factor of two between perfect days and real days. When the load is higher than we can accomplish, we allow the customer to choose the stories that will not be done, or to split stories into parts that will and will not be done in the iteration. Often we choose to do what Ward calls a "spike", an end-to-end implementation of the desired functionality, to gain an understanding of what has to be done and how to do it.
We always work from the developers' time estimates, and do not ever pressure to do more than they believe can be done. There is a built-in pressure to live up to one's own estimates, but to the degree we can accomplish it, pressure isn't part of the process.
At the same time, since we have a complete plan for every iteration, the customer and management has complete knowledge of what is being done, and what, if anything, is being swept forward into the future. This ensures that while progress can't always be as imagined at the beginning, all decision-makers are fully up to date on reality.
So far, we're tracking very well against the original plan, but even when a particular iteration has done less than originally hoped for, the open communication has kept things very above-board and healthy.
We have a huge array (600+) of unit tests and over 100 end-to-end functional tests. These are used religiously to determine that new functionality can be released, and to ensure that the system is learning to do payroll as the customer wants. All unit tests must run at 100% before ANY new software can be released ... and we release new software multiple times per day!
The development effort is very team-oriented. We try to have all actual domain development done by two developers sitting together. It has been an interesting process getting this to work, as not all of them do it naturally. We've tried a number of things to help it happen.
My own role has been to serve as Kent's eyes on the ground, to be the (gentle) enforcer of the coding patterns, to contribute to design sessions, to help with sticky coding problems, generally to serve as a senior consultant to the project without having overall project responsibility. In addition, I've wound up advising the project manager on how to interact with the people, how to collect metrics, and how to appear calm when all about you are losing their heads. I've needed to gently derail or rerail unproductive discussions; to calm distraught customers; to encourage people who feel they aren't getting it; to reassure paranoid developers that while the world is out to get them, we won't let it.
Now that I think about it, I've been working my tail off.
The project is a very interesting example of project resurrection from a failing one; a very interesting example of application of coding, testing, and project management patterns. I look forward very much to discussing it with the workshop participants.
Thanks for considering me ...
Ron Jeffries
11359 Pleasant View Dr
Pinckney, Mi 48169
313-878-6449
jeffries@ic.net
Received: Mon, 23 Sep 1996 20:32:16 -0400 From: Ron Jeffries <jeffries@mail.ic.net>
Here's what I'm thinking about in regards the People Workshop. I apologize for taking so long to get this down on "paper": I thought I knew what I thought.
To the People Workshop Participants:
My ultimate purpose here is to identify some things that limit results, and to offer ideas on how to make them better. This is a work in progress: right now there are more questions than answers. At the "People" session, these are the things I’ll be working on. I look forward to sharing with all of you.
Introduction
It often seems that, even with good people trying hard, our results aren’t as good as they should have been. How do we recognize, before it’s too late, that this is happening; what do we do about it?
If you have people who just can’t cut it, or aren’t trying, use the pattern: Get Them Off The Project. The commonly-used alternate, Put Them Where They Can Do No Harm, is much less desirable, less effective and bad for morale. Here, we’re concerning ourselves here with good people, who are trying hard.
The things that go wrong usually fall into a few major groups:
There’s a famous saying: "There’s never time to do it right, but always time to do it over". The truth in programming is often worse: sometimes code gets worse and worse because it appears that it will take longer and longer to clean up the problems. We never get around to it. Code rots.
Real or perceived time pressure
Time pressure is a big contributor to this one, of course. If we feel pressure to get done, in our natural desire to please, sometimes we wind up cutting corners to get in the main functionality. Then we feel pressure to move on to a different piece of functionality, and never get back to clean up the mess. After a few additional features are added to the code, even the prospect of cleaning it up becomes daunting. Code rots.
Focus on the larger goal
Sometimes we’re doing a task as part of some larger task. We just need to find a way from here to there, so we "navigate" through a bunch of objects to get the thing done. Moving on to the larger task, we forget the bizarre code we have left behind. Code rots.
Focus on too large a goal
Sometimes we focus on a task that goes beyond what we’re actually there to do. We are considering future cases that might not arise, forms of generality that would be "nice". Often as not, those capabilities aren’t even needed. Even if they are, they aren’t needed now, and we don’t know enough now to really do a good job of them. In the best case, we waste time and add code that no one uses.
No time to do it right, no time to do it over - What can we do?
Kent Beck tells us always to do the simplest thing that might possibly work. This means, never implement a complex solution if a simple one might do. It also means not to implement something that couldn’t possibly work.
To know that something might work isn’t too hard. To know that it is the simplest thing, it often helps if you think of two ways to do it. Particularly if the first way you think of is overly complex, and it may well be, waiting a few minutes until you have two ideas to compare is a good way to pick something simple. At least you’ll be sure you aren’t doing the most complex thing, since you’ll have eliminated one solution more complex than the one you choose.
Since time pressure is one of the main reasons why we write bad code, we must eliminate time pressure. Since bosses and our own consciences won’t really turn off the pressure, we have to learn to act as if it weren’t there. Use CRC cards to sketch a design; build a prototype and throw it away; code your tests first; walk around the building; talk to someone about what you’re doing before you do it.
Fact is, doing those things makes us produce better code faster. The more time pressure we feel, the more we should do them.
Dale Carnegie says, "If you act enthusiastic, you’ll be enthusiastic". Maybe if we act calm, we’ll be calm. In any case, we’ll sure make everyone else wonder.
Usually when we write something, we know whether it isn’t very good. We know whether it’s bad. If it is bad, don’t let it stay in the system: it will come back and bite you when you have even less time. Now that the problem and solution are fresh in your mind, clean it up. Even if you have to rewrite the classes in question, it won’t take as long as the first time.
There is no greater time-waster and energy-sapper than working on something that isn’t going well. You’ve written this mass of code, the day is getting old, and it still doesn’t quite work. You edit, change, breakpoint, put halts everywhere. You are starting to suspect that the Smalltalk compiler has a bug in it. When people say things to you, you ignore them or shout at them.
Face it: you’re stuck.
You know that thing where you’re trying to remember someone’s name, and you just can’t get it, and finally you give up and a few minutes later the name pops into your head? It works in software development too. We have to learn to use it.
The first thing is to recognize that you’re stuck. Here’s how: think about how you would program Smalltalk to recognize that you were stuck and pop up a window that told you. What would your telltale signs be? Putting halts in more than three methods? Editing the same method multiple times? Setting halts that never get hit? Repeated typing and syntax errors that you don’t usually make? Increasingly foul language? Slamming your mouse on the desk?
It almost doesn’t matter what else you do when you’re stuck: just stop what you’re doing and take a break. Do whatever is necessary to relax and to think about something else, anything else. Get it out of your head.
Sometimes the answer will come to you before you even get to the soda machine. It’s OK to go right back. But if it doesn’t come instantly, take that break.
Whenever you have the chance to tell someone else about what you’re stuck on, do so. They might have an idea, but more likely just telling someone will organize your thoughts differently and give you a new angle on the problem that’s almost certain to solve the thing.
If you stay stuck for more than an hour (maybe even less than that; set your own timer), you really should throw the code away and start over. Bet you don’t have the nerve to do that!
"Don’t ask questions, don’t tell them you don’t know." Sometimes we’re afraid to admit that we’re stuck, particularly when we’re stuck at the very beginning, or on something that "everyone else knows". We waste hours, when in fact a little tip from the right person could really get things going much more quickly.
"What if they find out how dumb I am?" Don’t sweat it. Most people love to show off how smart they are, and if you learn something from everyone around you, pretty soon you’ll be pretty smart yourself. Meanwhile, everyone already thinks you’re smart because you’re smart enough to come for them for help. When you’re stuck, at the beginning or in the middle or at the end, you owe it to yourself and the project to get unstuck. Ask someone; ask anyone.
Sometimes you’ll notice someone else cursing and throwing their mouse, or showing some other signs of being stuck. You can probably help out by interrupting them (though you should be ready to bat away a thrown mouse). Say something like "I know you’re busy, but can I ask a quick question?" If they allow it, ask something simple but believable. After they answer, they may well volunteer what they’re stuck on. If not, ask "Whatcha workin on?" If they don’t want to answer, thank them and wander off. If they start to tell you, listen and ask intelligent questions. When they scream "Eureka" and turn around, go back to your computer.
Often you’ll find yourself in a discussion, with yourself or with others, about how impossible it is to do something. These can go on forever and are never productive. One good way to break out of the loop is to say, "Well, we could …", and go on to describe a solution that is incredibly impractical, but that would work. Almost every time, someone will improve your solution.
Bill: "There’s just no way we could know the average monthly salary
for that screen.
You: "Well, we could just go over all employees and add them up.
Bill: "That’s dumb: it would take forever. Even you know we need 1/3
second response time. Even with an index …
Dave: "What if we started a separate task …
Jim: "We could keep the average around and use a weighted …
It’s true, Bill may never realize who broke the log-jam. But the jam is broken, and the problem is being addressed. If you need to avoid the almost inevitable abuse that comes with the first response, you can preface your remark with something like: "Well, this wouldn’t work, but just to get us going …"
Fascination with tools
Over-exercising some valuable skill
Sometimes we wind up with bad code by using the wrong tool for the job. Often this comes about because we, or someone else on the project, has some favorite invention or object that they insist on using on every occasion. This is the "small boy with hammer" syndrome: to a small boy with a hammer, everything looks like a nail.
If you find that an object you have provided, or that has been provided for you, isn’t fitting the situation, consider whether you need a torque wrench. What other object would make the system really better?
One rather good way to be sure you aren’t using the hammer when the task calls for a torque wrench is to think of two good ways to solve the problem. Make the case for the one that isn’t obvious. Take ten minutes to argue for another way. Then decide.
No one’s baby is ugly. Sometimes we feel that way about our code: criticize my code and you criticize me. We become defensive at the moment when we could best use some objectivity. Try hard to listen to what people, or your programs, tell you about the objects you’re using. If it’s awkward, weird, slow, unreliable: probably you’re doing something wrong.
If you actually succeed in this case in setting your ego aside whenever you need to, please write and tell me the secret of how you did it.
I’ve tried here to outline as many of the causes of poor code as I can think of, and to delineate causes and actions to improve them. This is a work in progress: your input will be very welcome.
Recieved: Mon, 19 Aug 1996 02:03:32 -0500 from: yoder@freedom.ncsa.uiuc.edu
Please accept this paper for the workshop: The People Side of Object-Oriented Technologies. Thanks for the extension as I didn't receive information about this until very late and then recieved something from Ralph on it. I believe I can provide a useful contribution to your workshop and look forward to seeing you at OOPSLA and PLoP.
take care....joe
Joseph W. Yoder
August 19, 1996
There has been some recent success on the research and development of a "Business Modeling" application that is to be deployed at Caterpillar, Inc. Caterpillar, Inc. joined the National Center for Supercomputing Applica- tions at The University of Illinois as an Industrial Partner in December 1989 to support the educational function of the University and to use the Univer- sity environment to research new and interesting technologies. During the partnership Caterpillar has initiated various projects, including the evalua- tion of supercomputers for analysis and the investigation of virtual reality as a design tool.
The most recent work is a pilot project to demonstrate how an appropri- ate tool might support financial analysis and business decision making more effectively. This Business Modeling project aims to provide managers with a tool for making decisions about such aspects of the business as: financial decision making, market speculation, exchange rates prediction, engineering process modeling, and manufacturing methodologies.
When we developed the Caterpillar Business Model, we quickly realized that every business unit had its own variations on the way that they did business. Therefore, instead of trying to build a single model, we built a set of frameworks for building financial models. When we started, however, we had no idea what these frameworks would look like. So, we started with a dynamic programming environment (VisualWorks) that would make it easy to change our programs.
The financial portion of this application has had many frameworks suc- cessfully developed that have potential for reuse. Work has been done to- wards training internal Caterpillar developers at learning Smalltalk and our frameworks and a current implementation is being deployed successfully at a single Caterpillar plant.
In spite of this success, there has still been many problems getting Cater- pillar to be able to be successful at using this technology and for them to get the "warm feeling" for re-using our components within other Caterpillar plants. To date, there has not been a corporate wide integration of OO technology or even a broader use of our frameworks.
This leads me to consider the following questions. Where have we fallen short on our technology transfer? How can we help Caterpillar move to OO thinking quicker and see the benefits that we strongly believe in.
The first problem we dealt with was training. Caterpillar has a few small pockets of people experimenting with OO technology, but no corporate com- mitment to it. At the beginning of this year, we started with 3 Cobol pro- grammers with very little PC and client-server background. We trained them over a four week period with an introduction to Smalltalk and an introduction to our frameworks.
The OO way of thinking was very foreign to the Caterpillar people. Because of this they were very frustrated and voiced that frustration to their management. Management in turn had concerns on being able to get their people trained for supporting our financial application.
We continued working with the Caterpillar people training them with our frameworks and letting them take a more active role on the develop- ment. The people we have trained have now gained internal confidence and managements confidence that they will deploy a successful implementation of the financial application for at least one plant.
This success has been good towards building confidence but their is still a lack of corporate support for integrating this technology more fully into Caterpillar or for even re-using our frameworks for other plants.
The primary concern that I have been able to elicit from Caterpillar is that there is a large learning curve in order to get their people up to speed. They still believe that there is a high-risk factor for integrating OO technology, Therefore, management support has not been forthcoming and the committed resources have been very limited.
Part of management's problem seems to have come from expectations. They expected their people to learn Smalltalk, the problem domain, and our framework including mapping the OO technology to a relational model within a few months. They also put a lot of pressure on their people to perform within this time frame. It was at least six months before the Cater- pillar developers really became comfortable with all of this. It seems that managing expectations is very important. And by this I mean not only the expectations of management, but also the expectations of the new teams learning how to use objects.
Another problem we ran into was that we were evolving the frameworks quite a bit while trying to teach them to the Caterpillar people. They were not use to this quick change as it made it more difficult for them to learn our frameworks, or, worse yet, they would just learn how to do something and we would change it. Once you become proficient with a language like Smalltalk, you are very open for this type of development. However we noticed that new developers do not like this. Therefore, when teaching new developers, it is important to use stable frameworks.
Integrating OO technology corporate-wide definitely deals with many cul- tural issues and much care needs to be taken to train people with this new paradigm. Not only does a focus on the teaching of the developers on OO thinking and ways of assisting them with the transfer of OO technology, much effort needs to be done on training management with dealing with cultural behaviors while introducing objects and to assist them with dealing with the fear.
It also seems very important to manage expectations. Give the people time to go through the transition with little risk and allow for possible failu* *re during the early transition to OO technology.
I graduated with High Distinction and Honors from The University of Iowa in Computer Science and Mathematics. Since then, I have completed a Mas- ter of CS degree in the study of problems of the computer-based recording of medical records at the University of Illinois. I primarily focused on the development of computer-based system for the collection of physical exam findings. This design of this system employs an object-oriented approach through the direct manipulation of graphical objects integrated with hyper- text approaches and semantic networking to build a system that is more natural to the user.
I started working with Professor Golin at the beginning of 1993. His focus was Theory, tools and applications of Visual Programming. I was leaning towards providing a visual environment for the development of in- telligent agents to assist in intelligent automatic user interfaces for my PhD work before he resigned from the University.
I am currently working on my PhD with Professor Ralph Johnson. His focus is on object-oriented technology and how it changes the way software is developed. In particular, he is interested in how to use and develop frameworks, which he believes is a key way of reusing designs and code using objects.
I am investigating "visual languages for business modeling". I am de- signing them, using them, and implementing them. My current focus has been on using frameworks to develop and implement visual languages for use with business modeling. This project is aimed at providing support for decision making during the business process.
I believe that Frameworks are both a way of coming up with visual languages and a way of implementing them, because if you focus on build- ing something in an Object-Oriented language, then building a framework for it, then making the framework composable, and then making a direct manipulation tool for composing applications using a framework, you will automatically discover a visual language.
I am also interested in finding and describing the design patterns in visual languages and business modeling. To support this I am also research- ing "Domain Analysis and Engineering". This project is being funded by Caterpillar at the National Center for Supercomputing Applications.
My Research Interests Include: Computational Theory, Learning The- ory, Human Computer Interaction, Software Engineering, Computer-supported Cooperative Work, Visual Programming (including grammars and parsing), Expert Systems, Intelligent User Interfaces (providing intelligent automatic semantic feedback), Object-Oriented Programming and Databases, Design of Reusable Software-specifically with the use of frameworks, Domain Anal- ysis and Engineering, and Pattern Languages of Programming.
I enjoy learning and have worked many jobs during my academic career including: Teaching Assistant, Research Assistant, Consulting, Systems An- alyst and Programming, Honors Research, Design and Implementation of Medical Computer Systems, etc.
Joseph W. Yoder
Internet: yoder@cs.uiuc.edu
Usenet: uunet!uiucdcs!yoder
Dept. of Computer Science, Univ. of Illinois
Phone: (217) 244-4695
1304 W. Springfield Ave., DCL, MC 258, Urbana, IL 61801-2987 USA
WWW Page: http://freedom.ncsa.uiuc.edu/~yoder
Recieved: Tue, 20 Aug 96 16:37:39 From: "Brown, Kyle" <kbrown@ksccary.com>
Here's my bio and submission. Sorry it took so long. It's kind of light hearted, but I think it makes some valid points.
Kyle
Kyle Brown is a Senior Member of Technical Staff at Knowledge Systems Corporation. He has over seven years of experience in building small to large scale systems in Smalltalk. He is the author of numerous articles for Object Magazine, The Smalltalk Report and Software Development Magazine, and has presented presentations on Smalltalk and patterns at many OO conferences. He is also the co-author (with Bruce Whitenack) of the pattern language "Crossing Chasms: A Pattern Language for Object-Relational Integration", published in Pattern Languages of Programs Design 2.
Over the past several years the spiral model of software development has supplanted the waterfall model in almost all software development organizations using object technology. However, there is another vestige of the waterfall that forms a hindrance to building really effective teams. I'm referring to the organizational equivalent to the Waterfall model - the division of labor in project teams according to the stages of a waterfall.
Organizations that would never think of having projects follow a waterfall do not think twice about giving their software developers titles like "Analyst", "Programmer" or "Architect". A sneakier, more "OO" version of this is to divide people into "class builders" and "class users". However in most organizations these words are still synonyms for "Analyst" and "Programmer".
The problem is that we should know better than this. One of the hardest lessons to learn has been a central theme of Jim Coplien's Pattern language "A Generative Development-process pattern language". People working on successful projects using spiral processes generally work across artificial boundaries of Analysis, Design and Implementation. Understanding the deep meaning behind his Pattern 15: Architect also Implements is absolutely crucial. It must be kept in mind that the original words in Greek from which "Architect" is derived are usually best translated as "Master Carpenter". Trying to fit a spiral model into an organization where people still think of themselves in waterfall roles leads to turf battles, squabbling over deliverables, and poor communication. It's an almost sure recipe for failure.
Instead of dividing people according to their roles in the waterfall, let's try working out a division of labor better suited to the new spiral model. Instead of looking to the waterfall model, for inspiration let's look back to the days of medieval craftsmen. If we can understand how the Cathedrals of Chartres and Notre Dame were built, it may provide us with some inspiration for building our own software edifices. I will propose that we instead divide our labor into three (somewhat overlapping) roles; Master Builder, Journeyman Builder and Apprentice Builder.
Master Builder. A Master Builder is someone whose skills go across all the phases of the lifecycle. They can do Analysis, Design, Coding and Testing, and have done so in many projects. They will do all four in each project, although their job as teacher, mentor and architect may mean that their work is much more heavily weighted toward the first two than the latter two. Larger projects may have Master Builders that specialize in one or more areas. Just as there are Master Joiners and Master Cabinetmakers, so you may have Master Persistency Framework Builders and Master GUI Builders.
Journeyman Builder. Journeymen have also been involved in many projects, but not as many as a Master Builder. They are still learning the ropes, so to speak of the domain and its subtleties. They may be responsible for small subsystems, or groups of classes. Their work will be more heavily weighted toward the Detailed Design and Coding parts of the development process. They will still participate in the Analysis portions, but perhaps not to the extent of the Master Builder. A key focus of the Journeyman is to gain knowledge and experience in all the different aspects of the domain and implementation. On one project a Journeyman may work most closely with a Master GUI Builder. If that is so then they should work closely with a Master in another area on the next project. This will give them the breadth they need to become Masters in their own right. However, it is in the Journeyman stage that they begin to specialize.
Apprentice Builder. An Apprentice Builder is one who starts out as a relative novice in the technology and must learn how systems are built. They are learning, in most cases, both the domain and the technology at the same time. Their work will be much more heavily weighted toward coding and testing. This is simply because it is difficult to understand the issues involved in the front end unless you have a solid grasp of the back-end issues. However, Apprentices should still be involved in the design process - otherwise they will never be able to learn these skills on their own. It is also useful to expose them to the Analysis process so that they can get a glimpse of the "big picture" of how the system works. This is similar to Coplien's pattern "Apprentice".
Now, how does this apply to staffing the spiral model? Well, we begin by seeding the project with a few (perhaps one) Master Builders and Journeymen. As the spirals progress and the Analysis and Design issues become better understood more Journeymen and Apprentices are added to the project. Finally, in the last few spirals before the first release, specialized Master Builders and Journeyman can be added.
This has been shown to work for years in our own projects at KSC. Our entire Smalltalk Apprentice Program concept is based upon the idea of putting together a Master Builder with a few apprentices on a small, well-bounded problem. In this way apprentices can gain experience across the lifecycle and move on to becoming Journeymen. We have followed this staffing procedure whenever we take on an in-house project as well. In three small projects we have done in-house, we used the following staffing schemes:
| Person Ken Brian Steve Derek |
Role Master Builder Journeyman Journeyman Apprentice |
Specialization GUI, Domain All areas All areas All areas |
| Person Ken Barry Kyle Lynn |
Role Master Builder Journeyman Apprentice Apprentice |
Specialization GUI, Domain Domain Domain GUI |
| Person Mike Kyle Dave Amy |
Role Master Builder Master Builder Journeyman Journeyman |
Specialization Database GUI Domain GUI |
These projects were successful in that they each made their deliverables on time, and within the bounds set for them for cost and functionality. What is interesting about them is the division of labor in the projects - there were no "Analysts" "Designers" or "Programmers", just developers who shared the work along the lines given above. The requirements of each job differed slightly - some were more challenging than others and required more Master or Journeymen programmers than others, but the basic concepts still held true.
Fax Submission Recieved 8/11/96
10 August, 1996
Some thoughts submitted for the People Side of OO Technology workshop of OOPSLA '96
The mountain ahead of you does not slow you down as much as the pebble in your shoe. (American? proverb) This effect has also been seen in engineering projects in general and OO projects in particular (since OO's what I do). Little things can delay or derail a project.
First-time OO projects are still a substantial fraction of our industry. People planning a project usually scope out the magnitude of effort. They often solicit help from consultants and advice from suppliers as to what to expect. They buy computers, chairs, training, mentoring and tools. Many projects add staff. But even if they do all the actions, it is very difficult for someone doing anything for the first time to know what it is supposed to feel like. Once you have learned to ski, you can just feel when your balance is off and make immediate shifts to correct. Remarkable recovery and spectacular crashes are for those skiing beyond their ability. The same is true of projects: teams that know how to do it are almost boring to talk about: nothing exciting happens.
We can almost forgive the participants in a first-time OO project for not noticing a pebble. While the pain of a blister is automatic, the feel of a project pebble is more subtle. At least we can tell stories so that tyros can recognize some pebbles more easily and avoid others entirely.
Focus. A collection of good engineers from different departments of a company were asked to evaluate various tool systems (including Smalltalks). A goal was to form a recommendation for next-generation development. I was called in a week ot two after their first charter meeting and pep-talk to tell them about Smalltalk and to serve as a life-guard while they tried it out. I saw a pebble: each person was still expected to go to their own department's weekly meetings and file progress reports. This meant that the entire group was almost never in the "classroom" at the same time. Things pointed out to some, would be realyed to others later, sometimes accurately, but sometimes distorted, sucking up even more time. To their immense credit (and their managers), they collectively fixed the problem shortly after I offered to issue "Doctor's Excuse" slips.
Scents. One engineer wore too much perfume. It was just thick enough that others did not rush to say "Hey, looky dis" if it meant she'd come close to look. The result was an unreasonable duplication of discovery. Not everyone was even aware of the effect until someone pointed it out. The perfume wearer had no idea. Take-home lesson: be aware of personal scents including perfumes, breath, deodorants. Us consultants can even get away with suggestiong that if anyone needs to take a fart break, they should just leave.
Workplace environment can annoy a few people or almost everyone. Different people like different kinds of work places at different phases of projects. Is there daylight? Private office? Community workroom? Music? What kind? It's hard to exaggerate the pebble-ness of environmental mismatches. If someone really wants to find a quiet place with a 'puter to work, they might acquiesce to sitting in the community workroom, but resent each "noisy" interaction among co-workers. They get little done. It really is the environment's fault. On the other hand, when people want to work together, they don't want to have to phone first, then get up and go away from their own workstations. People should be able to adjust the environment to suit their mood. Some people get medically depressed if kept in the dark too much. My best recommendation is that workers should be involved in the planning, and have continuous opportunities to fix workplace problems. Substantial computer carts can pay for themselves in a hurry if it allows people to work together when they wish, but find privacy with small effort. Perhaps we should look at Alexander's Pattern book for its comments on architecture, too?
Personality conflicts. Some combinations of personalities work, others don't. Observe that it's hard to put together a team that clicks. Isn't it amazing that many corporations fail to take advantage of proven teams, but scatter the staff upon completion? Managers have a serious responsibility to enable people despite conflicts.
Cheap tools. Penny-pinching managers think they can save money buying cheaper. slower computers, smaller screens, and mice with fewer buttons. It costs them every time an engineer has to use both hands to get to their third mouse-button, or works around by closing windows that are not yet obsolete. Time is wasted and concentration lost for lack of such simple techniques as leaving a workspace or message list browser open on one side of the screen. Many people do not even know what they are missing, never having had the "luxury". Is a consultant a rabble-rouser to mention it? Depends on the project and the phase.
External influences. With any luck at all, staff members have outside lives. The secure knowledge that a good secreatary will deal with calls from kids, parents, S.O.s, doctors, etc., and interrupt exactly when appropriate, can be enormously helpful for concentration. Conversely, imagine the disruptive power of one worried member of a skunkworks project. Don't plan to save money by laying off a good secretary.
Fear of the unknown can greatly impede progress for many people. Educators and consultants can help. Managers have an opportunity to screw-up bigtime by pushing for false-precision in schedules and designs.
Rik Fischer Smoody
smOOdynamics
Systems Made Outa Objects
2400 NE 25th, Suite 800
Portland, OR 97212
riks@smOO.com
503-249-8300
Received: 08/21 6:57 AM From: Scott Ambler, Scott_Ambler@wintergroup.com
Abstract: This workshop will compare and contrast the techniques used by developers to learn OT skills on their own, or at least to enhance the training and education programs offered by their organizations. Very often the people who truly make the transition to OT are the ones that put that little extra bit of effort in, the ones that fend for themselves.
Topics will include:
Note: Please refer to the September 1996 issue of Software Development for an article I wrote on learning OO for more details.
Background: I have been working in OT since 1990 in the roles of programmer, analyst, designer, architect, mentor, and trainer. I am author of the books The Object Primer -- The Application Developer's Guide to Object-Orientation (SIGS Books, 1995) and the forthcoming The Object Primer II -- Patterns, Architecture, Design, Coding, and Testing (SIGS Books, December 1996). I write a column for Computing Canada on OT, feature articles for both Software Development and The MicroFocus VisualObject Cobol Developer's Journal on OT, and starting in January will have an OO Design column in Software Development.
Scott Ambler, Senior Object Consultant, Mark Winter & Associates
Norm,
I just heard of your workshop from Luke, and I'm off to Object World West tomorrow so I don't have time to write anything original, but an article I wrote for Object Magazine (February1996) is close to the subject, perhaps it will do as a submission.
| Timothy D. Korson Executive Director Comsoft P.O. Box 3104 Collegedale, TN 37315 |
Email : korson@comsoft.org Voice : (423) 238-3288 Fax : (423) 238-3289 Home : (423) 236-5110 |
I sensed the difference the minute I entered the room. Instead of tailored suits and high heels, these managers were dressed in blue jeans, sweaters, and comfortable shoes. I had just come from a similar meeting at another corporate site with a peer group of managers and the difference in dress was glaring. As the meeting progressed, I found myself consciously noting other cultural differences between the corporate sites and trying to correlate these external culture differences with bottom-line business differences. This analysis was driven, in part, by my past observation of cultural inhibitors to the successful corporate adoption of object technology(OT). Because of these observations, I have become interested in analyzing culture, what it is, how to change it, which aspects of culture are correlated with the successful adoption of object technology, and in particular how to manage and stabilize a corporate culture.
Every culture has its own set of stories, rituals, legends, icons, heroes, accepted behaviors, and defined roles which exert a strong influence on the behavior of the individuals in that culture. My behavior is influenced by Babe Ruth, Paul Bunyan, Davey Crockett, and George Washington. Because of my culture, I have a ritual that I perform on a certain Thursday every November, I don't eat horse meat, and I have an understanding of the role that is expected of me as an American father.
Having experienced other cultures helps me understand the uniqueness of my own and the effect of culture on behavior. When I travel in the USA, it is my habit to eat an early dinner so that I have a longer evening period for uninterrupted work in my hotel room. This ritual is interrupted when I go to Europe because restaurants there usually don't open for dinner till 7:00 pm. After living in France for a year, it became apparent to me that the cultural role of the village bakery in France today is more similar to the role played by the American general store in the 1920s then to the role of a modern American bakery. The details of the complex role played by a village chief were only starting to become apparent to me after living in Zaire for five years. We have no equivalent role in America.
Cultures are not limited to countries and ethnic groups. Anywhere one finds a group of individuals with a shared set of stories, rituals, legends, icons, heroes, accepted behaviors, and defined roles; you have a culture. Some groups take their culture very seriously, and actively try to manage and maintain their culture. The French, for example, spend more time trying to manage their culture than do Americans. The same is true of corporations. For years, IBM was famous for its well defined culture; roles were well defined, employees didn't have to guess as to what behavior was acceptable - you just knew, there were established rituals and icons, and many well circulated legends. As a consultant to many different companies, I observe numerous cultural icons, heroes, and legends related to object technology. One company has a Reuse Rabbi, in another the lead framework architect is known as the Chief Conehead, and yet another has coffee cup classes.
Yes - coffee cup classes. Let me explain. Some corporations have a very exclusive coffee cup culture. Each employee has a personally monogrammed corporate mug, and if you misplace yours, or are a visitor, there will be no caffeine for you. But at this particular site, there are mugs everywhere. Not only are there mugs available, but the coffee is free, and so is the tea, three flavors of hot chocolate, and a variety of other drinks. The mugs all have a corporate logo, but they are not identical. Each seems to have been designed by a different product team and bears the appropriate inscription. No one is assigned to care for the mugs, yet everyone takes care of the mugs. I have seen analysts, designers, testers, and even managers washing out spare mugs and placing them on the drying rack for anyone to use. Visitors often note this friendly coffee cup culture, and the staff seems proud of this local custom. Thus, it seemed quite natural for them to create "coffee cup classes." This has been used as a local icon for a library class, one that anyone can use, and is taken care of by everyone. Yes, there is a proper management structure for these classes, but the importance of the cultural support for these classes, and the value of associating them with a cultural icon, should not be underestimated. I know that "coffee cup classes" sounds tacky to some, and it might not work for your company, but that's the nature of culture. What is accepted in one culture could be tacky or even offensive in another.
Most companies realize that adopting OT represents a paradigm shift, but many fail to realize that sustaining a paradigm shift requires more than training, mentoring, and introducing new processes. Sustaining a paradigm shift requires sustaining a new culture. Written processes, company rules, new compilers and case tools are needed to institutionalize a culture, but they do not constitute or create a culture. A new corporate culture is created only when its employees identify with a new set of stories, rituals, heroes, icons, etc.
Corporations tend to understand how to institutionalize a fledging culture, but they often give little thought on how to manage the introduction of a new culture. Evidence of this can be seen by analyzing the activities that companies assign to their Object Technology Center (OTC). For the past three years I have been closely involved with this corporate phenomenon. Each of these years the Consortium for the Management of emerging Software Technology (Comsoft) has sponsored an OTC workshop at OOPSLA. This column, in fact, has its origins in a break-out session at the most recent OTC workshop. Last year Comsoft hosted the first annual conference (OTC'95) for members of OTCs, and currently a book is being published that contains case studies and summary information for about a dozen OTCs. An analysis of these case studies unfortunately finds few activities specifically aimed at fostering the creation of a new set of stories, rituals, roles, icons, etc.
The creation of a culture used to be a grassroots event with oral stories and traditions handed down from generation to generation, but Madison Avenue and Hollywood have shown us that cultural icons and rituals can be created almost overnight. I am not suggesting that corporations "make up" legends, but rather that they deliberately foster their creation. For example, a corporation can set up a project for overwhelming, legend-like, success by careful choice of the system to be developed, and judicious assignment of personnel to the project. Obviously, not every project can have all the best staff with ample external mentoring support, but your first project can and should be a carefully engineered spectacular success. Add in some deliberate marketing of this success and voila, a legend.
The creation of a written process can help to institutionalize a culture, but the creation of new roles and career paths for employees helps to directly establish a culture. Roles related to an OT culture include project reuse coordinator, repository librarian, prototyper, modeler, pattern harvester, chief framework architect, and application assembler. The more clearly these roles are defined, paired with job titles, and put on business cards, the better they help to establish the desired culture. If the roles happen to acquire a colorful title like Chief Conehead or Reuse Rabbi, so much the better. Latch onto those icons and foster them.
To become a part of a culture, potential cultural artifacts must be widely circulated. Multiple means should be employed for this. Web pages, newsletters, Email, project meeting announcements, hallway bulletin boards, inter-office mail, and word of mouth should all be used.
A sometimes forgotten part of managing the introduction of a new culture is managing the extinction of incompatible pieces of the old culture. Some of the old legends, icons, roles, and rituals must be abandoned. To effect this, not only must policies and procedures relating to the old culture be changed, but the old cultural attitudes must also be extinguished. Custom created cartoons seem especially suited to the task of pointing out the absurdity of certain cultural practices from the old paradigm. Often this happens spontaneously. As I wander the labyrinth of corridors between cubicles in corporation after corporation, I notice the popularity of pinning up mutated cartoons on cubical walls. Dilbert and the Far Side seem to be among the most popular. The mutations are created with a splash or two of white-out and the name of a particular project, process, or local ritual penned in the place of the whited-out text. Why not have an editorial page in your newsletter where the best of these are reprinted and elaborated on in the editorial text. A prize could be offered for submissions that get printed and the collection could adorn a well placed bulletin board next to the coffee pot.
Obviously, cartoons, colorful titles for roles, and legendary success stories do not form the core foundation for success with object technology. Solid technical skills in object-oriented analysis and design, proper management metrics and techniques for controlling iterative, incremental, software development, and a well documented process with a strong quality assurance component are required. But cultural factors are also important.
One of the most successful ways to manage the introduction of OT is to form an OTC charged with both the creation and institutionalization of an OT culture. Details for the successful formation of an OTC can be found in a previous article. Most OTC activities will be focused on the technology itself and related policies, processes and procedures. But a successful OTC will also address cultural factors. Culture is about people. When cultures change, employees may lose rituals and other things that are personally important to them. An OTC should interview employees to determine what they miss about the old culture and then devise ways to make sure that employees understand how they can attain these same values and benefits within the new culture. The OTC should provide an example of the new culture within its own staff, and should train its staff on paradigm shift issues as well as on technology issues. The OTC should insure that the OT training curriculum includes reference to the new cultural legends and icons and that at least one of the instructors is a master story teller. In addition an OTC could create awards and special recognition ceremonies for things like "best pattern of the month."
This column is about managing assets. Your corporate culture is as much a corporate asset as the skill sets of your employees. Employees may have wonderful technical skills, but how will that benefit you if they don't have a work ethic, don't care about reuse, don't support framework development, think modeling is a waste of time, and sabotage efforts to adequately document domain specific patterns. Or, more typically, what if your employees think they are employing modern OO software engineering techniques, but are clinging to incompatible rituals such as awarding a "guru of the month" plaque to the person who has written the most cryptic code.
In future columns, we will explore the management of a number of specific assets, but I also want to motivate you to think about the variety of assets a corporation has that need management. Assets that you directly and specifically pay for come quickly to mind. These include compilers and CASE tools, commercial class libraries, external vendors, and salaried employees. But what about domain specific patterns, corporate processes, culture, and other "soft" intangible assets. It is my contention that the management (or lack of) these assets directly affects the corporate bottom line.
Given the right employees with the right skills, your corporate culture can propel you to success. However, it can also strangle your most gallant efforts. Don't let your culture just happen, manage it.
Received: Mon, 26 Aug 96 16:04:21 PST From: "Thomas J Hadfield" <Tom_Hadfield@SMTPGate.TESSERACT.COM>
Revised: Thu, 26 Sep 1996 22:01:41 -0700 From: "T. J. Hadfield" <76254.154@CompuServe.com>
Tom Hadfield
Director Business Process Modeling
TesserAct Technology
BBA, MBA - The University of Michigan
Object-oriented project management has developed a reputation for being difficult. It is said to be fraught with uncertainties and rife with failure. Executive management is uncomfortable with what appears to be ambiguity caused by incremental and iterative development processes.
Management of object-oriented projects is undeniably different from legacy projects. The differences are attributable to changes in the granularity of work, changes of values and culture, and requirements for increased collaboration. Reduced abstraction transformation between analysis, design and implementation has advantages, but confounds management approaches which rely on clear separation of tasks.
There are many organizational environment factors that can make object-oriented project management troublesome. These factors include organizational patience, project visibility, attitudes toward risk, staffing and management support. [See Ennis, OOPSLA '96 Workshop on 'The People Side of Object-Oriented Technologiesî] Organizational factors are not the only contributing elements. There are additional challenges arising from inappropriate transfer of historical approaches.
People resist change, not the least of which in how they approach work. The degree of resistance is directly proportional to the length of time and degree of success with previous approaches. Changing technology is easy, but changing how people work with is not.
Project teams like familiar approaches that succeeded in the past. A technique's familiarity may even be more important than its track record. As a result, projects often put significant effort into utilizing known techniques, whether or not they have been or are effective.
The ability to recognize successful development techniques from prior approaches is limited. The maturity of procedural development approaches resulted in well-defined body of heuristics. Tactical steps were boiled down to formulaic life-cycle methodologies. Definition of these tactics is exemplified by voluminous methodologies like ìMethod/1î and ASGís ìStructured Development Methodology.î
These methodologies described project plans as tactical enumerations of tasks and sub-tasks. They were inspired when CPU cycles were hard to come by and programming was complex and tedious. This era required large staffs do as much desk work as possible to assure precious machine cycles were not wasted. The methodologies espoused formal, written specifications, division of work and static development plans. The benefits of the iterative approach were to occur on paper. CPU cycles and programming were too costly to use for opportunistic development.
The extensiveness of these methodologies and the process they defined permitted success even if all the tactics did not work well. Teams could get the process ìmostly rightî and still achieve success. The preponderance of known, well-defined steps overshadowed many subtleties. Subtle failures were often masked. There wasnít necessarily an awareness of which techniques were useful and which were not. Nonetheless, there is an irresistible urge to bring these ideas forward.
Adding to this confusion, the definition of tactical steps often eliminated the need for understanding their reason and purpose. It is difficult, therefore, to apply these processes appropriately to radically different situations.
Techniques of the past are often carried forward as if they were relevant:
Mini-waterfalls masquerading as long iterations Microsoft Project® plans detailing tasks and subtasks; micro-managing completion dates for small efforts Extensive separation and specialization of effort Management performing a ìto-do listî checking function Emphasis on extensive written specifications Static plans created at project inception Plan items that can be updated by asking ìIs this done yet?î
Iterative development allows implementation to benefit from discovery. Therefore, everything canít be sufficiently known in advance. A static project plan is simply one that iterates on an excessively large quantum. It changes when performance deviation from plan is so large as to deem the performance a ìfailure.î
Iterative development obsolesces the idea of a project plan that does not vary. Plans must iterate to incorporate the discoveries facilitated by iterative development. Written specifications did not emphasize functionality, they concentrated on procedures and data. When new or changed functionality is discovered during coding or customer exposure, plans need to change.
Tasks remain important, but they are not the primary unit of planning.
Plans need to be strategic, not just tactical. Plans should be organized by delivery of functionality, not tasks implementing procedures and data structures. Strategic plan items are updated by asking: ìIs it doing this yet?î
Another shift from tactical to strategic planning is a shift in emphasis from time/effort estimates to targets. The ability to create task estimates was based on experience. Most object-oriented teams have insufficient experience to create estimates. Targets become the useful planning concept. Targets are something to shoot for and monitor against, but they are not estimates.
Reducing system development practices to heuristics and tactics seemed to allow large team sizes. Teams could divide the written specifications and establish specialization. Teams did not emphasize collaborative approaches or a total system view. Collaboration becomes more difficult with each added resource.
Large teams actually never were efficient or productive, even in previous development paradigms. Successful projects with large teams often succeeded despite team size, not because of it. Yet these successes, along with an outdated notion of management worth proportional to staff size, inspire object development with large teams.
Tactical approaches may have withstood the weight of a large staff. Strategic approaches with collaboration and iteration are crushed by the weight of a large team.
Team composition also needs consideration. Most IT problems solved by procedural systems were technical. It was appropriate and useful to staff projects with strong technicians and the best problem solvers. Today the solutions sought are conceptual as well.
Object technology itself is largely a conceptual leap from traditional approaches. It does not follow that staffing a project with resources with strong technical expertise will guarantee success. Technical and problem-solving resources are helpful, but creative, conceptual thinkers are needed for conceptual issues.
Management often has a feeling of being out of control on an object-oriented project. Progress seems difficult to measure and objectives seem vague. This is largely because management does not understand the OO paradigm or its development process. They are trying to use their old process paradigm to measure the results of a new development paradigm.
Previously, managers frequently kept distance from software development details. Management provided status-checking and resource allocation (especially for corrective action). Most managers' experience made them experts in traditional life-cycle methodologies. It was possible to track the project against a score-card built from known concepts.
Management expects progress and status reported in traditional tactical terms. They may not recognize another approach.
More involvement gives opportunities to understand the technology and appropriate planning and monitoring processes. Progress is not necessarily measured by completion of tactical steps. A hands-on approach facilitates knowledge of status by direct observation. This understanding is multi-dimensional and exceeds any notion of status as reported on planning documents.
Despite efforts to utilize inappropriate ideas from the past, teams often ignore past wisdom useful in an object-oriented paradigm. Some principles of the past are simply dropped when moving to objects.
Perhaps these points were never understood. They may have been important, but they werenít critical, to previous project approaches. The large quantity of other tactics achieved critical mass which allowed success without these principles.
These principles may not have been exercised. If their absence didnít cause failure, there may be no motivation or skill to apply them now.
When managing an object-oriented project everything seems so new teams donít know what to consider. Everything seems overwhelming and known approaches get ignored.
Object orientation changes the unit of work and shifts large work items (e.g., programs, procs) into more granular efforts (e.g., methods, classes). Legacy life-cycle methodologies depended upon identification and tracking of larger ìchunksî of work.
The granularity of work in OO development can make things appear unmanageable. This contributes to the feeling that older techniques might not apply at all. Many people know how control change in a Panvalet program library. Extending a similar discipline to fine-grained items like methods and classes seems impossible. Besides, at the granularity of programs, losing control of a Panvalet library was painful but recoverable. At the granularity of classes and methods, a loss of control could be make recovery impossible. Granularity issues can elevate older disciplines from optional to critical.
Smaller chunks of work make it hard to track completeness and maturity. Things that used to comprise tasks can't be separated; they seem to be happening all at once. Itís difficult to ascertain whether someone with a Smalltalk browser open is doing analysis, design, coding or prototyping. Each of these is achievable in smaller increments. It is possible that all of these tasks may be going on simultaneously.
Since procedural life-cycle approaches donít have a clear fit, itís very important that projects define or adapt a new development process model. Many people have never done this since the heuristics of legacy life-cycle methodologies pre-date their experience. The new process model wonít resemble a legacy one. It should be subject to iterative creation. It will need to be enhanced and expanded during development.
When approaching a new process, it is common to discard things we canít figure out how to apply. Since the reason for steps in legacy approaches wasn't always understood, itís easy to classify them as irrelevant.
As teams get involved in the OO development process, the following items often become casualties. They are important, and must be incorporated into the new process:
During the 1970s and 1980s, system development heuristics were discovered and refined. Several things made the creation of heuristics possible. There were opportunities to repeat procedural development numerous times (during the 1960s) and distill the best practices of successful developers into tactics. Additionally, technology was largely used to address problems which were linear, deterministic and mechanistic. Business demands on systems were not as onerous. Markets were stable and business problems involved optimizing how markets were served. Integrating a variety of systems that mechanized deterministic functions was the challenge. Technical approaches were used to harvest ìthe low-hanging fruit.î
Significant success was achieved applying tactical development steps against businessís tactical problems. System development management became comfortable with a set of procedures and practices that allowed reproducibility, conformity and predictability.
Tactical solutions work well on tactical problems.
The 1990s has brought unprecedented competition to business. Markets change rapidly and international competition expands markets with new ideas and products.
Previously, tactical problems could easily kill a business. A firm that was inefficient collecting receivables, processing payroll or managing inventory was buried alive by competition with no more market edge than efficient operations. Generally, this is no longer the case. Tactical problems have largely been handled or optimized.
Business needs to create new markets and radically re-invent (not just optimize) business processes. Objects are being used for strategic solutions, not just operational problems. Objects themselves are a strategic solution to software development, not just an optimization of a previous approach. The problems confronting business and software development organizations are conceptual and strategic.
Project management techniques do not transcend technology. They track technology and adapt accordingly. No one could have developed information systems of the 1980s with the management used to deploy tabulator solutions. Object-oriented development is a larger paradigm shift than the transition from hardware-manipulation to stored programs.
Object-oriented development processes are not completely refined to heuristics. This may be due to inexperience with the technology. It may be true that objects exist in a more conceptual realm and cannot utilize deterministic solutions.
Most of the problems being attacked with object solutions are more strategic and conceptual. Even operational systems implemented in objects are being approached in conceptual ways designed to transcend business process re-engineering and to elevate previously operational systems to strategic systems.
It is important that an impedance match be achieved when applying management approaches to systems development. Procedural projects can effectively utilize practical and tactical approaches. Object projects address a conceptual space and benefit from conceptual and strategic project management approaches.
Attempts to manage object projects with the tactics of a prior paradigm results in frustration and confusion. Itís easy to determine if a tactical approach is being utilized. If management asks ìIs it done yet?î they are still thinking of tactical steps. If management asks ìIs it doing it yet? they reveal an understanding of conceptual planning.
Tom Hadfield is Director of Business Process Modeling at TesserAct Technology, a software solutions provider for corporate human resource and payroll applications. Previously, Tom was a project manager at Chrysler Corporation. He has spent the past 14 years in human resource and financial systems development and finance management. His experience includes standard mainframe development, information center development, personal computer application support, and client/server solutions using Smalltalk. His current project involves application of object technology to a suit of new distributed human resource applications. Previously he conceived and spearheaded the use of object technology with Chrysler’s payroll systems. Object oriented techniques were used in payroll’s business process redesign and analysis and followed by a Smalltalk implementation. Tom is currently leading a system analysis team building object-oriented application solutions for the human resource domain.
Fax Received Aug 21, 1996
James Vandendorpe
Lucent Technologies
j.e.vandendorpe@flw.lucent.com
Nothing effects the success or failure of a project as much as the people who do the work. Object Oriented start-up projects are especially vulnerable. They often lead experienced programmers from their home in the safe, black-and-white Kansas to a mysterious, technicolor Oz. Measuring OO effectiveness and staff composition over time is a prerequisite to managing this resource.
Within the Oz metaphor, here is a simple pattern for grouping a person's OO skill/preparedness:
A questionnaire can sort people into these general skill groups and it is useful to do so at each phase of the project's life-cycle. Without this timed measure of OO skills, there is no way to effectively manage the team's OO skill development and its relationship to the project's success. By comparing these charts showing the maturation of a project's OO skills with the project's actual timeline, we can begin to understand how OO skill's change during a project and how these skills effect project goals.
The following questionnaire could be used to sort and count skill-set populations at regular development life-cycle intervals:
The team needs to know from the outset that these questions will be part of the development process and how the project will use the answers to assess the team's progress in adopting the OO paradigm. While it is the total numbers in each category over time that is important, individual responses and confidentiality must be considered.
The Toto category is a group of people who either do not understand or do not accept the OO paradigm. Questions 1 and 2 address the former. Question 4 addresses the latter. Since Totos are not productive, the goal is to reduce the Toto number to zero over time. The risk of project failure increases with the number of Toto employees. This is even more evident if the managers are themselves Totos or if the programming language selected accepts code outside the OO paradigm.
Totos mature faster when the reasons for adopting OO are immediately apparent. This can be helped along by establishing a work environment where many of the problem domain questions are already solved by: ORB platforms; OO application frameworks (especially GUI interfaces); and OO Libraries. These reuse solutions along with good OOA/OOD tools and OO courses need to be present at the start-up. It is unrealistic to expect Totos to gain OO advantage if they have to invent the OO world themselves. This isn't Kansas.
Scarecrows have an open mind about the OO paradigm and struggle to adopt it. While learning they often stop programming in procedural ways in order to think exclusively in the OO paradigm. This approach causes them to avoid Jacobson Control Objects and the use of "friend" relations. They tend instead to over-use inheritance, contrive polymorphisms and create too many classes. These mistakes are apparent in Question 4 coupled with zealous answers to Questions 1 and 2. Scarecrows make mistakes and their OO decisions may need to be revisited, but their OO skills develop quickly.
As a group, Scarecrows benefit greatly from experienced OO practitioners in OO design and code reviews. One-on-one design/code reviews by OO experts are the most effective way to develop a Scarecrows OO skills.
Munchkins are at home in the OO world. A Munchkin's job is to recognize when a problem resembles an existing framework or class. Munchkin's modify both the problem and the classes so that existing software can be reused. In successful OO projects, most of the workers evolve into Munchkins as the domains become increasingly well-understood and polished. Question 4 and to some extent Questions 1 and 2 serve to identify Munchkins as people who talk in terms of the existing models.
In the Oz movie analogy, Monkeys happen to work for the wrong witch; were they better employed, the worker value of their high level perspective could have been better appreciated. Monkeys are seen here as the OO architects, domain experts, and designers which every project needs. With Questions 3 and 4 as predictors, this group of generalists is predisposed to see the "big-picture". Monkeys aid the developer community by selecting the OO tool set and/or defining the base domain classes. Because they have this leverage, their decisions are important. Line Managers should either be Monkeys or Wizards. The chemistry and quantity of Monkeys can be a success factor.
Wizards are the systems programmers of the OO community and their code is almost always transparent to application programmers. They traffic in macros, container classes, garbage collection and metaclass issues and may be distinguished by their answers to Question 3. Wizards can fly like Monkeys and often serve in the Flying Monkey/Architect role. A bug within Wizard code, however, can be a project-stopper. Projects that depend on Wizard code have a need to mitigate this risk. On small OO projects and/or projects that begin with a well-defined OO domain, Wizards are not needed, though it never hurts to have a Wizard around. Large projects and projects with strict performance/reliability requirements need Wizards.
People begin new OO projects in various states of preparedness and predispositions to do certain kinds of OO work. The patterns above represent this work-readiness and are a step in assessing OO skills. Management preparedness is arguably a greater issue and can be measured against the same pattern. The correlation of the team's skills over time with the project's measures of success (e.g. schedule, skill development, reuse) is worthy of discussion and research.
Jim Vandendorpe has a PhD in Computer Science and has patents on real-time garbage collection techniques and fault tolerant computing. For the last fifteen years Jim has worked for Lucent Technologies where he has alternated between being an OO Architect and an OO Project Manager. Prior to this Jim was a professor of Computer Science and a consultant.
Fax Received Aug 20, 1996
Recieved: Thu, 19 Sep 1996 19:42:38 -0500 From: brr@mcs.com (Bindu Rama
Rao)
Bindu Rama Rao
Integrated Solutions
brr@mcs.com
The introduction of object-oriented technology into organizations that have traditionally employed structured programming approaches requires the deployment of newer OO processes. The rate of education of the development teams far outstrips the competence of the management, especially when the management is ill prepared to handle OO projects. The evolutionary changes adopted by the development teams eventually results in reorganizations, with or without the pro-active leadership of the management.
With unprepared project management and newly assembled development teams, evolutionary changes are followed by traumatic reorganizations.
When employing a new paradigm for a project, the management, if untrained in the new paradigm, falls far behind the developers in their understanding of the state of the project and in their comprehension of the complexities involved and the problems faced. This is further exacerbated by their inability to communicate in the new vocabulary. The development teams continue to make progress in their mastery of the paradigm and eventually their concerns and the communication problems with the management leads to the reorganization of the organization.
Received: 08/27 4:51 PM From: mpl@cmprime.att.com
> I can live with a "day or so late." Thanks for the warning.
OK, so I lied. It's been much more than a day, and the paper underwent substantial "toning down" to get it releasable, but Paul tells me you may still have spots in the workshop, so if you can forgive our extreme tardiness....
Do you want bios for all of us?
-- Mike Lindner mikel@attmail.com (908) 576-2017
by Nancy Lewis, LoAnn Lindner and Michael Lindner
Several years ago we were invited to join a new project. There were about a dozen people all ready working on the project, which was to develop a large scale consumer-oriented proprietary e-mail system. The major features, for us, were not the technology, but the people side of things. Some of the best people we had worked with were on the new project. The new project was being organized as small self-managed teams supported by a single department head. The title of supervisor was to be merely a title, and neither the supervisors nor the department head were to have technical decision making power above that of any other person working an issue.
In addition, there was to be no notion of AT&T's traditional performance evaluation, ranking, and salary administration. Instead, you were reviewed by your peers, the information was private, and salary was simply a matter of taking the budget and doing some arithmetic.
Due to the radical departures from the norm, the project attracted many of the best minds from the surrounding organizations. One of the biggest attractors was the development methodology. The new project promised to let the developers plan and implement whatever methodology they deemed best.
The organization spent quite a bit of time up front examining different development methodologies, and chose Shlaer-Mellor, supported by the Teamwork CASE tool, with C++ as the target language. The decision was made by concensus, based mostly on the degree of training and tools available at the time.
Time was taken to ensure that every developer on the project had training in OO concepts, the Shlaer-Mellor methodology, our development process, and C++. Several consultants were brought in one or more days a week to provide a place to go for answers during any phase of development.
The project was completed successfully in more time than was in the schedule, but less time than most people actually thought it would take. Although technically a success, the project failed to be as popular as predicted at its start, and did not generate much revenue. It went into "maintenance" mode.
This project was successful in creating and maintaining an environment where object-oriented technology could be adopted and used. The key to this success was creating an environment where new technology could be evaluated based on its merits, and responsibility for decision-making was shared.
This is in contrast to other projects we have worked on, where object-oriented technology has been used with less success. In these situations, technology is evaluated and chosen for political reasons, and the responsibility (or blame) for decisions is a political football, passed around based on short-term perception of success or failure.
Ultimately, such behavior resulted in the loss of key expertise in object-oriented technologies, as developers versed in this technology were attracted to projects on which they have more control over the technical aspects.
It is our belief that one of the key aspects to developing and maintaining object-oriented technology is providing an environment that nurtures the type of people who will foster such technology. One way to do that is to provide an atmosphere where people have empowerment in the real sense of the word. When people are allowed and encouraged to make decisions and take risk, the organization will attract the type of people who are willing to try new techonologies and are able to manage and use these technologiess.
Received: Wed, 25 Sep 1996 09:40:37 -0700 Via: "T. J. Hadfield" <76254.154@CompuServe.com>
Alexis Ennis
An organization chart does not in any sense capture how an organization actually runs. Real business problems are not mechanistic, but are the result of a system of interactions, a process of subtle forces, counter-forces which create specific results.
In 1968, Conway discovered that a system will tend to have a structure that mirrors the structure--or management style--of the group producing it, whether or not this architectural duplication was desired. The organizational model used by many high-technology companies today have their inspiration in organizations like the military, government, and turn-of-the-century auto companies. These organizations have developed cultures emphasizing linear and hierarchical thought processes and management practices exemplified by ìchains of command.î
The thoughts and activities of individuals in the OO project are inevitably affected by the organizational structure, cultural norms, management practices and thought processes of the organizational environment. The norms and practices of most organizations are mechanistic. This permits close measurement, facilitates reproducible results, and promotes conformity.
Today's businesses face more complexity and require more robust, dynamic, flexible business and development environments than businesses did years ago. The traditional mechanistic, linear, command-and-control product development organization is too static, slow and inefficient. For example, six month release increments are not unusual today. Therefore, successful OO development environments and teams should be increasingly self-directed and less dependent on the management practices and protocols of traditional, hierarchical organizations.
Many high-tech companies are unwittingly handicapping their product development efforts by managing in very traditional monolithic, hierarchical ways. These companies are reaping what they sow. Relying heavily upon traditional chains-of-command results in slow decision making and information sharing and stifles creative product development. Companies ask for creativity, innovation, and risk-taking from development teams, yet management behaviors perpetuate conformity and me-to products.
Highly successful development teams are flexible, creative, lean, responsive to cues, proactive and self-correcting. They also have a partnership their customers and an effective management team. Ideally, they exist in organizations that exhibit these characteristics as well. Of course, this is not going to be the case for all organizations undertaking OO development.
Individuals do not naturally think in mechanisticly or linearly. People think in patterns and utilize many parallel processes.
Peopleís natural thought processes capture subtle nuances and create a holistic perception of reality. Both right and left brain activities combine to create a balanced model of the world.
Objects have a basis in cognitive research and, as such, have a closer mapping to individual thought processes than linear, procedural programming. Linear, procedural programming styles appear to reflect the concept that businesses run by deterministic processes. Business environments are composed of many systemic variables too subtle to be reduced to heuristics. Business problems are rarely deterministic.
To the extent that objects are used to model business problems, they have potential to capture systemic solutions and model a holistic environment.
Enhancing an organization's ability to effectively utilize objects requires understanding and utilizing the organizational meta-system. The organizational meta-system is comprised of:
In a manner similar to object-oriented systems, organizational behavior is concentrated in entities which have information and interact with each other.
The organizational scan is used to define the heuristics of the organizational system. The results are similar to an object-oriented model, but not as deterministic.
The organizational scan allows definition of the organizational context by:
The behavioral entities include internal and external forces as well as company characteristics.
Organizational culture is an additional entity that participates in this interaction. Organizational culture is defined by the organization's norms and values; "The way things are done around here."
The desired state is described by appropriate interactions of the behavioral entities. The optimum set of conditions for any organization to be successful is unique to that organization and the forces present within it. In the case of object-oriented development, a key characterization is the use of systemic and holistic approaches. However, the entire organizational context needs to be considered.
Comparing the results of the organizational scan to the desired state produces a gap analysis. Determination of root causes is an important component of this analysis. The behavioral entities may be re-enforcing undesirable behaviors. The gap analysis is used to determine a set of prescriptives which can be used to course-correct to the desired state.
The current state can be changed by determining and implementing a specific set of prescriptives, i.e., actions and interventions. Many text-book solutions are available that embrace a particular technique or approach. Simplistic solutions are not the answer. The behavioral interactions are extensive. Changing any of the subtle forces that determine the organizational context creates new interactions which must be considered. As with objects, the elements of the organizational context can participate in a wide variety of collaborations.
A change in organizational forces can be facilitated by determining business, organizational and people practices re-enforcing undesirable behavior. This is followed by a determination of actions and modifications that will reinforce creativity and holistic thinking.
There are specific skills required to manage the organizational meta-system. These skills include an organizational sensitivity and awareness that can only be achieved through years of dedicated practice. The application of a prescriptive results in a new organizational state. This new state must be monitored for new desirable and undesirable interactions that are occurring. The gap analysis must be performed again and the entire meta-system must be re-evaluated.
Behavioral mentoring is a powerful tool that can get individual thinking in synch with holistic, object-oriented thinking. The mentoring and iterative development approaches considered essential for object-oriented development are equally valid approachs for individual and team effectiveness.
Team development happens incrementally, day-to-day. Team effectiveness develops most quickly when supportive, behavioral interventions are done real-time, on-line. Building an effective development team is a constant process, not a set of discrete events. Organizational development needs to be executed continuously and cannot be achieved by a series of developmental events.
OO mentoring is considered the best approach for creating object-oriented developers. It is an equally appropriate approach for re-enforcing holistic behaviors and synergies. Cookbook approaches and classes will not work. Behavioral changes deal with subtleties and undercurrents which are not readily visible in short observations.
Whether implementing OO in a start-up environment or transitioning an existing organization from another technique, specialized skills can be useful in helping deal with change.
Self-directed, autonomous work teams are the road to success. The objective of object-oriented systems is to achieve collaborative, cohesive and modular software. We can infer from Conway's research that the best way to achieve this is with collaborative, cohesive and holistic teams.
Creating cohesiveness and productivity depends upon understanding the goals of the development team and fostering alignment of the team and individual capabilities with those goals.
Mentoring organizational behavior is key to successfully creating the appropriate team environment and organizational context for object-oriented development.
Alexis Ennis, Consultant Ennis Consulting Services, Palo Alto, CA
M.A., Psychology. Emphasis: Organizational Development, Santa Clara B.S., Business, University of Idaho
Alexis Ennis is an organizational development consultant specializing in high-technology companies. Alexis has 15 years experience developing and mentoring high performance product development teams. She has been a key organizational strategist for businesses transitioning to object-oriented development.
As Senior Director of Apple University, Alexis began her career mentoring technology managers and teams during the innovative product development times at Apple Computer in the 1980's. She has developed a special expertise in building the team attributes, cultural norms and the leadership behaviors required by high-performing development teams. Alexis has worked with such companies as Intel, 3-Com, Tandem, and National Semiconductor.
Alexis is known for her pragmatic, straight-forward solutions to the people and team issues which are often inherent in dynamic product development environments. In this effort she has worked with such individuals as Peter Senge, Tom Peters, Rosabeth Moss Kantor, Steven Wheelwright to develop practical, accessible and successful solutions to the issues facing them in their day-to-day operations.
Alexis has found that object-oriented development's focus on creativity, modeling and iterative development places and new and different demands on development teams. Object-orientation's more holistic approach to the analysis, design and implementation cycle offers increased benefit, and opportunity as well as challenges for collaborative work arrangements. Alexis has a keen interest in the issues confronting object developers and "traditional" developers making the transition to a more entrepreneurial and integrated development style.
Sent: Tuesday, September 10, 1996 3:51 AM From: Marykay Wells
Revised: Mon, 30 Sep 1996 19:41:50 +0000 From: MARYKAY WELLS <Marykay.Wells.0201420@nt.com>
Marykay Wells
Nortel
marykay.wells@nt.com
Northern Telecom (Nortel) is a preferred global resource for designing, building and integrating dynamically evolving information, entertainment and communications networks.
In order to effectively introduce and transition object-oriented technology into Nortel, the Nortel Object Center was established. The Object Center facilitates the implementation by providing solutions delivery teams with a formal development process which includes a fully-supported development environment. Services provided by the Object Center include training, mentoring, object modeling, life-cycle and process expertise, technical and process support, and custom delivery of reusable frameworks. In addition, the Object Center manages an Object Corporate Reuse Library (OCRL) which is a repository of certified and classified reusable assets intended to provide development teams with time-saving building blocks for software development.
There are many ways for an organization to introduce and gain acceptance of implementing object technology (OT). Many organizations receive an executive mandate to use the technology and don't concern themselves with how this will effect the people and organizations (i.e. "grass-roots) that are accountable for the mandate. It is essential for an Object Technology Center (OTC) not to assume that executive sponsorship is sufficient for a successful transition of this technology. Even though an executive might be behind the move, you can count on some resistance from the "grass-roots". The benefits of using OT must be explained and presented as an opportunity with exciting new challenges rather than a threat to one's position. Undoubtedly, most software developers will not be motivated by fear but many will be excited for an opportunity to learn the highly marketable skills of OT.
At the onset, it's also essential to present a business case which explains the costs involved in moving to the new technology. This must include the costs, and the measurable benefits, of using the technology. It is highly inadvisable for an organization to expend a sizable amount of money on OT without being able to demonstrate it's worth to the corporation. Any attempt to "cover up" the costs will be quickly detected and exposed. It's better to be prepared with a justifiable business case.
After the various organizations have accepted object technology, expectations of OT can run rampant. Developers immediately begin to associate OT with reuse, reduced delivery cycles and guaranteed project successes. It is important for an OTC to manage these rising expectations by communicating that success may be noticeable only after the infrastructure has been established and the learning curve completed. Generally, a development team needs a few object technology projects under its belt before any reduction in delivery time is noticed.
Reuse impacts multiple software development projects and therefore requires a long-term investment and executive management readiness. No single development organization wants to pay for reuse but every project wants to benefit from it. Corporate funding should be provided for a reuse initiative so individual projects will not be straddled with the high costs. Additionally, it is essential that the corporation instill, and propagate, a reuse mindset. This organizational initiative needs to be established in order to support, manage and direct the reuse process of acquisition, use and maintenance.
Although a primary function of most OTC's is to train and mentor development organizations in OT, it is unrealistic to assume that all software developers will successfully make the transition. A few common roadblocks exist that can prevent an expeditious transition. First, developers that have mastered established tools (e.g. COBOL, Assembler, etc.) are reluctant to give up their leadership. Second, some developers have more difficulty in transitioning to new technologies. Mastering one technology does not necessarily mean that an individual will become equally proficient in another. It is very difficult to predict how each individual will handle the change and make the transition but it is common to expect that only one-half of the developers will be successful. An OTC must work with project managers to plan and incorporate this risk into project schedules.
OT offers many potential benefits but the very characteristics and techniques that make it effective also add a complexity to the management of projects. It is important for the project manager to understand the differences of managing an object-oriented project. Like software developers, project managers should receive formal training and mentoring when making the transition to OT. In making this transition, Project Managers should also be educated on when to and when not to use the technology. There are some software development situations that simply do not make sense for OT or any other new technology for that matter. A key aspect to remember is that if you are taking on this technology for the first time or are relatively new to it, it is important to start small and avoid mission-critical projects. It is also essential to make sure that a project is seeded with the proper experience and trained staff.
Once you have the experienced staff it is important to motivate, recognize and reward team members in order to minimize employee turnover. Valuable team members are not easily replaced and experience in the practical aspects of object-oriented software development does not develop within a short period of time. Some simple ways of motivating team members include; giving them time to pursue areas of interest in OT, making sure that they are successful in their endeavors, compensating them fairly, and making their job fun.
As the number of OT projects grow in a company, it is helpful for an OTC to set up a common forum so that project managers can share ideas and experiences. This also serves as a support group. An OTC can also gain learning from this forum.
The insertion of OT into an organization is not without some discomfort to the people expecting to make the transition. Object-oriented technology is new in many aspects (new terms, training and development processes). In planning the transition it is important not to forget the "people aspects" of the change if you expect to succeed.
Received: 09/08 7:20 AM From: Hendley, Greg, ghendley@ksccary.com
The wild OO frontier has been tamed and the later settlers are arriving. The trail blazers and first settlers brought with them an expectation that anything is possible. With this expectation they have been able to appreciate the wild beauty of OO. In this appreciation they have listened to the frontier and learned to use it in uniquely OO ways.
Now the later settlers are coming and with them their old ways of life. Some have come to see this wild frontier for them selves. Some have come for the financial opportunity the frontier provides. Others have come as they have to every place their company needed them. They come to set up shop, provide needed law and order and make OO productive for the many. In the process will they continue to tame OO to fit their ways till OO programming is indistinguishable from the past? Or, will t hey adapt themselves too so that the unique wild beauty of OO enriches the way all other programming is done? Recognizing and managing the different attitudes of the trail blazers/first settlers and the later settlers will help preserve the beauty of OO even as it is tamed.
Much of the benefit of object-oriented programming and Smalltalk in particular has been in the joy of its use. The accelerated pace of development, the use of a spiral model with constant maintenance, and the potential for reuse have all contributed to th e joy. Much attention has been spent on the affect of corporate culture and how it affects the success of OO and the realization its promise. Agreed, corporate culture one is in affects the way one uses OO. I would like to add that one’s o wn culture (perhaps internalized corporate culture that one has come from) also affects one’s use of OO. The Wild Frontier and its People
In the wild frontier of Smalltalk there were a few books and almost no paper documentation. Everything was in the browsers. The only real way to find your way around was to dive in and start browsing. Finding ways to develop applications and model domains was a lot like blazing trails. Like most trail blazers and early settlers early object oriented programmers had to be self sufficient. Each programmer had to design, implement and test their own applications.
In the wild frontier the only law that existed was the law they created. Object oriented programming was a new way of doing things and the trail blazers and early settlers argued well that old rules as they stood should not apply. Some of these rules incl uded disciplined code and design reviews, the way milestones are set and many other rules necessary for conventional large scale software development. This provided the freedom needed to explore this new technology.
In the settling of the wild OO frontier the trail blazers and first settlers have gained experience. Style guides, pattern languages, cookbooks and documented frameworks are the codification of much of this new experience. The Settled Frontier and its People With the settling and increased experience other less adventurous types have decided it is safe enough to set up shop. So the later settlers arrive and begin using object oriented programming for every-day uses.
At times the frontier still has the feel that anything is possible. But now some things are more likely than others. IS departments using Smalltalk are still writing the IS applications that service their business. The sheer volume of these standard types of applications gives the appearance of there being standard ways of doing OO programming.
These later settlers have established ways of doing thing and established roles. There are architects and designers who design applications . There are programmers whose job is to do the initial implementation of the applications. There are yet another set of programmers whose sole job is to maintain applications. Much of the programming is routine. So much so that cut-and-paste is the most common method of programming. Often there are already code generators to do the routine cut-and-paste programming. If not, the routine of repetitive coding is comfortable.
The Effect of Settling on the OO Frontier & Maintaining its Benefits Much of what the later settlers bring to the OO frontier is the patience, persistence and attention to detail needed for large scale development, enterprise wide reuse and the creation of design and code that will be maintainable for years to come. This is a patience and maturity often not required to be a trail blazer or early settler. Maturity can (although not necessarily) bring with it a resistance to change. An application developer when faced with repetitive coding may spend time cutting and pasting instead of writing a tool to generate the repetitive code for him. Where the early settler knows they have only themselves to rely on the later settler knows it is another group’s job to write tools.
I would recommend that extra time be spent training the later settlers not only to use inheritance to avoid cut&paste programming, but to regularly write tools to generate code where inheritance can not be applied. When faced with such a large body of knowledge (style guides, pattern languages, cookbooks) later settlers may get the perception that all of the innovation has been done. And, much of it has been done for the simple or commonly used classes. This perception can prevent the later settlers from attempting the innovation necessary to cleanly model their own domain. Aga in, additional time should be spent making sure the later settlers know that innovation in their own domain is necessary and that they have their own frontier to explore.
Some later settlers (but by no means all) tend to stick to their old assigned duties. Architects architect, designers design, coders code and testers test. The benefits of specialization are not argued here. But a reminder is needed for these later settlers that a little architecting, designing, coding and testing is required of each and e very role. The trail blazers and early settlers had no problem with this since they had to be self reliant. Some later settlers need to be reminded to validate their architectures and designs by using code. Not all of the coding details will be designed in advance and will have to be designed by the coders. Testing needs to be done as the coding is done. Also, testers may want to design and write their own testing code.
The benefits realized in the early days of the OO frontier do not have to be lost as the later settlers arrive. They bring with them the maturity and patience to make object oriented programming productive for the programming population at large. By takin g the time to emphasize the creativity and flexibility of object oriented programming the later settlers may add to these characteristics rather than overrunning them.
Greg Hendley is a Senior Member of the Technical Staff at Knowledge Systems Corporation in Cary, North Carolina. His eight years of experience in the Smalltalk frontier has been an even mix of design, development, mentoring, teaching Smalltalk Apprenti ce Programs and Practicums. He has applied his skills to custom graphics, knowledge representation, telecom, workflow and order processing. Prior to working in Smalltalk he worked for the US Navy specifying and testing flight simulator real-time computer graphics systems: a continuously new frontier within an established process.
Revised : Wed, 25 Sep 96 16:12:00 C Via: Luke Hohmann <lhohmann@msmail.objectspace.com>
George W. Heyworth
Director of Technical Training
Perot Systems Corporation
My brief paper highlights a serious education and training challenge, previews an evolving, new education and training model, summarizes Perot Systems’ strategy to meet this challenge, and lastly identifies may key factors that affect the human side of training software engineers.
It is evident that rapidly changing technologies are spurring radical reconfigurations in many American Institutions to include our entire formal educational system. To one degree or another, institutions of higher education are scrambling to protect turf, reinvent the educational process, or fighting off industry’s charges that (1) the process is inefficiently lengthy, (2) costly, and (3) to make matters worse misses the target—does not properly train our emerging software engineering talent.
Industry must accept the challenge of reshaping the learning process and will do so because capitalism “the power of performance” is the crucible for change. I submit that industry will drive this change through the following vehicles:
CULTURAL change -- the need for continuous learning. The newly emerging market place, fueled by rapidly changing technology, now requires each of us to learn how to manage change. We acknowledge that continual learning is paramount to the professional tribe with which we choose to join.
INTENSIVE COMPETION. Competition is driving (1) experimentation and early adoption and (2) the ability to quickly get to the bottom line.
FINANCIAL INVESTMENT tied to survival. Industry is consciously refine its processes, attempting to reduce cycle time, and more recently shorten the distance between consumers and producers. Businesses are investing billions in new solutions that seek to capitalize on technology driven process changes that seek to reshape even the traditional commerce value chain.
CREATIVITY. Competition requires industry to explore, propose new solutions, try new technology, constantly search for the quicker, cheaper, better solution. It is this creativity which the rapid transfer of technology from one business sector to the next.
The stage (culture, competition, investment, and creativity) is set for industry to demand and mature a new learning model—Learning on Demand (LOD). This model integrates newly emerging delivery technologies, infinite sources of information, and advanced authoring. In short it seeks to put the non threatened leaner (customer and in some cases the co-producer) closer to the producer (best practice, mentor/teacher, process, standard, and knowledge base). SRI Consulting is formulating a concept paper Titled “Learning on Demand: The Next Frontier in Building Competitive Advantage.” We must look to industry to refine the need, resource, and creatively adopt solutions. Most importantly we are asking industry to foster a cultural change that acknowledges the need for continual training. The training and education requirements for organizational “Object Adoption” serves to amplify industry’s challenge.
Technical Training Group has the requirement to broker training opportunities to three distinct customer types— (1) initial full immersion training to acquire a fundamental competency in a discipline, (2) the just-in-time short burst opportunities to adapt new technology, and (3) the requirement for readily available knowledge for refreshing. Perot Systems is evolving three levels of training very focused on the LOD concept.
Level I -- Career Oriented Required Education (CORE). CORE programs support vertical and horizontal business needs by providing a platform to train our associates in multiple technologies. These programs focus on the fundamental disciplines and core competencies needed to keep Perot Systems engineers in the forefront of technology. CORE programs are intensive, full immersion instructor led, multi-week sessions. Each CORE program provides the Associate with the requisite training needed to pursue a technical career path. Programs include; key technologies, the methods and processes to successfully use these technologies, and fundamental project management. The model for all CORE programs has been the CORE OO. Key to immersion is the recognition that fundamentally object adoption requires a technology transfer (example C++ language training); learning OO Requirements / Analysis and Design; and mentored project work utilizing all facets of the software development process. This training program stresses the understanding of fundamentally diverse concepts. This is precisely why that successful object adoption is full immersion. Many believe that these sub-components should be separated and for resourcing reasons taken a week here and a week three. Other organizations move the students directly into the fast lane developing production systems the week after course completion. In the final analysis, the only chance for success in each of these scenarios is time and mentoring. Without mentoring and time for the learning by doing, the learning process is ultimately lengthened and significantly stifled by large doses of failure.
The OO CORE program trains tomorrow’s architects and due to the pace we have an intensive screening process. Generally, recent college graduates have an edge in the technology transfer component and seasoned legacy programmers have an edge in fundamental life cycle software development and key under lining technologies such database, transaction processing, or communication protocols.
Level II -- Continuous Training (Computer Based Training (CBT) & Instructor Lead Training (ILT)). The focus at Level II is on Continuous Learner Centered Training. Today’s technical environment is very complex, requiring mastery in many different technologies as well as roles. Today, we are asking associates to work on systems implemented on multiple hardware platforms, networks, and database management systems. Standards, languages, and development tools are constantly evolving and changing. To meet this challenge, we are providing associates with media-based, self paced, multi-vendor focused training. Our goal is to be able to deliver this type of training on demand anywhere, any time. In the OT arena, we are assuming a fundamental grasp of object technology. We would be using CBT to conduct the initial technology transfer to say rapidly learn the Java language.
Level III -- Special Events -- (Visiting Professor & Cooperative Education). Special Events constitute those strategic opportunities to grow our technical capabilities by taking advantage of recognized industry and academia programs. Examples include adding an advanced technology course expert to PSC’s Technical Education Staff to mentor and bring the latest in OO technology transfer. Again, in OT we will focus on critical advanced topics such as distributed computing, object databases, and transaction processing.
Many factors affect successful implementation. Examples include:
George Heyworth recently assumed leadership of PSC’s Technical Training Organization as PSC seeks to rapildy move into the Netcentric and Object Technology development arenas. He currently oversees a training budget of over $8,000,000. Earlier this year he transitioned the advanced technology team – object technology focused -- team into PSC newly formed Global Software Development Organization. The GSD is chartered to operationally meet PSC needs in the areas of Object Technologies, Reuse, and Networkcentric computing. This past spring he lead a $3,000,000 project to re-engineer a healthcare solution into a flexible, scalable, distributed architecture.
Prior to this, Mr. Heyworth managed PSC internal software development/delivery capability (International PeopleSoft HR/Financial Implementation, Operations, Advanced Technology, strategic vendor partnering, and Applied Technology). Mr Heyworth lead the General Analysis and Design Phase of MCI’s Strategic Billing Reengineering $35, 000,0000 effort that culminated with an object technology solution.
Prior to joining Perot Systems Corporation, he was Chief Software Engineer for NASA’s Space Station Trainer--responsible for software development methodologies and supporting processes and procedures. He received NASA’s award to technology innovation for the authoring of what is called the Iterative / Incremental Software Development Methodology.
Mr. Heyworth has course directed and taught computer science courses at the University of Oregon, West Point, and the University of Houston. He received a Bachelors degree in Civil Engineering from the United States Military Academy and a Masters in Computer Science at the University of Oregon.
(Norm Kerth has suggested that the conference organizers also submit position statements.)
Recieved: Sun, 22 Sep 96 From: Luke Hohmann <lhohmann@msmail.objectspace.com>
Luke Hohmann
ObjectSpace, Inc.
I recently co-taught a class on building user interfaces using Microsoft Visual C++ and the Microsoft Foundation Class (MFC) libraries. My partner was responsible for teaching the technical part of the class. I was responsible for teaching the human factors part of the class. Our collective goal was to capitalize on our respective areas of expertise. My personal goal was to refresh myself on the technical aspects of MFC (I’d built systems using MFC 1.0 and MSVC++ 1.5, but that was a “long” time ago). I also wanted to get my hands dirty, and see what it was like to be a student once again. This paper reports my experiences as a student in this class who was involved in refreshing a given technology, and poses more general questions relevant to all who wish to get past the technology and on to problem solving.
Technically, the MFC class libraries motivate the developer to violate many of the principles that characterize well-designed multi-tier application architectures. As a simple example, developers are encouraged to embed data validation logic in the user interface or the application management layers instead of the domain model. This leaves us with a dilemma: Do we teach the students the MFC way and then show them a more pure approach or do just simply teach the pure approach right from the start.
In this class we decided to teach the MFC way and then show them a more “pure” and object-oriented approach. In general we had good results, mostly because this class was taught as the fifth week of an eight week immersion program, and the previous four weeks had been spent focusing on the importance of good system design in the context of objects.
Unfortunately, I am confident of two things. First, unless a student had a firm understanding of the importance of multi-tier architectures this approach would be ineffective. It is too easy to do such things as embed domain logic in an MFC user interface—with poorly architected systems as a result! Second, I am unaware of any other training vendors who take this approach. Indeed, in our informal survey of other vendors product offerings, most begin their MFC class with a discussion of device contexts and how to override WM_PAINT (or some-such nonsense). Such an approach provides little value to the developer whose dominant task will be creating (primarily) form-centric business applications.
We cannot avoid this issue! Every OO system I know of has had to deal with non-OO problems. It might be a RDBMS. It might be converting an incoming sequence of data packets into a set of domain objects. It might connecting to legacy code that represents too much of an investment to rewrite in the future. The question is this: How can we ensure that OO systems are, well, OO systems, when so much of our existing structures are inherently non-OO?
During our immersion program we teach the use of several different kinds of patterns, concentrating on the GoF design patterns, the GRASP patterns of Craig Larman, and the Crossing Chasms patterns of Kyle Brown.
As I’ve watched students struggle as they learn how to apply patterns I’ve been struck by how much knowledge is embedded in a pattern. Quite simply, there is a far greater amount of knowledge embedded in a pattern than many of us realize. Moreover, much of this knowledge is quite subtle. Learning the basics of Abstract Factory and Factory Method are relatively easy, especially if you take the time to read the patterns book. Learning to apply them appropriately and effectively in a real production environment is far harder and can take months (if not years) of work to do easily.
When patterns are misapplied, the results are often quite detrimental. How can we ensure that those adopting patterns can the critical thinking skills so necessary for success? In related issues, I fear that novices may not have the experience (wisdom?) to differentiate between “good” patterns and “bad” patterns. Alternatively, how do we prevent becoming lost in pattern space?
Over the past two years I’ve spent my time teaching and managing, but not really developing. Certainly, when you teach, your coding skills stay current, but they stay current in a very limited domain: The domain covered by the class. You know what problems to expect, and have internalized a variety of ways to solve them (and at the same time explain your solution to a student so they can learn and grow at the same time). And, I’ve been teaching more Smalltalk than C++, further contributing to the problem or “rusty” C++.
As I was taking the class, I made several novice mistakes. I sometimes forgot my semi-colon after the end of class definitions (or is it declaration?) and suffered through the usual onslaught of incomprehensible compiler messages. I separated the implementation of my template classes just like my domain classes and forget one of the cardinal rules of templates: Don’t do that! I played with various compile/build options until I could get a “project database” created. (For Smalltalkers who don’t know C++, a project database enables you to select a method and track down its senders. Yes, I know it is built into Smalltalk, but I don’t want to start a language wars discussion here. It is not productive to our mutual goals). I tried to modify source code while the program was running (like I can do in Smalltalk), but forgot that I couldn’t do that in C++.
Of course, Smalltalk is not immune to the syntax problem (although C++ has a worse case of the disease). Developers with experience in traditional languages find the Smalltalk syntax of unary, binary, and keyword quite confusing until they “get” it.
You may be thinking these are just my idiosyncratic mistakes because I have the good fortune (or terrible curse) to know more than one OO language. And yes, each time I was able to track down the mistake and correct it fairly quickly. But, the sum total of the amount of time it took to correct even these minor mistakes was astonishing. Keep this in mind: Every time I was thinking about syntax I was not thinking about objects, their proper structure and relationships, or the application architecture I was so carefully constructing. And every time I’m not thinking about objects I am drawn into thinking about my system in my old patterns of thought.
After each mistake all I could think of was this: If I am having this much trouble with something I know, then what of my students? How can they possibly focus on this issues of good object-oriented design, good coding style, and proper application architectures when they must battle the syntax beast on every compile? Are the tools (which are structures) we give appropriate? Are we giving power tools to adolescents? How can we as educators and mentors craft learning experiences that enables our students to get past the syntax and think objects?
The focus of this paper has been two-fold. First, it has identified some of the structural impediments to building well-designed object-oriented systems. Second, it has outlined some of the problems novices face in learning how to craft such systems. We know that adopting OT is hard. Sometimes I fear that we forget just how hard it can be.
LUKE HOHMANN is a senior object technologist at ObjectSpace, Inc.. He has taught object-oriented technology and software engineering management for companies such as Sprint, Kodak, E-Systems, Ernst & Young, and Bell-Atlantic. From 1985 to 1993, he worked at several positions for Electronic Data Systems, including Vice President of Systems Engineering at EDS Fleet Services. From 1988 to 1992, he was also a member of the Highly Interactive Computing Environments (Hi-CE) research group led by Elliot Soloway, Ph.D., at the University of Michigan, where among other projects, he designed programming environments to help novice developers learn design skills. He is author of the book Journey of the Software Professional and has published articles in JOOP and American Programmer. He can be reached via http://members.aol.com/lhohmann.
Received: 10/01 7:59 AM From: terrence (t.c.) cherry, tccherry@nortel.ca
Terrence C. Cherry
Nortel
This document presents a personal view of a number of people realted issues in building object oriented frameworks based upon personal experience. In no way is it meant to reflect official Nortel policy.
In late 1990, Nortel launched a large and rather ambitious initiative whereby the the call processing base software for its digital switching products would be re-engineered and enhanced using object oriented technology. The project grew from 6 people to several hundred over a number of years.
In traditional SASD methodologies, a typical designer would be responsible for implementing all the software required to deliver some specific functionality. This frequently entails the modification of existing software not owned by the designer himself; where this is difficult or impossible, the designer often simply clones the required functionality. The fact that the designer exercises overwhemling control over his software means that there are minimal dependencies on others. The need for teamwork is decreased since the work is encapsulated within individual designers.
Such is not the case in OO methodologies, where a designer is typically responsible for the design and implementation of individual classes. These classes generally implement only part of the required behaviour of the system, forcing him to work closely with desingers responsible for the remaining classes. Teamwork is essential if the various classes are to interact appropriately to satisfy the system's functional requirements.
It is our experience that desingers who have thrived in traditional software development environments may fail utterly in an object oriented environment if they do not posssess the necessary communication and team skills.
Communication skills alone will not guarantee a successful transition to OOT. Many designers are afraid of the new technology, or more precisely, think that they will not be able to master the new concepts. While this fear is generally groundless, it is a fact that some designers, no matter how expert they are in traditional methods, simply cannot make the transition.
We have found that it is in the best interest of the organization to eliminate or at least minimize the fear. Training helps. But in the end, the organization must make a conscious decision to redeploy individuals who have not managed to master objects to areas where their expertise will continue to be valued.
It is our experience that traditional management processes do not work in an object oriented development environment. In order to produce the illusion of progress, classical design processes generally involve exhaustive requirements and design documentation prior to proceeding to actual coding. When coding does begin, designers tend to code up the simplest pieces first, once more resulting in a false sense of progress.
OO methodologies generally employ iterative design techniques, whereby understanding of the requirements and the evolving solution are continually refined over several iterations. Rapid prototyping and architecture modelling replaces the traditional documentation to ensure that the requirements are understood and that the solution indeed addresses the requirements. The most complex and risky items are addressed first, producing successive refinements of the architecture. Required fucntionality is delivered incrementally.
Management processes must change to reflect the new emphasis on early risk reduction via rapid prototyping and iterative design. This requires a new kind of partnership between management and development teams, since it is the latter who must continually assess the technical risk which forms the basis for management decision making.
This partnership requires significant effort for seasoned managers who are used to having total control over their project planning, and having a relatively static view of project milestones and deliverables. It is our experience that the inability of some managers to change their traditional modus operendi can lead to failutre of the entire project.
Once again it is important to minimize the fear amongst management that the inability to produce completely detailed project plans from Day One is a shortcoming. Rather it is a strength, since project plans and milestones refined iteratively based upon the actual risks encountered within the project will be far more credible in the longer term.
Background. Raised in Montreal and Winnipeg married with two children (boys 6 & 8)
Education. MMath Computer Science (Waterloo) BEd Mathematics, Physics, French (UBC, Toronto) MSc Theoretical Nuclear Physics (Toronto) BSC Honours Physics (Concordia)
Work Experience. Telecommunications Software (13+ years) High School Teacher (8+ years)
Current Responsibilities. Technology Invisibility Program (Adaptive User Interfaces)
Previous Management Responsibilities. Rainbow Software Architecture Gambit Services Architecture Global 100 China Development GSF Architecture Integrity (A-Team) GSF Agent Interworking Framework and Protocol GSF Services Domain Signaling Management Architecture
Previous Design Responsibilities. CLASS Services International Call Processing and Maintenance International Inter-Processor Communication Protocol