• DDC-I Organization - Focused on the Customer
• Learning and Remembering: Tell me a Story!
• Tech Talk: Notes on TADS Interrupt Types
• On the Front Lines: Meet David Mosley, Engineering Manager and SCORE Product Champ
• 3rd Party Update: Providing a Total Solution Through 3rd Party Partnerships

Subscribe to DDC-I Online News and receive monthly updates automatically


Previous Issues



Success Stories

Current Products

****** NEW! ******
Custom Solutions

By Ole N. Oest, President/CEO

In the traditional corporate hierarchy, everybody works for the President. The organization can be depicted as a pyramid with the President at the top. The employees, who do the real work and have daily contact with the customer, are at the bottom. Decisions are made somewhere higher up in the pyramid, and the folks at the bottom are not empowered. That doesn't do much for the customer.

At DDC-I, the organizational pyramid is turned upside down, with the focus on the customer. The structure is also flattened, so that DDC-I employees are cast in only two roles. They are either "front-liners" who interact directly with the customer, or they have support of our front-liners as their primary objective.

DDC-I's Organizational Structure

#1 in Customer Care

The front-liners here at DDC-I are knowledgeable, experienced, and empowered to solve problems. They can allocate resources (people and money) as needed. They have the training and authority to deal directly with customer issues, without securing approval from all higher levels of authority. We have aligned responsibility with capability. This ensures a timely response by a qualified individual to every customer issue, and it reduces both bureaucracy and cycle time.

Here are the DDC-I front-liners:

Product Champions: Each product has its Champion. Product Champions are highly skilled senior engineers with a deep understanding of the product line for which they are responsible. Unlike most software companies, DDC-I allows their customers direct access to these lead developers. Technical questions or problems relating to specific products are handled directly by the Product Champions. Within the framework of their budgets they decide the best approach to each customer issue, providing technical advice, temporary work-around suggestions, critical program patches, or regularly scheduled maintenance releases. Naturally, the development of a new release must follow specific procedures, in order to ensure conformance with overall company goals and coordination among all products. Otherwise, the Product Champions have substantial latitude and discretion in solving customer problems.

Help Desk: Customer Support Engineers respond to a wide variety of customer inquiries about product installation, configuration, and usage. More difficult technical issues are dispatched by the Help Desk to the appropriate Product Champion for investigation. The Help Desk is also responsible for all shipping and product documentation.

Sales Representatives: Each customer is assigned a Sales Representative, based on geographical region. The sales representative is the direct administrative link to current and prospective customers.

This organizational structure is not a new concept. It was first implemented by Scandinavian Airlines, and it has proven to be highly effective. It fosters ownership and pride in the front-liners. When properly managed, this approach ensures short cycle times, a lean and efficient organization with few administrative procedures, and a high degree of customer satisfaction.

DDC-I adopted this structure in April 2000. The result has been resoundingly positive for both customers and employees. Customer maintenance renewals and employee retention are at all time highs. When we say "DDC-I - #1 in Customer Care", it is not just a marketing motto. We have restructured our organization and fundamentally changed the way we do business, in order to make this a reality.

Stories are like flames that warm our hearts. They help us overcome our mortality.
Gerard Tsonakwa, telling Abenaki Indian legends during an evening presentation at the Arizona-Sonoran Desert Museum.

By Linda Rising

Back in September, I wrote an article that introduced readers to the notion of patterns. This article builds on that one and assumes that the reader knows a little about patterns. I refer readers with questions to that article or any of the articles on my web site: www.lindarising.org.

In the mid-90s, when most of us in the software community were reading our copies of Design Patterns [Gamma+95], we thought that by understanding the 23 patterns described in that text, that we would have a pretty good handle on patterns. Now there are dozens of books on patterns and in The Pattern Almanac [Rising00], over a thousand patterns are documented. While most of us who study the patterns scene agree that the number of patterns in software is finite. It is overwhelming to consider the number of patterns that are currently out there.

How can we learn the ones we need to know and how can we remember them?

