• All in the Memory -- bookkeeping services
• Arabella -- a dynamic musical duo
• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Champagne Beadworks -- handcrafted jewelry and beadwork
• Crafted By Carol -- handcrafted jewelry and beadwork
• Dana Fontaine -- unique photography-derived art
• Dymond Graphics -- note cards, pet/people photography
• Fountains & Funktini -- glass art and more from Beth Keenan and JoAnn Rawley
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Mary Kollman Fine Art -- lovely floral watercolor originals
• Primrose Studio -- terra cotta switch plate covers and wall art
• Ratso's Studio -- astoundingly realistic bronze sculpture
• The Spiral Gallery -- local artists exhibit in the Oregon Cascades foothills
• The Roaming Artist -- info and resources for artists "on the road"
• Van Dyke Sepias -- Jan Van Dyke's nostalgic sepia toned photography
• Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel
• Village of Willamette Arts Festival -- annual visual/performing arts festival, third weekend of September
• Whitehorse Designs -- Gwen Miller's beadwork and fused glass
• West Linn Arts Commission -- city support for the arts

Preface and Index

28 November 1995, Jan Steinman

In various forms, this presentation has been given dozens of times, both for our clients, and at major conferences. Each time, we try to "feel the pulse" of the industry, and upgrade it accordingly.

