Assignment B: Software engineering process paper
– Length: 1500 words
– ACM format, MS Word
– Reference
• All references must be cited
• Must include specific references from at least three books related to the development approach being described
– Paper must reference the transcript
– The paper should compare the approaches. Identify strengths and weakness of different approaches and suggest at least one process improvement for the interviewee.
一点点我对作业的理解：根据下面的采访资料，写1500字文章，下面采访是和一个软件工程师的对话，主要问到了工程师工作过程中遇到bug的故事/策略。前面部分提到了两个他们预防bug的典型策略，最后又提到一个没有解决bug而失败的案例。 所以文章是需要评论这3个策略/故事，说说他们优缺点（或者一般开发里防止bug方法的讨论），并且可以为最后那个失败案例提出一个好的预防方案。这文章需要尽量引用一些软件开发的书，当然我不强求。可以谈谈test-driven development 和behavior-driven development这些。
Interview transcript
Me: Good morning, Jonathan. How are you doing today?
Jonathan: I am good. Thank you.
Me: Today I would like to have an interview with Jonathan to talk about bug escape stories. Jonathan is a 5G/NR developer at Ericsson. He has been in the industry for almost 10 years. And he has contributed lots of features to simulations projects. Currently he is working on a simulator written in C++. Thank you so much for helping out my interview.
Jonathan: No problem, thank you for having me.
Me: So let’s go straight to our topic! I want to ask you three examples of “bug escape”: one typical example, one success example, and one failure example. First of all, could you explain what’s the typical strategies for you or your organization to prevent “bug escape”?
Jonathan: Yes, sure. So my job mainly involves in writing Link Level simulation code. For this Layer 1 type of simulation, it’s like a signal processing chain, the output at each stage is pretty predictable. A typical strategy to avoid bugs is to compare intermediate outputs with 3rd parties. This may help us discover functionality bugs. Even though this is not a formal way to purposely debug, at the end of the day, we want to collaborate with these 3rd-party companies to sell our products. Therefore it is important to work closely with them, like define test cases with UE vendors and UE tools company together.
Me: Hmm, I see. It sounds like a double-check mechanism to check bugs even though it’s not the primary way of checking bugs. Can you also give me a detailed example of how your team makes sure to not let bugs escape in the development cycle? Maybe a success example?
Jonathan: Yes. Apart from the strategy I just mentioned. Ericsson has all kinds of gating tests before a commit gets pushed to the master branch. We manage our performance results cautiously. Sometimes we have new commits impact the performance and functionalities. Even though the regression test pass, we still look at it carefully. Like the KPI test you worked on, we could use it to monitor the performance change. So if this is the case, we will check the commit or contact the developer. We sometimes also use “git blame” to find out who the developer is that wrote the code caused the performance change. We understand whether the performance change makes sense, or is expected, and then we can accept the commit.
Me: Got it. Multiple tests have been set up to protect the codebase’s quality. This definitely has a positive impact on preventing “bug escape”. Now here comes the interesting question: having all these useful testing and double-checking happening, is there still a case where the “bug escape” happened and end up giving bad influences, maybe in later stage of development or in production?
Jonathan: Ok, ehh, on top of my mind, I can’t think of any now that happened to me. I think there is a story I heard that happened in another team. So you know there are many existing C++ libraries and they are well maintained and well documented. Here at Ericsson developers also write libraries for internal use, but sometimes we give similar names to different libraries. So there was a time that developers were communicating and suggesting to use one library. Somehow The other developer ended up using the library not suggested by his colleague but the one has a similar name. These two libraries have similar functionalities but also have different ways to use or call them. After a long time, people realize that the code works not as expected. When they found out that they used the wrong library, they also found out that the structure and code followed by it have to be greatly changed because of the different library usage.
Me: Oh, that’s unfortunate. So what bad impacts it caused, what happened later on, like wasting lots of time?
Jonathan: Yes, they had to spend lots of time rewriting and restructuring. The project deadline was pushed.
Me: Ok! Thank you Jonathan for sharing all these stories. That’s all of my questions. And Thank you so much again for helping out me do the interview.
Jonathan: No problem. It’s my pleasure.