• Flexible Subscription Pricing Now available from DDC-I 
• 3rd Party Update: FAA DO-178B Training From Enea TekSci
• Tech Talk: A Simple Way to Debug Ada Elaboration Code in SCORE®
• Pair Programming - This simple concept conceals one of the most powerful additions to the software development toolbox in decades

DDC-I's Multi-Language SCORE® IDE Offers Flexible Subscription Pricing … Royalty Free!

Phoenix, AZ. – October 21, 2003 - Veteran software tools supplier DDC-I today announced a subscription pricing option for the versatile SCORE® (Safety Critical, Object-oriented, Real-time Embedded) Integrated Development Environment as a cost-sensitive alternative to traditional licensing models. Allowing the customer to subscribe to only the number of program seats actually required during each single year period, from one to whatever needed, DDC-I’s subscription model is highly competitive, and even includes DDC-I’s "Atlas Advantage" support package.

"With a clear understanding of increasingly challenging budget structures confronting many project programmers and the long-term importance of minimizing maintenance costs, subscription pricing for SCORE® offers customers the simplest, most sensible means to align programming and project expenses," explains DDC-I President Ole Oest.

Providing industry-leading programming products and support services to a distinguished list of commercial and defense contractors including Boeing, Lockheed-Martin, and Sikorsky, DDC-I also supports diverse development beyond aviation and aerospace, from commercial satellite and telecommunication systems to next-generation voice and data network technology, bullet trains and medical equipment.

Subscription pricing reduces up-front costs, allowing the customer to increase or decrease the number of subscribed seats to match the dynamics of a program's staffing profile. In the maintenance phase of the program's life cycle the subscription could go as low as one seat.

With subscription pricing no cash is tied up in a capital purchase, and while the annual subscription fee is very competitive, the customer still retains the benefits of DDC-I's acclaimed support program. In addition, SCORE® remains royalty free (no fee is associated with distribution of the customer's application), an additional feature aimed directly at the customer's bottom line.

"The creativity, engineering support, and customer service that help our customers succeed are what we continue to offer every developer in the real-time embedded systems market," Oest concludes. "Whether it's aerospace, satcom and telecom, networking infrastructure - or any safety-critical application where system downtime is simply not an alternative - we have the tools and pricing programs to help our clients excel."

[ Back to Top ]

FAA DO-178B Training From Enea TekSci
November 6 & 7, 2003

Mention DDC-I and Save 20%
Bring a Friend and Save an Additional 20%