The first time it was presented (OOPSLA '93), everyone wanted to know the mechanical details of making Smalltalk work for teams. By OOPSLA '94, most people had heard of Team/V® and ENVY®, and they became more interested in coordinating the efforts of team members. By OOPSLA '95, it was "now we got these great tools, and we've learned how to use them, now how can we integrate them into a development process?" In its present form, this tutorial tries to address that concern.

The actual Smalltalk Solutions '95 printed notes included some 30 slides from previous presentations that we intentionally did not cover in that presentation. We feel they detract from the presentation's goals, and have not included them here.

The following index includes everything on each slide, but the linked pages also include copious notes provided with the printed version of the tutorial notes. (Unfortunately, these notes may include ligatures, "m" dashes, and other things that might give your web browser grief!) Enjoy, and please send your feedback!

• Who are we?
  • 20 years object experience, 18 in Smalltalk
  • Smalltalk80/Agents/V/X, Ada, C++
  • Embedded systems, UI research, visualization, instrumentation, finance, and telecommunications
  • Involved in many groupware projects of six to sixty or more developers
  • Developed, customized team programming tools
• Who are you?
  • An experienced Smalltalk developer
  • A Smalltalk project leader
  • A Smalltalk team integrator
  • A manager who is considering Smalltalk
  • Someone mired in FUD
  • Have hit The Smalltalk Productivity Wall
• The Problem
  • Organizational issues predominate
  • Human needs often overlooked
  • Individual environment needs differ from group needs
    Combined result: The Smalltalk Productivity Wall
• Tutorial Objectives
  • Managers
    • Suggest administrative and cultural changes that have proven useful in large OO projects
    • Present sketches of possible technical solutions from which to choose
    • Hard data that can be presented to upper management to justify investment in groupware tools
  • Developers
    • Present advantages/disadvantages of possible groupware solutions
    • Present detailed information on one possible technical solution: ENVY
    • Present enhancements, hints, tips for ENVY users and administrators
    • If already using groupware tools, validation based on case studies
• The Problem
  • Organizational issues predominate
  • Human needs often overlooked
  • Individual environment needs differ from group needs
  • Combined result: The Smalltalk Productivity Wall
• Organizational Needs
  • Realistic expectations from OO technology
  • Useful metrics
  • Assurance of quality
  • Smalltalk-specific needs
  • Sound software development process
  • All of these reduce risk, maximize benefits of OO.
  • None of these can be handled by technology alone.
• Realistic Expectations
  • Management, developer education
    • Avoid the overselling trap
  • Firm scope of pilot project
    • Success of pilot is not necessarily a predictor of future success!
  • Modification of corporate processes
• Useful Metrics
  • Metrics must be relevant to the evolving process.
    • Locality/globality metrics
    • Degree/use of abstraction metrics
    • Code stability metrics (If it is still changing, is it really done?)
    • Interface size/generality metrics
    • Specification/commentary metrics
  • Lines of code is a nearly useless metric!
    • So are other traditional metrics, such as defect count
  • Must reward reuse and reusability
  • Must record and revisit metrics, not just gather them!
• Quality Assurance
  • Unfamiliarity with OO fuels quality concerns.
  • Testers (as well as developers) must be OO-trained.
  • Coding style guidelines, peer review are essential.
  • Documentation synchronized continuously.
  • Process must stress early, continuous testing:
    • Early: any phase that produces code has testing
    • Continuous: most problems should be detected by developers, not testers
• Smalltalk-Specific Needs
  • Use the right tool for the language!
  • Can shoehorn Smalltalk into traditional repository
    • Impedance mismatch will cause productivity loss
    • Satisfy the intent, if not the letter, of corporate mandates to use a central repository
    • Raise visibility of what common repository mandate costs
  • "...legacy systems are best avoided... "
  • Keeper of the base image an important role
  • Other tools can be justified based on lifecycle savings
• Organizational Needs
  • Realistic expectations from OO technology
  • Useful metrics
  • Assurance of quality
  • Smalltalk-specific needs
  • Sound software development process
  • All of these reduce risk, maximize benefits of OO.
  • None of these can be handled by technology alone.
• Sound Process
  • Traditional process is inappropriate
  • Hybrid approach is possible
  • Expect process to change and evolve
  • Have relevant deliverables
    • Demoware, documentation, QA reports, etc., must flow out of process as side effects rather than separate activities.
  • Process can be informal at first, but it must exist!
• A Sample Development Process
  • Iterative vs sequential
  • Multiple feedback loops
  • Variety of checkpoints and milestones
  • Continuous integration
  • Continuous documentation
  • Continuous testing
• The Software Building Activity
• Waterfall Production Activity
• Waterfall Development Activity
• Waterfall Implementation Activity
• The Software Building Activity
• Spiral Production Activity
• Spiral Development Activity
• Spiral Prototyping Activity
• Expand-Contract in the Spiral Model
• Expand-Contract Development
• Some Process Case Studies
  • American Management Systems, Inc.
  • Hewlett Packard Distributed Smalltalk Project (DST)
  • Anonymous Early Adoptor N
  • Anonymous Innovator T
• American Management Systems
  • Approach
    • Read books & journals, attended OOPSLA.
    • Hired OO consultants.
    • Began projects using techniques from books.
    • Learned from projects experiences.
  • Needed process changes, but didnt allow that to paralyze them.
  • Evolved existing process.
  • Reuse already ingrained in culture.
  • Incremental and Iterative.
  • Four project phases
    • For OO, collapsed Detailed Design and System Development into System Construction.
• Hewlett Packard DST Project
  • Adapted existing process for OO
    • Added Functional Spec to Investigation Phase
    • Like AMS, merged Design phase and Implement and Ship phases
  • Iterative process has these activities:
    • Design/Prototype
    • Implementation
    • Integration and Test
  • Checkpoints with reviews
  • Bite size functionality
  • Strong on testing
• Anonymous Early Adoptor N
  • Approach
    • Like AMS, read, attended conferences.
    • Hired consultant to evaluate all OOA/D tools.
    • Evaluated different vendors Smalltalks.
    • Hired consultant to propose process changes.
    • Inhouse process change committee.
    • Began two OO projects using the parts of the waterfall process that fit.
    • Lack of clear strategy made team members feel directionless.
  • Deviation from corporate process meets strong objections.
    • Generally, from line managers who want waterfall milestone deliverables.
  • Fulltime project mentors established spiral model as the defacto process.
  • Status to date:
    • Changes to process gaining acceptance through results.
    • Important to provide documents as deliverables from iterations.
    • Managers concern about tracking progress is lessened.
• Anonymous Innovator T
  • Approach: OO is so different from traditional software development, well just use our common sense as emerging OO gurus.
    • Company had a waterfall process, which was followed very loosely.
  • Good points:
    • Freedom to try new ways of running a project.
    • Involvement of tech writers throughout (docs not written based on functional specs).
    • Discovering how to do OOA/D -- there were no books in 1987!
    • Code reviews as needed (albeit sometimes confrontational).
  • Problem areas:
    • Requires extremely dedicated, selfdirected team members.
    • Difficult to gauge progress, plan schedules.
    • Research group became product group, never acquired a clear productoriented focus.
• The Problem
  • Organizational issues predominate
  • Human needs often overlooked
  • Individual environment needs differ from group needs
  • Combined result: The Smalltalk Productivity Wall
• Cultural Needs
  • Technology is no replacement for human needs.
  • Reuse must be rewarded.
  • Play time is important.
  • Revision time is required.
  • None of these can be handled by technology alone.
• The Technology Trap
  • The problems begin after you buy your tools!
  • Mentoring vs training
  • Broader views needed
• Rewarding Reuse
  • Writing code is writing bugs!
    • Therefore, reusing code is reusing tested solutions.
  • Peer praise
  • One-shot monetary awards
  • Combination
    • Example: monthly group luncheon, with free lunch for reuser of the month
• Curious Minds, Better Solutions
  • Time spent exploring the system fosters reuse.
  • Solution pattern discoveries vs calling libraries
  • Todays playthings have an annoying habit of becoming tomorrows indispensable tool.
• Nothing Is Ever Finished
  • Bitter pill for managers, but reality, therefore:
    • Manage the process.
    • Expect periods of chaos, punctuated by stable periods.
    • Anticipate the stable periods through metrics analysis.
    • Exploit stability by changing release schedules, etc.
  • Its a feature, not a bug!
    • Revision time, even on something you thought was done, often results in improved reusability outside its original use.
• The Problem
  • Organizational issues predominate
  • Human needs often overlooked
  • Individual environment needs differ from group needs
    Combined result: The Smalltalk Productivity Wall
• Individual Environment Needs
  • Good tools for navigating system and personal code
  • Incremental compilation
  • Image-centered change control and management
  • What you saved is what you get (WYSIWYG) philosophy
  • Freedom to experiment
  • Ease of recovery from failed experiments
    All of these are well met by Smalltalk without additional support.
• Group Environment Needs
  • Continuous integration
  • Code sharing
  • Revision history
  • Build transparency
  • Stability (Hey! Who changed Object basicNew ?)
  • Documentation support
  • Re-integration
    None of these are well met by Smalltalk without additional support.
• Multiple Team Needs
  • Planning for reuse
  • Common corporate base
  • Visibility of what other teams have developed
    None of these are well met by Smalltalk without additional support.
• Individual-Group Needs Mismatch
  • Source code identity problem
  • No code modularity
  • Arbitrary code units, maintained in files
  • No cross-developer browsing
  • Isolated change management
  • No documentation support
  • Integration synchronization
• Solution Needs
  • Integration
  • Code Sharing & Concurrency Control
  • Revision History
  • Configuration Management
  • Documentation Support
  • Re-Integration Support Branching & Merging
• Integration Needs
  • Essentially, a code combining activity
  • Asynchronous
  • Democratic...
  • ...yet controlled
  • Contents are apparent
• Code Sharing Needs
  • Multi-developer browsing
  • Code ownership
  • Code unit writelocking
  • Code privacy issues
  • Coherent release policy
• Revision History Needs
  • Each change distinctly retrievable
  • Changes instantly available to other team members,
  • But not imposed on them
  • Seamless integration with code sharing tools
  • Supported by differencing tools
• Configuration Management Needs
  • Arbitrary combinations of arbitrary code units
  • Code unit semantics
  • Seamless integration with revision history
  • Conditional integration
• Documentation Needs
  • Design -- implementation link
  • Simple to use
  • Enforcement
  • Hardcopy
  • Seamless integration with code privacy
• Re-Integration Needs
  • Necessary for spiral development
  • Supports expand-contract development
  • Painless identification of changes
  • Simple selection of changes
  • Differencing tools
• Possible Solution Patterns
  • Ad-Hoc
    • Better known as struggle your way through with whatever your vendor gave you
  • Check-In, Check-Out (CICO)
    • Models traditional software development
  • What You Saved Is What You Get (WYSIWYG)
    • Basically, the original Smalltalk individual code management system on a project-wide basis
• Pattern: Ad-Hoc
  • Developermanaged files of code, integrated by Smalltalk build scripts
  • Cheap, simple, good for oneperson projects
  • Error-prone, guru-based, difficult to change
• Pattern: CICO
  • Arbitrary files of code in a traditional code repository, with developer-managed deposit, locking, etc.
  • Simple to implement, simple to use
  • Difficult to change and extend, little management control
  • Supports single-grained sharing and history
  • Useful for smallish, co-located develop-only teams
• Pattern: WYSIWYG
  • Fine-grained, realtime sharing & concurrency using shared repository
  • Arbitrary-sized, nestable, modules with extendable semantics
  • Users associated with modules via roles
  • Fosters team communication, continuous integration, tight management control
  • Restricts impact of hacking
• Examples From Real Teams
  • Team 1 Ad-Hoc
  • Team 2 CICO
  • Team 3 CICO
  • Team 4 WYSIWYG
  • Team 5 multiple WYSIWYG
• Example Team 1: Ad-Hoc
  • 2 co-located developers, ST80 version 2.5
  • Multiple named change sets (custom enhancement to the base image)
  • File-in make file
  • Occupied 58% of project person-hours
• Example Team 2: CICO
  • 6 developers, ST80
  • RCS hooked into the image with custom tools
  • Code unit = a class
  • No support in image for check-in/out of base classes
  • No support in the image for managing the make file
  • Builds were done by the highest-paid team member (the guru approach)
  • Builds took many hours, required a dedicated workstation, often required multiple tries to succeed
  • Averaged 23 builds per week during final integration prior to a release
• Example Team 3: CICO
  • 4 + 5 + 1 developers (three teams), Smalltalk/V
  • Commercial Smalltalk source code management toolset (no longer sold)
  • One consultant fulltime fixing bugs and enhancing the tools
  • Developers were Smalltalk novices and very experienced Smalltalkers
  • No version control, no configuration control, no support for prerequisites -- a strict tree structure for code modules
  • A shared OS2 directory structure for the repository
  • Builds were done by a consultant (the guru approach)
  • Builds took many hours, were done on weekends or nights (no spare PCs!), often required multiple tries to succeed
  • Developer errors would completely ruin one teams half of the repository, by writing bad versions of code over good
• Example Team 4: WYSIWYG
  • Large, distributed telecommunications application
  • 8 developers, 6 with a year or less of Smalltalk
  • UNIX, Sun, VisualWorks, ENVY, client/server
  • Flexibility utmost -- shifting, conflicting requirements
  • Endured three major toolset changes
  • Extensive code module restructuring
  • Automatic generation of documents from comments
  • Online code reviews
  • Two developers shared integration task
  • Builds performed every six weeks, on average
• Example Team 5: multiWYSIWYG
  • Over 100 Smalltalk-80 licenses
  • UNIX, Sun, Smalltalk-80 v4.1, ENVY, client/server
  • Repository shared across 4 sites on 3 continents
  • Typical team size: 8 to 20
  • Automatic refresh of remote repositories via cron
  • Two teams:
    • Common data model, different GUIs
    • Weekly, nonsynchronized builds
    • Diverged, merged numerous times
    • Reorganized infrastructure several times
• WYSIWYG Exemplar: ENVY
  • ENVY/Developer , a product of Object Technology International of Ottawa, Canada
  • Available for Smalltalk/V and Smalltalk-80 on numerous platforms
  • Key points:
    • Integrated source code management and development environment
    • Error avoidance
    • Encourages an iterative development scheme with continuous integration.
• ENVY Concepts
  • Shared code and documentation repository
  • Realtime sharing & concurrent development
  • Atomic loads and unloads
  • Software component hierarchy
  • Users associated with components via roles
  • Software component lifecycle
• Shared Repository
  • Shared code and documentation repository
    • Replaces the sources and changes files with a single shared library
    • Besides code, arbitrary objects, such as documents and pictures (e. g., Hot Drawings) can go in the library.
  • Realtime sharing and concurrent development
    • Developers can work on the same module concurrently without worrying.
    • Short-term exclusive locking only (milliseconds)
  • Atomic loads from the library to your image; atomic unloads
• Repositories
• Software Components
  • Software Component Hierarchy
    • Containment relationships: No method, no class, no subapplication can ever be loaded into an image except by being loaded into a component that contains it.
    • Methods as the smallest version-controlled unit
• Component Relationships
• Roles of the Developers
  • Degrees of authority and responsibility
    • The creator of a component gets the highest authority for that component.
    • Most of these roles can be reassigned.
    • Manager role for configurations, applications, and subapplications.
    • Owner role for classes and class extensions.
    • Developer role for class editions and versions.
  • It is up to the project management how much responsibility they decide to attach to each role.
• Software Component Lifecycle
  • The component cycle is very simple:
    • Components begin life as editions open for change, writable, mutable. They can stop here, but usually they go on.
    • When they are ready to be locked to changes, they are made versions. Now they are immutable. They can stop here, or they can go on.
    • If the component is a class, class extension, or subapplication, it must be released to become a permanent part of the configuration of its parent.
    • Usually components repeat this cycle, so they next become editions, and development continues.
• Who can do what (and when)?
• ENVY Cycle