{"id":562947,"date":"2014-09-30T00:00:39","date_gmt":"2014-09-30T07:00:39","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/?p=562947"},"modified":"2019-01-31T16:04:39","modified_gmt":"2019-02-01T00:04:39","slug":"estimating-hidden-bug-count-part-2-3","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/research\/blog\/estimating-hidden-bug-count-part-2-3\/","title":{"rendered":"Estimating Hidden Bug Count \u2014 Part 2\/3"},"content":{"rendered":"<p><a href=\"https:\/\/www.microsoft.com\/en-us\/research\/blog\/estimating-hidden-bug-count-part-1-3\">Part 1: Introduction and Basic Theory ><\/a><\/p>\n<h3>Part 3: Harsh Reality<\/h3>\n<p>That simple logic is nice, but practice makes it questionable for at least two reasons:<\/p>\n<ol>\n<li>Bugs found by either of the parties are fixed. After that, another party gets no chances to find them again.<\/li>\n<li>Product development results in code changes and new code introductions, further obscuring the picture.<\/li>\n<\/ol>\n<p>The good news is that in \u201cclassic\u201d software with a clear notion of \u201cversion\u201d (such as an operating system or a browser) both effects could be accounted for.<\/p>\n<p>The 2<sup>nd<\/sup> one is easier. By shipping version 1.0 of the product to the customer you effectively create a nearly frozen snapshot of it affected only by bug fixes. External Researchers will be testing that version. Of course, Internal Engineering will be working with version 2.0 which is different. But it is usually quite easy to filter their discoveries (for analytical purposes) down to the codebase common with 1.0. So if we apply the method to the codebase that is shared between 1.0 and 2.0, we can work around issue #2.<\/p>\n<p>#1 is trickier. Intuitively it&#8217;s clear that shared bugs can still appear in a changing product if both parties hit the same bug while it&#8217;s active \u2013 i.e., between the moments it was found and fixed. But knowing the quantity of such discoveries requires more precise tracking of bug counts at each intermediate moment of time.<\/p>\n<p>And one of the ways to achieve that is to describe bug populations with a system of differential equations.<\/p>\n<p>The next few pages treat that subject. If you are not interested, just <a href=\"https:\/\/www.microsoft.com\/en-us\/research\/blog\/estimating-hidden-bug-count-part-3-3\/\">jump directly to the Step by Step Guide<\/a> where the results are applied.<\/p>\n<h4>Bug Population Dynamics: General Case<\/h4>\n<p>Let\u2019s introduce the following variables:<\/p>\n<ul>\n<li><strong>E<\/strong> is the count of externally found <strong>active<\/strong> (i.e., not fixed yet) bugs that are <strong>not<\/strong> Shared bugs (so they are reported only once and by external sources only)<\/li>\n<li><strong>I <\/strong>is the count of internally found active non-shared bugs<\/li>\n<li><strong>S<\/strong> is the count of active shared bugs, found by both internal and external entities. That does not include internal Duplicate bugs where the same bug is seen by two or more <strong>internal<\/strong> entities.<\/li>\n<li><strong>B<\/strong> is the total bug count in the system (obviously we are talking about some fixed class of them, e.g., memory corruptions)<\/li>\n<\/ul>\n<p>Each of them is a function of observation time <strong>t<\/strong> passed since version 1.0 of the product was released.<\/p>\n<p>We will assume that bugs are found and fixed with rates linearly proportional to their amount. While that is obviously a simplification, it is probably somewhat close to the reality, since when bug counts increase more developer resources are poured in to fix them.<\/p>\n<p>That will bring along a few more variables:<\/p>\n<ul>\n<li><strong>x<\/strong> is the rate of external bugs search and reporting per small unit of time (e.g., one month), relative to the total number of bugs. For instance, if x = 0.1 that mean Externals can find 10% of the bugs in a product in one month.<\/li>\n<li><strong>y<\/strong> is bugs discovery rate for internal engineering, defined in the same manner as <strong>x<\/strong>.<\/li>\n<li><strong>f<\/strong> is the rate of internal bug fixing relative to the total count of active bugs, per unit of time [i.e., <strong>f<\/strong> = <strong>-(dA\/dt)\/A<\/strong>, where <strong>A<\/strong> is the count of the active bugs].<\/li>\n<\/ul>\n<p>Strictly speaking, none of these variables are constants. They change over time and as bug counts change. But we need to start somewhere, so let&#8217;s use that model as a first order approximation.<\/p>\n<p>We will also assume that <strong>f<\/strong> is the same for all bugs regardless of whether they are internal or external. The case of significant difference could be reduced to the solution of uniform <strong>f<\/strong>, as will be shown later.<\/p>\n<p>In these variables, the dynamics of each bug category is described by the following system of differential equations:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565053\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/1588.20.png\" alt=\"\" width=\"429\" height=\"179\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/1588.20.png 429w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/1588.20-300x125.png 300w\" sizes=\"auto, (max-width: 429px) 100vw, 429px\" \/><\/p>\n<p>The first line says that active External bugs <strong>E<\/strong> are found with frequency <strong>x<\/strong> per year proportionally to the total bugs count <strong>B<\/strong> in the system, and are fixed with frequency <strong>f<\/strong> proportionally to their amount <strong>E<\/strong>, and sometimes also move away from External to Shared category when Internals find them, which happens with frequency <strong>y<\/strong>.<\/p>\n<p>The 2<sup>nd<\/sup> equation is the same but with respect to the Internal active bugs count <strong>I<\/strong>.<\/p>\n<p>The 3<sup>rd<\/sup> says that active Shared bugs are created when one party hits another&#8217;s existing active bugs, and destroyed by fixing with a common fix rate <strong>f<\/strong>. We assume here that internal sources don&#8217;t have knowledge of external bugs to check for duplicates before filing. That&#8217;s not exactly the case but is likely close to reality; if needed, a modification to account for that effect is relatively easy.<\/p>\n<p>Finally, the 4<sup>th<\/sup> equation describes the overall bug population, and states simply that the total bug count in the product is reduced when active bugs are fixed.<\/p>\n<p>There is really nothing of a rocket science behind solving that system, but it takes a few pages if done by hand on paper, so I\u2019ll spare you from that and will just write down the answer that shows how each bug category behaves over time:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565056\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4885.30-60.png\" alt=\"\" width=\"903\" height=\"765\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4885.30-60.png 903w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4885.30-60-300x254.png 300w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4885.30-60-768x651.png 768w\" sizes=\"auto, (max-width: 903px) 100vw, 903px\" \/><\/p>\n<p>where<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565059\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4466.Lanbthas.png\" alt=\"\" width=\"329\" height=\"150\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4466.Lanbthas.png 329w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/4466.Lanbthas-300x137.png 300w\" sizes=\"auto, (max-width: 329px) 100vw, 329px\" \/><\/p>\n<p>And <strong>B<\/strong><strong><sub>0<\/sub><\/strong> is the total initial bug count in the system.<\/p>\n<p>Hmm?\u2026<\/p>\n<p>This is ugly.<\/p>\n<p>Extracting <strong>B<\/strong><strong><sub>0<\/sub><\/strong> from that system is technically possible. You &#8220;just&#8221; fit those curves to the observed bug rates\u2026 in theory\u2026 and obtain miserable nonsense in practice because of the data noise, model imperfections, and unmanageable complexity.<\/p>\n<p>Fortunately, we don\u2019t need full precision here. In real life we often deal only with special cases \u2013 such as very short or very long observation times, or very high fix frequency, and so on. And it turns out that in this case it is possible to effectively \u201ctile\u201d most practically useful situations with those simpler special cases.<\/p>\n<p>So let\u2019s derive them from the general form.<\/p>\n<h4>Case A. Short Observation Times<\/h4>\n<p>At very short observation durations, such that <strong>t<\/strong> << <strong>1<\/strong>\/<strong>f<\/strong> and <strong>t<\/strong> << <strong>1<\/strong>\/(<strong>x<\/strong>+<strong>y<\/strong>), functions [30] \u2013 [60] could be expanded into low-order time series, and then it is possible to show that:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565062\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5226.image012.png\" alt=\"\" width=\"383\" height=\"42\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5226.image012.png 383w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5226.image012-300x33.png 300w\" sizes=\"auto, (max-width: 383px) 100vw, 383px\" \/><\/p>\n<p>Since nobody prevents us from declaring t = 0 at any arbitrary moment of product lifetime, this means a simple and very powerful thing: as long as there are statistically enough <strong>active<\/strong> bugs of Internal, External, and Shared category <strong>opened far less than 1<\/strong>\/<strong>f time ago<\/strong>, the total bug count in the system can be estimated at the current moment of time as simply as:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565065\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/6862.image013.png\" alt=\"\" width=\"170\" height=\"46\" \/><\/p>\n<p>This works regardless of the frequency of product fixes and (as will be shown later) even if there is an asymmetry between fix rates for internal and external bugs.<\/p>\n<h4>Case B. Long Observation Times<\/h4>\n<p>At very long observation times such that <strong>t<\/strong> >> <strong>1\/f<\/strong> and <strong>t<\/strong> >> <strong>1<\/strong>\/(<strong>x<\/strong>+<strong>y<\/strong>) most of the bugs found are fixed, so there are very few (if any at all) of them in the active state suitable for use in expression [80].<\/p>\n<p>However, <strong>fixed<\/strong> bugs of each category will probably be numerous. Can we use their counts instead?<\/p>\n<p>Let\u2019s call them <strong>E<\/strong><strong><sub>f<\/sub><\/strong>, <strong>I<\/strong><strong><sub>f<\/sub><\/strong>, and <strong>S<\/strong><strong><sub>f<\/sub><\/strong>\u00a0\u2014 similarly to the corresponding active categories (index \u201cf\u201d stands for \u201cfixed\u201d). Each of those is obtained by integrating the corresponding active bug fixes over time, e.g.:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565068\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5545.image014.png\" alt=\"\" width=\"208\" height=\"49\" \/><\/p>\n<p>Using these variables and simplifying the full solution for the case of <strong>t -> \u221e<\/strong>, one can show that<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565071\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/3264.image015.png\" alt=\"\" width=\"209\" height=\"48\" \/><\/p>\n<p>where<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565074\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/7183.110-120.png\" alt=\"\" width=\"202\" height=\"162\" \/><\/p>\n<p>[And estimates for <strong>x<\/strong> and <strong>y<\/strong> could be used to verify if indeed <strong>t<\/strong> >> <strong>1<\/strong>\/(<strong>x<\/strong>+<strong>y<\/strong>)]<\/p>\n<p>The relation between the current bug count <strong>B(t)<\/strong> and the initial one <strong>B<\/strong><strong><sub>0 <\/sub><\/strong>is:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565077\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/0447.image018.png\" alt=\"\" width=\"254\" height=\"22\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/0447.image018.png 254w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/0447.image018-240x22.png 240w\" sizes=\"auto, (max-width: 254px) 100vw, 254px\" \/><\/p>\n<h4>Case C. Sufficiently High Fix Rate<\/h4>\n<p>When <strong>f<\/strong> >> <strong>(x+y)<\/strong> another useful simplification arises for times such that <strong>t<\/strong> >> <strong>1\/f<\/strong>:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565080\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/8625.140-160.png\" alt=\"\" width=\"508\" height=\"194\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/8625.140-160.png 508w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/8625.140-160-300x115.png 300w\" sizes=\"auto, (max-width: 508px) 100vw, 508px\" \/><\/p>\n<p>And then<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565089\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5047.170-180-1.png\" alt=\"\" width=\"377\" height=\"159\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5047.170-180-1.png 377w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/5047.170-180-1-300x127.png 300w\" sizes=\"auto, (max-width: 377px) 100vw, 377px\" \/><\/p>\n<p>with <strong>x<\/strong> and <strong>y<\/strong> provided by [110] and [120].<\/p>\n<p>This set of simplifications actually covers (mostly) all of the problem space. Indeed:<\/p>\n<ol>\n<li>If there is statistically significant number of active bugs in the product, expression [80] approximately solves the problem, since we can declare <strong>t<\/strong> = 0 at any moment of time.<\/li>\n<li>If not, but there is statistically significant number of fixed\/closed bugs in the product that means the observation time is far greater than typical fix time. In other words, we are in the <strong>t<\/strong> >> <strong>1\/f<\/strong> Since most bugs are in the fixed rather than active state that also means <strong>f<\/strong> >> <strong>(x+y) <\/strong>and expressions [170] and [180] provide the answer.<\/li>\n<li>In other cases there are either not enough bugs to make a call, or we are in the &#8220;narrow&#8221; intermediate time window of <strong>t<\/strong> \u2248 <strong>1\/f<\/strong>. We should either wait, or use the full solution [30]-[60].<\/li>\n<\/ol>\n<h4>Case D. Asymmetric Fix Rate<\/h4>\n<p>Situations when fix rates for internal and external bugs are significantly different are conceivable. How would our logic work for them?<\/p>\n<p>Let <strong>f<\/strong> be the fix rate of internal bugs, <strong>\u03b1f<\/strong> \u2013 fix rate of external bugs, and <strong>\u03b2f<\/strong> \u2013 of shared bugs. System [20] becomes then:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565092\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/6406.190.png\" alt=\"\" width=\"409\" height=\"172\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/6406.190.png 409w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/6406.190-300x126.png 300w\" sizes=\"auto, (max-width: 409px) 100vw, 409px\" \/><\/p>\n<p>Technically, it could be solved from scratch, but we can avoid that by making variable substitution:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565095\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/2364.200.png\" alt=\"\" width=\"339\" height=\"88\" srcset=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/2364.200.png 339w, https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/2364.200-300x78.png 300w\" sizes=\"auto, (max-width: 339px) 100vw, 339px\" \/><\/p>\n<p>and introducing an intermediate variable<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565098\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/6607.image030.png\" alt=\"\" width=\"136\" height=\"21\" \/><\/p>\n<p>That would result in the solutions of the same form as [30] \u2013 [60] with the following input variable replacements:<\/p>\n<p>For <strong>E<\/strong>(t): <strong>t<\/strong> -> <strong>\u03b1t<\/strong>, <strong>x<\/strong>-> <strong>x\/\u03b1<\/strong>, <strong>y<\/strong>-><strong>y\/\u03b1<\/strong>\u00a0\u00a0\u00a0 [210]<\/p>\n<p>For <strong>S<\/strong>(t): <strong>t<\/strong> -> <strong>\u03b2<\/strong>t, <strong>x<\/strong>-> <strong>x\/\u03b2<\/strong>, <strong>y<\/strong>-><strong>y\/\u03b2<\/strong>\u00a0\u00a0\u00a0 [220]<\/p>\n<p>The short-term estimate then is exactly the same as [80] (i.e., not sensitive to the asymmetry):<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565101\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/3513.image013.png\" alt=\"\" width=\"170\" height=\"46\" \/><\/p>\n<p>Long-term is more difficult because sufficiently high fix rate discrepancy may cause a situation where ft << 1 while \u03b1*ft >> 1 at the same time. Technically, the answer would need to be derived from full case [30]-[60], but there is one potential alternative here.<\/p>\n<p>That is to consider <strong>internal<\/strong> product version as the primary target, with <strong>f<\/strong> being the frequency of <strong>internal<\/strong> fixes, and <strong>E<\/strong> meaning not all externally reported bugs but only those that affect the internal product version currently in development. If fix rate discrepancy is smaller for the internal version (which is probably more reasonable to expect), long-term estimates [170]-[180] may still be applicable within that interpretation, provided the following changes in variables interpretations:<\/p>\n<ul>\n<li><strong>f<\/strong> is the frequency of internal fixes for bugs of internal origin<\/li>\n<li><strong>E <\/strong>is the count of those externally reported bugs that affect the internal product version currently in development<\/li>\n<li><strong>B<\/strong> is the count of those bugs in internal (2.0) version that affect external (1.0) version<\/li>\n<\/ul>\n<p>Also the expressions for <strong>x<\/strong> and <strong>y<\/strong> in this case change to<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-565104\" src=\"https:\/\/www.microsoft.com\/en-us\/research\/wp-content\/uploads\/2014\/09\/7215.240-250.png\" alt=\"\" width=\"237\" height=\"150\" \/><\/p>\n<p><a href=\"https:\/\/www.microsoft.com\/en-us\/research\/blog\/estimating-hidden-bug-count-part-3-3\/\">Part 3: Flowchart Summary and Limitations ><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Part 1: Introduction and Basic Theory > Part 3: Harsh Reality That simple logic is nice, but practice makes it questionable for at least two reasons: Bugs found by either of the parties are fixed. After that, another party gets no chances to find them again. Product development results in code changes and new code [&hellip;]<\/p>\n","protected":false},"author":39507,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"msr-url-field":"","msr-podcast-episode":"","msrModifiedDate":"","msrModifiedDateEnabled":false,"ep_exclude_from_search":false,"_classifai_error":"","msr-author-ordering":null,"msr_hide_image_in_river":0,"footnotes":""},"categories":[194475,194488,194489],"tags":[216749,187057,186414,234968],"research-area":[13563,13560,13558],"msr-region":[],"msr-event-type":[],"msr-locale":[268875],"msr-post-option":[],"msr-impact-theme":[],"msr-promo-type":[],"msr-podcast-series":[],"class_list":["post-562947","post","type-post","status-publish","format-standard","hentry","category-database-data-analytics-platforms","category-program-languages-and-software-engineering","category-security","tag-bug-checking","tag-data-science","tag-security","tag-software-bugs","msr-research-area-data-platform-analytics","msr-research-area-programming-languages-software-engineering","msr-research-area-security-privacy-cryptography","msr-locale-en_us"],"msr_event_details":{"start":"","end":"","location":""},"podcast_url":"","podcast_episode":"","msr_research_lab":[],"msr_impact_theme":[],"related-publications":[],"related-downloads":[],"related-videos":[],"related-academic-programs":[],"related-groups":[],"related-projects":[],"related-events":[],"related-researchers":[{"type":"guest","value":"eugene-bobukh","user_id":"562986","display_name":"Eugene Bobukh","author_link":"<a href=\"https:\/\/www.linkedin.com\/in\/eugenebo\/\" aria-label=\"Visit the profile page for Eugene Bobukh\">Eugene Bobukh<\/a>","is_active":true,"last_first":"Bobukh, Eugene","people_section":0,"alias":"eugene-bobukh"}],"msr_type":"Post","byline":"<a href=\"https:\/\/www.linkedin.com\/in\/eugenebo\/\" title=\"Go to researcher profile for Eugene Bobukh\" aria-label=\"Go to researcher profile for Eugene Bobukh\" data-bi-type=\"byline author\" data-bi-cN=\"Eugene Bobukh\">Eugene Bobukh<\/a>","formattedDate":"September 30, 2014","formattedExcerpt":"Part 1: Introduction and Basic Theory &gt; Part 3: Harsh Reality That simple logic is nice, but practice makes it questionable for at least two reasons: Bugs found by either of the parties are fixed. After that, another party gets no chances to find them&hellip;","locale":{"slug":"en_us","name":"English","native":"","english":"English"},"_links":{"self":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts\/562947","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/users\/39507"}],"replies":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/comments?post=562947"}],"version-history":[{"count":11,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts\/562947\/revisions"}],"predecessor-version":[{"id":565143,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/posts\/562947\/revisions\/565143"}],"wp:attachment":[{"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/media?parent=562947"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/categories?post=562947"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/tags?post=562947"},{"taxonomy":"msr-research-area","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/research-area?post=562947"},{"taxonomy":"msr-region","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-region?post=562947"},{"taxonomy":"msr-event-type","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-event-type?post=562947"},{"taxonomy":"msr-locale","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-locale?post=562947"},{"taxonomy":"msr-post-option","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-post-option?post=562947"},{"taxonomy":"msr-impact-theme","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-impact-theme?post=562947"},{"taxonomy":"msr-promo-type","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-promo-type?post=562947"},{"taxonomy":"msr-podcast-series","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/research\/wp-json\/wp\/v2\/msr-podcast-series?post=562947"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}