As I describe in The Patterns Handbook [Rising98], the company I worked for, AG Communication Systems, provided extensive training on the patterns in the Design Patterns. It was, however, training. I remember one of our students remarking that going to a training class in industry is like "drinking from a firehose." He’s right! Too much, too fast, too difficult to learn and then remember when you need it. We addressed this problem in several ways. The first was to introduce study groups—a topic for an entire article. Perhaps we’ll schedule that if readers request it. You can also find more information in a paper I’ve written that’s on my web site.

Another solution we stumbled upon was to use stories and metaphors to teach the patterns and to help developers remember them.

The following observation about stories is from Roger Schank [Schank90]:

The...problem is simply that humans are not really set up to understand logic. People tell stories because they know that others like to hear stories. The reason that people like to hear stories, however, is not transparent to them. People need a context to help them relate what they have heard to what they already know. We understand events in terms of events we have already understood. When a decision-making heuristic, or rule of thumb, is presented to us without a context, we cannot decide the validity of the rule we have heard, nor do we know where to store this rule in our memories. Thus, what we are presented is both difficult to evaluate and difficult to remember, making it virtually useless. People who fail to couch what they have to say in memorable stories will have their rules fall on deaf ears despite their best intentions and despite the best intentions of their listeners. A good teacher is not one who explains things correctly but one who couches explanations in a memorable format. ... In the end all we have...are stories and methods of finding and using those stories.

As Gilbreath notes:

No matter how many seminars I conduct, the first and last thing the audience remembers is the stories. It doesn't matter how significant or minor the lessons, how detailed or inflammatory the discussions that follow. They'll remember the stories years after the points I've struggled to make are forgotten.

Laundry lists of key facts, bullet slides, flowcharts, case studies of excellent corporations—I know these are as impermanent as dust in the wind. [Gilbreath93]

In one of our classes, one of the students was struggling to stay awake. You know how it is. You’ve been trying to learn for a couple of days in a relentless training session and your brain just can’t absorb anymore. You begin to doubt your own ability to acquire new skills. It’s discouraging—especially just after lunch! To keep himself occupied and try to stay on track, he began to create a real-world, non-software example of each pattern as he was struggling to understand and remember it. At first it was just a fun exercise but after the class, he came by to see me and we realized that this would be a tremendous learning and remembering aid. The whole company was facing these problems—How can we learn these patterns and then when we face new situations where we need to apply them, how can we remember the one we need? The real-world, non-software examples seemed to help.

At the time, I knew little of cognitive studies and why this approach would be so successful but I was soon to learn a lot! The student was Mike Duell and he and I held two workshops at OOPSLA to share our ideas with others and to create an on-line catalog of real-world, non-software examples for all the patterns in the Design Patterns text, as well as the next new book on the patterns horizon, Pattern-Oriented Software Architecture [Buschmann+96]. http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/index.htm

In these workshops, as we struggled to create a good example or story, we realized that in many cases we didn’t truly understand the pattern. The act of telling a good story about the pattern ensured that we were all talking about the same thing. We hadn’t expected that. Our examples were actually clarifying the text in the books written by the experts. Some of the participants in our workshops were the experts who had written the books and they were learning, too!

At this time, I was involved in an activity we called "pattern mining." Our company was interested in the published patterns and wanted developers to be aware of the information that was publicly available but what really captured our management’s attention was documenting our own ideas. We would create a handbook of patterns in our domain to ensure that if anything happened to our handful of resident experts in a particular area, the knowledge they had would not be lost. This is a problem all organizations face. The solutions to this problem fall under the heading of knowledge management. Trying to solve this problem led to the first patterns in fault-tolerant computing. A couple of folks at Bell Labs (part of AT&T at the time, now part of Lucent) captured patterns from the 4ESS™ architecture, which are now used to teach newcomers to that project about the architecture of the software.

As I interviewed experts in our product domains, I noticed that what I was capturing were stories. Stories about some heroic gesture that really made a difference on a release. Stories about ideas that had been hard-won on earlier releases and were applied to help yet another. When these patterns were distributed to other developers, the stories were the first parts of the patterns that were read. I heard comments like, "So, that’s what happened on Project x!" People who had worked alongside others for decades finally had a way of sharing their experiences.