Enea TekSci provides both on-site and off-site training in the FAA's civil avionics standard, RTCA DO-178B. The 2-day course is taught by several of Enea TekSci's Sr. Engineers and FAA-Designated Engineering Representatives (DER's). The course instructors are of the highest caliber available anywhere in the world, and have many years of hands-on experience designing and certifying software to DO-178B standards.

Who should attend?

Any technical or managerial persons wanting to improve their knowledge and productivity within high reliability software processes and DO178B, the "FAA’s bible for safety critical software systems". Relevant fields: avionics (commercial and Military), medical, telecom, and high reliability software/systems.

Why attend?

• Improve your knowledge of building reliable software and systems.
• Improve your productivity and minimize schedule/$/risk when working with critical standards such as DO178B.
• Learn the latest tips and success secrets from professionals at the largest Safety Critical consulting company in the U.S: Enea TekSci
• Learn the latest Tools/Techniques available for safety critical applications
• TekSci is the largest DO178B consulting and training company in the world. 95% of all previous attendees called it "The most cost effective means of understanding DO178B, critical software processes, and improving cost-effectiveness".
• Why else attend our public training in Phoenix? Phoenix is 80 degrees F (26 degrees C) and the venue of The Wyndham Buttes Resort has been named one of the top destination/conference resorts in the Southwest .

How to Attend?

Register in advance by calling TekSci: 480.753.9200 or go to TekSci's website at http://www.teksci.com

Get additional information at http://www.teksci.com/teksci/news_ustraining.asp and hotel information at http://www.teksci.com/teksci/phx_rec_hotels.asp

All previous courses have been sellouts, so please register early.

See www.teksci.com for specific details.

[ Back to Top ]

With Ada applications, it is sometimes useful to be able to step through and debug the elaboration code for the compilation units in the application. This note briefly describes a simple way to debug the elaboration code of any units compiled with debug that works with the SCORE® Multi-Language Debugger, v2.4 and later.

To get to the elaboration of the first unit, at the initial breakpoint (when the debugger starts or after a restart), do a "source step into" either by entering it as a debugger command (step \into) or by clicking on the button in the GUI. If any units have elaboration code for which debug information is available, the debugger will execute to the start of the first such unit. This unit can be debugged as usual. When you leave the code for this unit by doing a step from the end of the unit or by doing a step return, you will be in the linker generated code that calls the elaboration code for each unit. This code has no debug information, and you will get a message to that effect. At that point if you do another "source step into" you will execute to the start of the elaboration of the next unit that has debug information or to the start of your main program (assuming it was compiled with debug).

Note that doing a "source step over" from the initial breakpoint will cause stepping to the start of the main program.

[ Back to Top ]

By Linda Rising
risingl@acm.org
www.lindarising.org

Let’s eavesdrop on a conversation between a manager and a developer on the topic of pair programming.

Manager: OK, I’m listening. What’s this new approach you’ve been reading about? What’s it called? Pair programming?

Developer: It’s really cool. Two programmers work together at one computer on the same task.

Manager: OK, two programmers and one computer. I get it. One is typing, right? Well, what the heck is the other one doing?

Developer: Well, er, ah, the other one is thinking!

Manager: Thinking! We don’t have time for that! We’ve got deadlines to meet! Get back to work. Crazy idea…two programmers…only one typing…

Yes, that’s the typical response. For those of you who have been keeping up with the latest "hot" topic in software development—agile methods —you’ll recall that many of these approaches recommend pair programming. And the idea is pretty much what our hapless developer described in the conversation above. But there’s more to it—a lot more. This simple concept conceals one of the most powerful additions to the software development toolbox in decades. Pairing can fit into any software development methodology to obtain all the benefits I’m about to describe. In fact, the power extends to other activities as well, pair testing, for example. Some advocates go so far as to say that any complex task should be done by pairs—the more complex the task, the greater the need for two brains. We’ve all been waiting for the data to justify what we knew all along was the case and now that data is here. It’s in the book Pair Programming Illuminated by Laurie Williams and Robert Kessler. I highly recommend that you get and read that book for more on this interesting topic. This article will, I hope, whet your appetite for more.

The power of pair programming, comes about, of course, as a result of collaboration. As Warren Bennis has said, "None of us is as smart as all of us!" And it’s so true. I see things differently from the way you see things, so if the two of us are continually thinking about a problem, we are simultaneously learning from each other and building a solution that gets better and better. The end result is something neither of us could have created alone and of much higher quality.

In the pair, the one typing is the "driver." The other is the "navigator." The navigator is thinking about what lies ahead, just as the navigator who sits next to the driver of a car. The driver of a car is concentrating on the details immediately in front of the car, while the navigator, many times consulting a map or set of directions, while looking ahead, is also making sure the driver is making the proper turns, seeing distractions, and so on.

If you’ve ever had the experience I have, of arriving in a strange city, trying to drive a rental car, worrying about directions hurriedly scribbled at the rental car desk, and trying to make sense of local road signs, you know how hard it is to get it right the first time. Sometimes we have to stop and ask for help. Sometimes we pull over and re-read the directions and study the map. If we have a reliable navigator, things are much easier, and sometimes, when there’s a puzzle—what does this instruction mean?—it’s a lot less stressful and a lot more fun to deal with when you’re not alone.

This analogy carries over to other kinds of problem solving, including programming. The driver talks about what is happening. The collaboration is very active. The data shows that pairs say something to each other every 45-60 seconds. They also take turns driving—just like a car – and for the same reasons! The pair doesn’t have to stay together. The make-up of each pair depends on the tasks that need to be done that day. "Wally, maybe you and I can work this afternoon on that database problem?" "Alice, if you’re free this morning, I need help with that protocol."

Even when working with pairs, each task should have a single owner. The owner recruits partners for parts of the task. As a result, a lot of time is spent on tasks we don’t own, which encourages team members to focus on the success of the team instead of on their own contribution. Team members also enhance their understanding of the overall system, which, in turn, helps each individual task.

To answer the manager’s questions, "What’s in it for me? Why should I pay two programmers to do something that one programmer can do?" Here are some answers:

1. To complete projects on time with higher-quality code. Data to support this will follow.

2. To reduce the risk of losing a key person. If a pair works together consistently, then there are two people who know the area. If the pairs rotate, many people can be familiar with each part.

3. To make employees happier. Turnover is costly. Happier people stay in their jobs longer. Happier people are positive about their jobs and eager to help the team meet its objectives. Pairing has been shown to improve job satisfaction and overall confidence while improving quality and cycle time. Over 90% of pairs in one survey agreed that they enjoyed their jobs more when pairing and 96% indicated that pairing made them feel more confident.

4. To reduce the amount of time to train a new person. When training costs are reduced it not only impacts budget but also allows new people to contribute much earlier. During typical training, neither the trainer nor the learner is contributing but while pairing the trainer teaches by doing, which means that contributions are made during the training time. One study found that the time required to get a novice to be relatively independent is reduced by half when using pairing.

5. To help teams work well together and communicate more effectively. Managers know the benefits of having teams work effectively together. Pairing reduces information islands because people are more likely to talk to each other often, sharing problems and solutions.

Now, let’s trot out some of that data. That’s always good for convincing executives!

A report on pairing from Hill Air Force Base showed a total productivity of 175 lines/person-month compared to individual productivity of 77 lines/person-month. The error rate through system integration was three orders of magnitude lower than the organization’s norm. Observed phenomena include: focused energy, brainstorming, problem solving, continuous design and code walkthroughs, mentoring, and motivation.

A Temple University study in 1998 involved fifteen full-time, experienced programmers working for 45 minutes on a challenging problem important to their organization, in their own environment. Five worked individually. The other ten worked in five pairs. The results were statistically significant. "To the surprise of the managers and participants, all the pairs outperformed the individual programmers, enjoyed the process more, and had greater confidence in their solutions." The pairs spent 60% more person-minutes on the task, but used less "wall-clock" time, and produced better algorithms and code. Most of the programmers were initially skeptical of collaboration and thought it would not be an enjoyable process.

In 1999 at the University of Utah, students in a senior-level software engineering course participated in an experiment on pairing. They were divided into two groups weighted for performance. Thirteen worked individually and twenty-eight worked in fourteen pairs.

Most students had significant coding experience in industry or had written small compilers, operating system kernels, and interpreters in other classes. The students completed four assignments over six weeks. All individuals and teams completed each assignment. The pairs passed, on average, 15% more of the automated post-development test cases.

The pair results were more consistent than that of individuals. Programmers in pairs admitted to working harder and smarter because they did not want to let their partners down. Individuals did not have this kind of pressure and did not perform as consistently. Not only were the pair results of higher quality but their programs were more than 20% shorter. Individuals were more likely to produce "blob class" designs—just to get the job done, while the pair designs demonstrated more encapsulation and cohesion. The code produced by individuals would be more difficult to understand and maintain.

The gut reaction of most people is to reject pairing because they assume that there will be a 100% increase in programmer time. Initially, the University of Utah study showed an increase of about 60% in the first assignment but thereafter, pairs spent on average 15% more than individuals. This was not statistically significant because the median amount of time spent by individuals and the pairs was essentially identical. As an interesting note, pairs that spent the most time also spent the most time when working individually.

The higher quality code produced by pairs reduced test time and field support requirements. If time-to-market is a concern then pairing can get the job done in about half the time. Assigning work to two individual programmers means increased communication time with decreased quality.

In a NASA Langley report in 2001, a pair re-implemented an algorithm originally developed in 1997. The original solo programmer worked for 6 weeks to produce 2144 lines of code. The pair worked 3 programmer-weeks, implementing the same functionality in 866 lines of code, 403 lines of production code and 463 lines of test code. The original programmer did not write any test code and while he was experienced in the programming language, the pair was learning a new language.

A company in India reported that a prototype of a Voice-Over-IP project was done without pairing. The follow-on actual development was done with pairing. The actual project was more complex but showed significant increases in productivity and quality. Pairs produced 7.2 KLOC/person-month compared to the original 5 KLOC/person-month. Pairs showed at unit test, 0.4 defects/KLOC compared to 5.34 defects/KLOC for the original and at system integration and 0.2 defects/KLOC compared to 2.3 defects/KLOC for the prototype.

Your first reaction might be to think that this is something that would only benefit the project or company if both people were experts, because then both can contribute equally. On the other hand, some of you might think, "There’s no way two veteran, introverted programmers are going to work together!"

There are many different kinds of pairs—each with benefits and consequences in given situations. The task at hand should define the pair. If you need a complex algorithm, put two experts on it. If the task is routine, put two novices on it.

Many resist pairing—it means breaking old habits and being more communicative and collaborative. But among those who try it, almost all decide it is better than working alone. Often resistance comes from misconceptions on the part of those who have never tried it, based on reasonable and rational, but incorrect, assumptions.

Pairing seems to work well with almost any partners—with one exception—someone with excess ego and/or a "my way or the highway" attitude. Other than that, people seem to be able to work with almost anyone.

Pairing makes us work differently. Seven synergistic behaviors have been identified that just appear naturally. Pairs get their jobs done faster and better and leave programmers feeling better. In fact, an eighth behavior could be added—pair fun. In a recent survey when asked, "What have you found beneficial about pairing?" The most common response was, "It’s a lot more fun!"

(1) Pair Pressure. Pairing puts positive pressure on members to work harder and smarter because they don’t want to let their partners down. When you’re alone, you can intentionally or unintentionally waste time. The presence of another person can draw us out of our tired, disgruntled mood. We don’t want to let the other person down or we’re embarrassed to disappoint him or look like a slacker.

(2) Pair Negotiation. Pairs arrive at the best solution by collaborating. This is supported by research in an area of psychology called distributed cognition. Each partner brings his own skills, abilities, and viewpoint, but both share the same goal. The partners jointly attack the problem, each with his own view, and must negotiate the solution. They evaluate more alternatives than either would have considered alone. Typically a person working alone pursues his first approach.

Research confirms that collaboration always outperforms the average and almost always exceeds the best possible solution. In other words, the fear of the pair reaching the lowest level is unfounded. Studies show that the longer the collaboration, the better the decisions.

Pairs report that together they can evolve solutions to seemingly impossible problems. They share their knowledge and energy, chipping away at the problem. While the driver is implementing part of the problem, realizing that he will ultimately come to a dead end, the navigator, while watching the driver at work, is continually thinking ahead.

(3) Pair Courage. Getting an OK from a partner gives us the confidence to do what we might be afraid to do alone. Pairing also gives us the courage to admit when we don’t know something. Alone, we tend to be embarrassed when we don’t know something and try to muddle through rather than ask for help—nearly half will exhibit this behavior.

(4) Pair Reviews. Inspections were introduced decades ago and have been shown in studies to be effective in removing defects, but developers don’t like inspections and generally don’t find them worthwhile. Many reviewers are unprepared and the process is short-circuited. We all know that we have "an almost infinite capacity for not seeing what we don’t want to see." We will ignore even the most glaring errors. While pairing, defect identification occurs constantly and can be an enjoyable part of the process.

(5) Pair Debugging. An effective way to solve problems is to just explain them to another person. The hearer doesn’t have to understand much, just ask questions, or not. This approach is described by Charles Weir and James Noble in a pattern called Cardboard Consultant. It even works with a pet! When this pattern is applied in a pair, the effect is magnified as a result of the other synergistic behaviors and problems are more easily solved.

(6) Pair Learning. Knowledge of all kinds is constantly being passed between partners, as they take turns being teacher and student. Even unspoken skills and habits cross between pair members.

(7) Pair Trust. Pairing allows the members to open up to the knowledge and experience of others and see that the end result is far better than anything they could have produced on their own. This allows them to present their ideas in a more open setting. If pairs rotate, members get to know and trust others on the team.

These seven behaviors work synergistically together allowing one plus one to be greater than two—the results of the pair are greater than the results of each individually—and it’s a lot more fun!

I know that old habits are hard to break, but why not let go of some old habits for the benefit of the team and have more fun in the process. You’ll have someone to bounce off those good ideas and someone who’ll be bouncing good ideas off you. You’ve got someone whose work you can help improve and someone who’ll help you when you do something that’s not perfect. If you decide to try pairing, let me know how it worked for you!

In a future article, I’ll present an interview with two developers at DDC-I who have been experimenting with pair programming. I will report on the results of a retrospective and share with you: (1) What worked well that they want to continue; (2) What should be done differently on the next project; and (3) What still puzzles them. Stay tuned!

Pair Programming Illuminated, Laurie Williams, Robert Kessler, Addison-Wesley, 2003.

About the Author
http://www.lindarising.org
risingl@acm.org

Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching as well as work in industry in telecommunications, avionics, and strategic weapons systems. She is the author of numerous articles and has published three books: Design Patterns in Communications, The Pattern Almanac 2000, and A Patterns Handbook. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in 2003. 

[ Back to Top ]