Mikhail Sudbin

Mikhail Sudbin
Chief Technology Officer at Advalange

Peer review is a commonly used practice in the software development world. Unarguably “Two heads are better than one” principle makes your product better. The main question is if the enhancement worth the price you pay for it. In the safety critical domain such as aerospace where reviews are mandatory, this issue is of current significance. DO-178C forces us to conduct reviews for merely every single item that is produced throughout the project lifecycle and consumes up to 30% of project efforts. Thus spending time for peer reviews in an effective and efficient manner is essential.

However, the intent lying underneath peer review sometimes becomes blurred, especially to a large and complicated aerospace project. Either review process is done for the sake of the process with the focus on production of formal review records. Or process becomes inefficient when people dig too deeply into the aspects that do not contribute in ending product quality.

Consider the following easy tips to keep the balance making your DO-178C review process more valuable and to control the time spent for review cycles responsibly:

Tip #1. Foster the right attitude.

Have you ever experienced anything similar to what I call “checkbox review” when all questions are marked with “passed” without any real check? I bet you have. Especially, when the deadline is close and management is pushing. Another case of the wrong attitude is “Correct it as I say” when a reviewer has much more authority or experience than an author does.

Always remember the following simple statement to avoid such a wrong attitude: “review is an independent qualitative opinion regarding compliance and quality of your outputs, not more not less. Every single word matters in this statement.

  • Review should be independent. Reviewer and author shall discuss findings and provide arguments, until agreement is reached rather than one of them enforces his opinion in a peremptory manner.
  • Review is always qualitative. You can never prove your views with 100% strict mathematical proof. There is always room for subjectivity.
  • Review is aimed to confirm or disprove that the output under review complies with the standards and procedures and fulfills the requirements against which it was developed. Review is neither a brainstorming meeting, nor a research session, nor training classes.

Tip# 2. Create the right checklist.

Peer review is deemed to increase product quality. Quality, however, is a very amorphous word. Everybody feels that understands what it is but almost nobody can express it in a short and quantitative manner. In the DO-178C world we are lucky to have more or less strict guidance to define the quality of the product.

  1. First, the product operation shall be safe.
  2. Second and complementary to the first, the product and process shall be compliant with the standards.
  3. Third and complementary to the first two, the product should fulfill intended functionality and shall not do anything unintended.
  4. Fourth and complementary to all above the product shall be maintainable throughout 30+ year’s period.

Always validate any review checklist against these principles. Make sure that your checklist is specific enough. It should contain questions regarding how exactly these principles are satisfied in a work product under review rather than if those principles are superficially satisfied. On the other hand, a checklist should not be too excessive. Concentrate only on what is vital. Having a 150-question checklist for a simple unit test is a sign that you are doing something wrong. Never ignore the feedback you receive from review participants. Reconsider the checklist if a reviewer is confused with what question to choose when relating a finding or if too many findings fall into the “other” category.

Tip# 3. Establish the right process.

Be sure that only relevant participants take part in the review and that their involvement is neither excessive nor insufficient. For the example with a unit test having two inspectors, one moderator and one facilitator will be exorbitant. However, such a team may not be enough for reviewing software architecture.

The flow of the review process is very important as well. Provide the team with a well-fit infrastructure to support data exchange between the participants and review records management to make it a favorite piece of project culture rather than annoying formal activity. Usually, configuration management systems are extended with peer review plugins to make the process fast, transparent and straightforward. Investment in convenient tool setup for reviews is a wise decision. What you  do not want to have is a “manual” process and record flow with review cover sheets looking like a “history book of the project”.

 

Taking after these three tips brings a powerful tool for project analysis in addition to making review process more adequate. The right checklists provide you with well-structured data taxonomy. The right attitude and the right participants provide confidence that data connected to those checklists is accurate and representative.  Statistical analysis will help you to figure out weak or poor defined aspects of your project besides the review process itself.

DO-178C requires reviews and no one can get by without it. It is your choice to make it for compliance solely or to get real benefits. The three tips will help you to make a wise decision and maximize cost\value ratio from your reviews.

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?

Welcome post from Mikhail Sudbin, Advalange CTO.

Mikhail Sudbin, Advalange CTODear friends,

In this welcome post I want to shed some light on my joining the Advalange organization. First, let me say a couple of words on my vision of software development and the safety-critical domain in particular. This will help to understand better what made me make this decision.

Revise your memory and compare the software industry in the early ’90s and now. Various frameworks and engines significantly changed the way application and solution software are developed. Just imagine if anybody tells you: “Every single line of code for this ERP system was written within these walls.” You would take it normally in 1995 but today you won’t believe it. New technologies are developing along with new methodologies. There was no such phrases as “scrum” or “application platform” 20 years ago.

The safety critical area is a little bit more conservative but now it is entering the new period of evolution and similar techniques come into play. As an example, look at integrated modular avionics and new approaches and challenges it brings to the aerospace domain. Organizations should accept the evolution and change accordingly to face it.

“Always be focused and keep in mind
how the result should look like.”

The organization I used to be working for was quite conservative and was not eager to catch on to the new trends. I was searching for the new opportunities when Evgeny proposed to found the new company. At first I was quite pessimistic. No solid background, no corporate culture, no proven structure… However, when we talked it over I saw that the idea could work. Let’s gather experienced, like-minded people and build a new entity. We can make “drawbacks” our strengths. Let’s build culture and infrastructure aimed at facing the new challenges. Our people are knowledgeable and creative enough to do it. There will be no bureaucracy or legacy constraints that other organizations face, and it will be a huge benefit.