As Schank has noted:

If a prior experience is understood only in terms of the generalization or principle behind the case, we don’t have as many places to put the new case in memory. We can tell people abstract rules of thumb that we have derived from prior experiences, but it is very difficult for other people to learn from these. We have difficulty remembering such abstractions, but we can more easily remember a good story. Stories give life to past experience. Stories make the events in memory memorable to others and to us. [Schank90]

Stories last. Especially if they involve people in predicaments that reflect yours. People struggling with dramatically new and challenging issues. People caught in ethical dilemmas and grappling with the irrepressible phenomenon of our time: change. People you'll recognize immediately, because you've dealt with them before. [Gilbreath93]

I remember how the patterns activity began. I gave brown bag sessions on a few patterns from the Design Patterns text. After each pattern had been introduced, I would ask if that particular problem had ever been encountered on a project. Lots of discussion followed. After one description of an instance of the problem, someone else would say, "I didn’t know you were working on that problem! We had the same problem!" Developers who sat only a few feet apart were suddenly given the opportunity to learn from each other’s success and failure. We need more of this.

We’re learning that knowledge works through rules of thumb: flexible guides to action that developed through trial and error and over long experience and observation. Rules of thumb (or, in the language of the artificial-intelligence community, heuristics) are shortcuts to solutions to new problems that resemble problems previously solved by experienced workers. Those with knowledge see known patterns in new situations and can respond appropriately. They don't have to build an answer from scratch every time. [Davenport+98]

Gary Klein has done considerable research in how experts solve problems. When he started, he believed that they used a decision-making process—created lists of alternative costs and benefits and weighed the consequences. He was as surprised as anyone to learn that this is not how they operate at all. They use patterns. The experts might call it intuition but somehow they just "know" what to do, especially in an emergency. When the experts talk about it, they tell stories.

We have found that people draw on a large set of abilities that are sources of power. The conventional sources of power include deductive logical thinking, analysis of probabilities, and statistical methods. Yet the sources of power that are needed in natural settings are usually not analytical at all—the power of intuition, mental simulation, metaphor, and storytelling. The power of intuition enables us to size up a situation quickly. The power of mental simulation lets us imagine how a course of action might be carried out. The power of metaphor lets us draw on our experience by suggesting parallels between the current situation and something else we have come across. The power of storytelling helps us consolidate our experiences to make them available in the future, either to ourselves or to others. [Klein98]

After we had been working with patterns for a couple of years, we also introduced them into our postmortem process. I will write an article about that in a couple of months. What’s of interest for this article is that the techniques we used began to incorporate stories from the project. In the past, we had collected postmortem data; most companies do. The problem with all that data was—no one ever read it! When we added stories—in the words of the people on the project—and then extracted patterns after seeing similar solutions in several projects—the lessons learned seemed to have impact. People picked up best practices and avoided mistakes. This benefit alone was worth all the patterns effort.

It was a happy accident that we found the power of stories. I described my job as that of a minstrel. Remember the strolling troubadours in the middle ages who went from place to place carrying news and gossip? It seems we’re missing that role in current software development. We often say that engineers have the "not invented here" syndrome but, in truth, there hasn’t been a convenient way to share knowledge. With a resident minstrel, someone hears the stories and then tells them to the next project. Someone knows the patterns and keeps using the names until they become a part of everyone’s vocabulary. Someone helps to grow an organizational culture that supports sharing of knowledge across all projects.

I can just imagine the ad: Wanted. Minstrel. Extrovert who believes there is good in everyone and wants to hear a story about it. Technically proficient with good organizational knowledge and team-building skills. Must be a good listener. Good singing voice nice but not required.

I like what Swap and his colleagues have said:

If you want people to remember information and believe it, your best strategy in almost every case, is to give that information in the form of a story. [Swap01]

[Buschmann+96] Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture, Wiley, 1996.

