Mikhail Sudbin

Mikhail Sudbin
Chief Technology Officer at Advalange

Pair Programming Is Not Just for Software Tasks

Two heads are better than one is a lesson well learned from childhood fairy tales. Two pilots in an airplane, two cops in a patrol car, two persons to open a bank vault prove this concept.  Pair programming works off this idea as well. In pair programming two engineers share a single workstation to produce a software code. One is a driver who does the typing. The other is an observer who conducts ad-hoc peer review and oversight. They switch roles frequently. Pair programming is widely accepted as a valuable practice in Agile development.

Nevertheless, pair programming does not exclusively belong to software development. It can be tailored to many other aspects of your work. Advalange implements this technique in several ways:

  • Presentations
    Some people have an artistic talent to present from scratch. However, many struggle to  prepare a good presentation especially for a topic which is not 100 percent clear. In such a case, we usually make a skeleton of the presentation in pair programming style. Defining S.M.A.R.T. goals, deciding what to explain and what to show appears much easier when you immediately validate your idea against your teammate. When your run out of ideas, your partner may have one more idea in reserve. This raises the creation tempo.
  • Analytics
    Sometimes an analytical task is obvious. Other times the number of parameters to analyze is overwhelming. In this situation, making an analysis is like searching for a treasure chest in a misty swamp. While you are figuring out the next chain in a link your mate can quickly verify your hypothesis, make some fast side calculations or search for more information. This cuts off dead-end directions faster and keeps overall focus clearer. In addition, we often try to get the result by two different methods concurrently. Matching numbers give us more confidence to proceed to the next stage.
  • Articles
    Like  the presentation example, you can validate your thoughts and statements before throwing them out to readers. This helps to avoid context trap: you know (or at least pretend to know) what you are talking about and can skip some important details. A reader out of context may be lost and misunderstand your words. I often ask colleagues to put on a reader’s hat and provide feedback. Wearing the writer and reader hats at the same time is not easy. Some doctors may even label you schizophrenic if you do it regularly. Another benefit of pair writing is ad-hoc style and grammar correction.
  • Planning
    Creating a comprehensive work breakdown structure is always a challenge. Sometimes a stupid mistake such as missed activity or inappropriate taxonomy results in sleepless nights and nervous overhead. While you focus on decomposing work domains to certain tasks, your mate keeps his eye on overall outcome and interactions between single tasks.

Obviously, a number of rules will make your pair work more efficient.

Rule #1: Respect your partner.

Your mate has a right to his own opinion. Educate him carefully rather than laugh at his ignorance. Remember that your goal is to achieve better results, not to criticize your fellow.

Rule #2: Trust your partner.

Never say “I don’t believe you.” If you doubt your partner, it is better to say: “I heard a different thing. Let’s double check it.” Also, let your partner finish his statement rather than interrupting him.

Rule #3: Be open-minded.

Remember that pair work aims to find the optimal way. Don’t fight for your opinion to the last breathe. You would rather dig into your buddy’s suggestions to figure out the best result. Be ready to accept that your initial idea failed.

Rule #4: Speak up.

Always comment what you are doing and why you are doing it this way. It is important that both of you talk. Do not convert pair work into a one-man speech. Do not chat. Plan short breaks every half hour to reflect. Though it seems obvious, this rule is hard to follow. You need to tune into each other for some time to find an optimal way of communicating.

Rule #5: Be focused.

Remember the goal of your pair activity. Don’t fall into brainstorming or a  discussion of overall philosophical questions of your work. We usually start with writing down our goal and vision of output. This helps guide us back to the intended direction.

Rule #6: Pair only what should be paired.

Pairing each single activity is a bad idea. In the presentation example, we pair only the semantic portion of presentation preparation. Formatting it in PowerPoint is always done by one person. Use pairing when one more idea, independent opinion, review, or validation may lead to a different direction.

 

Pairing helps get things done well. You can’t fall asleep or go and look into Facebook “just for a couple of minutes” when a teammate is staring at you.

We at Advalange trust in pairing. In our experience, certain tasks are done up to five times faster when done in pair programming style. You may agree or not but have you ever really tried to consistently pair non-programming tasks?

Mikhail Sudbin