We all sat together and discussed our positive and negative experiences of working with various organizations. It was quite a wide range of case studies: from Fortune 500 corporations with 10-year-long projects with thousands of people involved to tiny labs with a dozen people max. We came to the decision that often very few people know for what reason they are doing particular things, especially in big organizations. We definitely wanted to be different.

“Business process is a means encouraging
people to act and aim for results,
while the team is a core of Advalange.”

Thus, one of our main principles is “be focused.” You need to know what the result should look like. You need to put on the hat of the customer, manufacturer, user, vendor, and, at the very end, the hat of the engineer to figure it out. You need to understand how each particular task influences the result. Another principle that we agreed upon is that our world is not perfect. If you try to build a perfect product, you will fail. Even the famous gadget has its own drawbacks. Be a little bit more pragmatic: deliver the right result, spending the right amount of time and money.

Other key features of our new organization were based on these two principles. We accepted that people and teams should be the core aspect of our organization. Business processes should encourage people to act and aim for results. On the other hand, every single individual should commit to the principles and be tough enough to follow them. I was happy to know that the awesome group of cool professionals shares this point of view and we would be able to get the team together.

I did not doubt long and accepted the role of chief technology and process officer at Advalange. I think that this role is very close to the opportunity I was searching for. I believe the Advalange principles can be a sound basis of a unique corporate culture in the safety critical domain. I would be proud to prove that such a way of doing things can lead to building a solid and respectable organization. It will be a challenge and will definitely bring me to a new level of mastery.

Welcome message from Evgeny Rodin, Advalange CEO.

Evgeny Rodin, Advalange CEODear friends,

I’m delighted to greet you on our website and in our blog and let me start a series of posts from Advalange partners about the foundation of the company.

Advalange has been on air for a few months already, but I still keep asking myself if it’s real or not. Actually it was my dream. I had a desire to apply my knowledge and experience and create something new and different. Now I can say I’m a lucky person. I was fortunate to meet my Advalange partners. We share the same values and speak the same language. We had almost no discussions on what Advalange would be doing. Software development in the safety-critical areas was an obvious and reasonable choice supported by our core engineering team.

It is a hard time to start a new business, but the Advalange team, and I as a part of it, love challenges. We love aerospace and engineering. I believe it will outweigh all the issues and obstacles we’ll face. I’m sure that strong aerospace expertise and experience in performing embedded software and IT projects will help us taking off smoothly in this rough air.

As one of the means to deal with the obstacles, we chose sharing our knowledge with colleagues, partners and customers. And in this first post in our blog I want to tell you about the first challenge we ran into. After Advalange founders agreed on the services and markets, we had to figure out what will make us different from many other players. Now I can say we found it.

“Regulated mindlessness of actions
is a source of inefficiency.”

Since the beginning of my career 12 years ago, I’ve participated in a number of projects with companies of different sizes, regions, and history. Regardless of the project’s scope, complexity and schedule, many of them had a common feature, which I call “regulated mindlessness of actions”, when a process is performed just for the sake of process.

Software projects are getting bigger and more complicated following the demand for increasing complexity of the electronic equipment. In turn, more rules, procedures and regulations are created to manage larger numbers of similar and repetitive operations. At the same time, attention of corporations has been turning to the schedule performance due to demand for lower time-to-market and pressure from competitors. As a result, higher productivity has become very important even in intellectual work.

“Keep being critical even when
everything seems to work fine.”

In such an Indy-car race even high-class engineers forget that the improvement process slows or even dies as soon as you stop questioning and criticizing existing approaches and decisions. I was watching the great teams able to solve complex problems and to complete projects on time and fully according to the procedures and regulations. However, even members of those teams often failed to answer the following question: “What is the business value that you add to the project and to the customer by doing your particular tasks?” Teams keep working without a vision, and sooner or later their performance starts degrading.

When a project team stops being critical, the mass production approach wins. Project teams tend to unify what is not supposed to be unified and it gets especially dangerous when each single result of the same process is unique, which is fully applied to the software development.

Furthermore, any business-process improvements aimed at increasing the production rate can lead to the opposite result in the long run. It happens when a team fails to recognize what brings the real business value and needs to get improved. Breaking this conveyer trap becomes a long, complex and in some cases painful procedure, especially in large corporations.

“Continuous and persistent search
for meaningful work makes
a professional employee.”

There are methodologies and philosophies like Kaizen called to resolve such type of issues. A company can hire proven experts to audit existing business processes. The experts can advise and lead the process optimization. The danger comes at the implementation stage. In many cases implementation goes mechanically. Project teams are often told what to do, but don’t get clear understanding and acceptance of why they need to do it. Consequently, the same people perform new sequences of actions after the process is optimized and reset. But they didn’t have time to figure out why one or another aspect of the process has been changed. They were concerned about their personal performance, rather than about what is really valuable and what’s not. In such circumstances, the change to the process relaxes over time, often quite quickly. It accretes new unnecessary steps and “improvements” that may not bring any additional business value but allows teams to simplify the process that is not equal to make it efficient.

“Simplification doesn’t necessarily
increase the business value.”

I’m sure that meaningful awareness of the real business value that is brought by each particular task is not just a means of improved efficiency.  It is also an important motivation factor, the importance of which can’t be overestimated. Continuous and persistent search for meaningful intellectual work is what makes a professional employee, while a company that creates conditions for such research has higher chances of long-term successful development.

We put this important principle into the foundation of the Advalange system of corporate values. I’m sure that consistency in doing the job based on the common company values is an important prerequisite to successfully implementing a chosen strategy. And I really hope that openness, transparency and respect for each other – colleagues, customers and partners – will create the greenhouse conditions for sustainable Advalange growth and development.