[Davenport+98] Davenport, T.H. and L. Prusak, Working Knowledge: How Organizations Manage What They Know, Harvard Business School Press, 1998.

[Gamma+95] Gamma, E., R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison-Wesley, 1995.

[Gilbreath93] Gilbreath, R.D., Escape from Management Hell, Berrett-Koehler Publishers, 1993.

[Klein98] Klein, G., Sources of Power, The MIT Press, 1998

[Rising98] Rising, L., The Patterns Handbook, Cambridge University Press, 1998.

[Rising00] Rising, L., The Pattern Almanac 2000, Addison-Wesley, 2000.

[Schank90] Schank, R. C. Tell Me A Story, Charles Scribner's Sons, 1990.

[Swap+01] Swap, W., D. Leonard, M. Shields, and L. Abrams, "Using Mentoring and Storytelling to Transfer Knowledge in the Workplace," Journal of Management Information Systems, Summer 2001, Vol. 18, No. 1, pp. 95-114.

Tech Talk: 

Notes on TADS Interrupt Types

By Russell H. Katz

The TADS system defines three methods of implementing interrupts:

I. The Transparent Interrupt Handler
II. The Standard Interrupt Handler
III. Ada Tasking Interrupts

I. The Transparent Interrupt Handler

A Transparent Interrupt Handler is what most people would most commonly associate with a traditional form of a real-time embedded systems interrupt. There is an Interrupt Service Routine (in this case, it must be written in the target boards assembly language) that is associated with a hardware interrupt number. The address of this ISR is installed in the appropriate entry of the systems interrupt vector table. When the hardware interrupt occurs, and the vector table is accessed, the entry corresponding to the interrupt number is determined and accessed, then control is transferred to the ISR.

The transparent handler requires very little overhead in the servicing of interrupts. In most cases, it will need to save the values of the registers it will use in its processing, perform some type of interrupt masking and the do its work. After it is finished, it will need to restore the registers and the interrupt mask and then return.

Advantages: Fastest form of interrupt handling available. Very efficient, reduces most overhead associated with other forms of handling.

Best form of handler mechanism for dealing with time critical devices.

Disadvantages: Cannot use any runtime services, Ada tasking or any other Ada calls. Can be difficult if not familiar with assembly language programming. Must take care of all overhead associated with the handling of the interrupt.

II. The Standard Interrupt Handler

This type of handler provides for more options than with the transparent handler, but does require more overhead for implementation. The benefit comes from the fact that you are actually calling an Ada procedure to handle the interrupt. Since the handler is being executed in an Ada environment, it allows calls to Ada runtime tasking and interrupt services. Any call that could cause a context switch or system rescheduling must not be used. Due to the fact that the Ada handler is being directly called from the context of the hardware interrupt, if transfer of control were to take place, it would never return to the handler.

The benefits of executing in the Ada environment come with a price. The Ada procedure must be tied to an assembly routine that is actually installed in the vector table. This routine is responsible for setting things up so that the Ada handler can be called, and then does the call to the Ada procedure. It is also responsible for doing the cleanup after the Ada call has completed. This creates more overhead and can slow down response times.

Advantages: Deterministic interrupt handler, in that it will call the Ada procedure handler immediately with no context switch required as in the case of tasking handlers. Fairly fast handling capability plus allows the use of some runtime system calls.

Disadvantages: Not as fast as transparent handlers. Does require some effort to create and implement standard handlers. Must be careful regarding which system calls are used inside the handler.

III. Ada Tasking Interrupt Handlers

This type of interrupt handler provides the most capabilities in the handling of interrupts. This is due to the fact that the interrupt handler is actually an Ada task executing outside the interrupt context. This allows all features of the Ada language and runtime system to be utilized including calls that would cause context switching. There are two types of Ada tasking interrupt handlers, fast and full support. The key difference is that with the fast mode, you get a faster response in scheduling the task handler to execute, but there are some constraints (no select statements in the accept statement, no nested accept statements and the handler must be waiting at the accept when the interrupt occurs otherwise it will miss the interrupt). The full support model does not apply these constraints and can queue one interrupt call, but it does involve a slower response time.