Mikhail Sudbin
Chief Technology Officer at Advalange

Is continuous integration worth the price? Yes, I’m sure.

Software development teams from different industries recognize continuous integration as a valuable practice. Some treat it as a “must-have” piece of an effective life cycle. However, in safety-critical areas and in the aerospace domain, in particular, there is still strong resistance to implementing continuous integration. Some people may think that continuous integration cannot formally fit into DO-178B\C.  Some people may think that those agile things bring no practical value into strict and rigorous development process.

These fears are groundless and I can show you that a DO—178C project can benefit from continuous integration.

Continuous integration aims to pull testing activities inside the development cycle rather than saving them for last. This goal breaks down to the following tasks:

  • Integrate all software pieces to see how they fit each other;
  • Check for any  regression possibly introduced by recent changes;
  • Check the functionality of newly implemented changes (if applicable).

These tasks should be done frequently enough to allow removal of any bugs before moving to the next stage of the life cycle.

“Any DO—178C project can benefit
from continuous integration.”

You will need several prerequisites to implement continuous integration:

  • A version control system to store and retrieve project artifacts coupled with a build tool;
  • Automated tests and a test execution framework;
  • Means to analyze test results.

Luckily, DO-178 features of heavyweight development approach provide a solid base for all three requirements.

DO-178 mandates comprehensive configuration control and change management.
Every single change request and the resulting changes in artifacts should be segregated and tracked. Usually it’s only a matter of setting up a configuration management tool to automate the build process and see how each subsequent change fits into the previous build.

Requirements-based testing is one of the main ideas of DO-178 standard.
Usually different groups develop code and test cases concurrently. If test strategy is established and test tools and environment are set up, nothing prevents the test group from developing test procedures along with test cases. This means that when a code change is deployed, everything is ready for continuous integration and, more important, for continuous testing.

DO-178 requires establishing thorough traceability.
Usually every single function is traced to corresponding requirements. Test cases and procedures are traced to requirements as well. Trace matrices are stored in a well-structured way. Everything is in place to select an appropriate set of tests and run them against a code change. Trace matrix will also aid analysis: you can identify the broken parts almost instantly.

“DO-178 features of heavyweight
development approach provide
a solid base for continuous integration.”

Of course, this approach works well if testing is automated or at least semi-automated. Modern software testing toolsets from VectorCast, LDRA, Rational, and others provide a solid base for test automation. Model-based development environments open new horizons for continuous integration by software-in-the-loop and hardware-in-the-loop concepts. Even old school manual visual tests can be adjusted for continuous integration. A way to set inputs automatically almost always exists. Output from a screen can be recorded for further analysis. Thus, all tests, with few exceptions, can fit into the strategy: “Run automatically, when a change is ready, analyze results when needed.”

Compliance is one of the most important questions when you develop airborne software. Some people believe that every tool should be qualified for continuous integration. It is not true. The DO-178C standard states: “Tools that are used to eliminate, reduce, or automate software life cycle process activities, and whose outputs are not verified, need be qualified.” You may choose different strategies to fulfill the DO-178 requirements such as:

  • Automation and pass\fail selection functionality may be qualified’
  • Tools’ outputs may be reviewed;
  • A combination of qualification and reviews may be used.

“It is not true that
every tool should be qualified
for continuous integration”

You may also go a different way – separate continuous integration and certification tasks. You may conduct formal verification (a k a run-for-score) once at the end without using automation tools. If continuous integration is applied throughout the project, you would be sure that your code is in good shape and your tests are correct and complete. There is minimal risk of getting some sudden costly updates..

Since continuous integration is not mandated by certification authorities some may seek to avoid the additional cost. It’s your choice, but make it wisely. Time and resources spent during earlier stages of your project to introduce test automation and continuous integration will save money later. You’ll be rewarded with fewer bugs, , avoiding integration hell and decreasing the cost of changes in later stages of project (Beck’s curve). Or defer testing and pay the price closer to the project deadline as you fix all those cascaded bugs. Each single change will be a challenge under such conditions (Boehm’s curve). Look at those two curves and decide which one you would rather see in your project.

Beck’s curve

Beck's curve

Boehm’s curve

Boehm's curve