<div dir="ltr">Thanks for sharing this, Brian! x-posting to teampractices</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 19, 2015 at 6:55 AM, Brian Gerstle <span dir="ltr"><<a href="mailto:bgerstle@wikimedia.org" target="_blank">bgerstle@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Short "case study" at LinkedIn [0]<br>
<<a href="http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality" rel="noreferrer" target="_blank">http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality</a>><br>
about how they cut release latencies by 80-90% by reversing the "ice cream<br>
cone of death" [1]<br>
<<a href="http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png" rel="noreferrer" target="_blank">http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png</a>>:<br>
<br>
There's one particular snippet that strongly resonates with what I've<br>
experienced at multiple jobs (emphasis mine):<br>
<br>
*Team ownership of quality*<br>
<br>
<br>
<br>
Quality is the responsibility of the *whole team*. Quality control is most<br>
> efficiently achieved if software quality is considered at *every step in<br>
> the development cycle*. A software quality process will benefit from an<br>
> appropriate distribution of test automation ownership between teams<br>
> cooperating in a software development effort.<br>
<br>
<br>
In other words: QA aren't the only ones responsible for tests. I would go a<br>
step (or several) further and explicitly suggest that testing needs to be<br>
considered at—or an integral part of—the  design & planning processes.<br>
Rich Hickey goes even further in his talk about "Hammock Driven Development"<br>
<<a href="https://www.youtube.com/watch?v=f84n5oFoZBc" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=f84n5oFoZBc</a>> (highly recommended: TL;DR;<br>
people start work before fully understanding the problem space).<br>
<br>
Things seem to be trending up at WMF, especially w/ the Web engineers' big<br>
strides in end-to-end testing.  However, as the article suggests, you need<br>
to attack the quality problem from both ends—perhaps even emphasizing unit<br>
tests (shortest feedback, cheapest, least fragile).<br>
<br>
0:<br>
<a href="http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality" rel="noreferrer" target="_blank">http://engineering.linkedin.com/developer-happiness/getting-code-production-less-friction-and-high-quality</a><br>
1: <a href="http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png" rel="noreferrer" target="_blank">http://engineering.linkedin.com/sites/default/files/InitialState-Fun.png</a>,<br>
thanks to Zeljko for introducing me to that fun term, much better than<br>
"upside-down pyramid"<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
EN Wikipedia user page: <a href="https://en.wikipedia.org/wiki/User:Brian.gerstle" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/User:Brian.gerstle</a><br>
IRC: bgerstle<br>
_______________________________________________<br>
Wikitech-l mailing list<br>
<a href="mailto:Wikitech-l@lists.wikimedia.org">Wikitech-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/wikitech-l" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/wikitech-l</a></font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Arthur Richards<div>Team Practices Manager</div><div>[[User:Awjrichards]]</div><div>IRC: awjr</div><div>+1-415-839-6885 x6687</div></div></div>
</div>