Tasking interrupts can be associated with an entry in the hardware interrupt vector table, implemented as a software interrupt (where DO_INTERRUPT is used to cause the interrupt to occur), or both. Whether a task handler is installed in the hardware vector table or not is controlled by setting or clearing the appropriate bit corresponding to the interrupt level in the CONNECT_MASK.

One unique feature of the software interrupt feature associated with the tasking interrupts is the ability to combine them with Standard Interrupt Handlers. This is useful in cases where a device might require some immediate processing, while at other times the associated processing can be done in a lower priority mode, without having other interrupts or tasks blocked. In this approach both a standard handler and a tasking handler would be created. The standard handler would be installed in the hardware vector table in the entry associated with the interrupting device. The tasking interrupt would be assigned an unused interrupt number and would not need to be installed in the vector table. When the device causes an interrupt, the standard handler will be invoked, and can then determine whether the device requires immediate attention or if it can be handled at another point in time. If it is not extremely urgent, the standard handler can cause the task interrupt to occur (by using the DO_INTERRUPT call), which will schedule the task interrupt handler to take care of the device. This allows fast deterministic servicing of hardware interrupts while also allowing the system to execute outside an interrupt context as much as possible.

Advantages: Very flexible interrupt handling mechanism, allows access to all Ada system calls. Can be implemented as either hardware or software handlers, which makes testing easier and allows for combining with other types of handlers. Easiest form of interrupt handler to implement.

Disadvantages: Non-deterministic response times. Possible to be preempted by other tasks or interrupts. Slowest response time of all interrupt types.

On the Front Lines

David R. Mosley DDC-I, Inc. Engineering Manager SCORE Product Champ

As Engineering Manager for DDC-I, Inc, David Mosley is responsible for all engineering and customer support activities in the U.S. Additionally, David is the Product Champion for the SCORE product line. In his role as SCORE Product Champ, David works closely with SCORE customers, deciding the best approach to each customer issue, providing technical advice, temporary work-around suggestions, critical program patches, or regularly scheduled maintenance releases. During his 8-year career at DDC-I, David has led many development teams for other DDC-I product lines, including DACS-80860.

David grew up in Phoenix, where he discovered a true passion for Astronomy. He graduated from Caltech with a BS in Astronomy in 1972, and followed with an MS in Astronomy from the University of Arizona in 1975. Changing his focus, David obtained an MS in Computer Science in 1977.

Since 1978, David worked in compiler development at Motorola, Bull, Honeywell Air Transport Division, as well as DDC-I. He has been using DDC-I's technology since 1987. He also has experience as an instructor of the Ada programming language at Glendale Community College, and regularly volunteers his time as an auditor of donated tapes for the Glendale Public Library.

David lives in Glendale, Arizona with his wife Shelley. He has two grown children, Andrew and Jessica, and enjoys reading science fiction and leisurely drives in his PT Cruiser.

3rd Party Update

Providing A Total Solution
Through 3rd Party Partnerships

The DDC-I Third Party Partner Program is designed to provide our customers with a total solution which offers the best tools and services available for today’s tough demands. Our partners are recognized technology leaders which compliment and strengthen DDC-I’s products and services.

This column is dedicated to building industry awareness of our partners and their relationship with DDC-I. It will provide valuable information on high quality development solutions and the wide variety of hardware and software options available.

DDC-I’s commitment to being #1 in Customer Care is evident in our ongoing pursuit of quality third party partnerships. Visit our partner pages for a list of current partners and watch for the first feature in next months issue.

Upcoming
Training:

Introduction to Ada95:
The Language for Safety Critical Applications
Nov. 13, 2002

---------------

FAA DO-178B Basic Seminar
Nov. 14, 2002

---------------

FAA DO-178B Applied Seminar
Nov. 15, 2002

---------------

Seating is Limited!

Click Here for More Info

Check out DDC-I's

Support Program