Coding Without a Net

Yahoo! has been in the news quite a bit over the last few years as it’s primary business of placing display ads slowly dies and it searches for new ways to grow and/or remain relevant. It’s hired new executives, lost new executives and made acquisitions. Plenty of people still use Yahoo! products like finance and email. According to Yahoo!’s advertising page every day some 43 million people come to visit its homepage alone.

The Article

In December, Spectrum magazine posted an article about Yahoo! eliminating it’s testing department with the tag line “What happens when you eliminate test and QA? Fewer errors and faster development…”

Yahoo isn’t the first big tech company to move away from (presumably) dedicated testing teams. Google has never had them relying instead on SETs (software engineers in test) to build out automation infrastructure and TEs (test engineers) to understand testing and build out tools (or something to this effect). ¹ Although it’s easy to question how much Google really cares about quality given it’s daunting task of dealing with such huge scale and demand and how often their services seem to go down or remain difficult to use. Microsoft did something similar a few years ago by moving towards a combined engineering approach with having everyone focused on the product. Alan Page, in particular, has talked about the fluidity of his role at Microsoft.

The most interesting idea from this article was how Yahoo! believed “coding with a net” was a good idea. Let’s assume “coding with a net” meant one team did some programming and another separate team was tasked with understanding those changes and testing for them. Most often this means please make sure we didn’t break something (regression testing) instead of help us understand what we don’t know (uncovering new information). That seems like a very narrow net, doesn’t it?

First, you choose to use one primary test technique (regression testing) out of the hundreds of available techniques. Two, those most responsible for building and ensuring the quality, the programmers, now have to wait until some the code is shipped to a different group until they can start getting feedback about what works and what doesn’t. That’s a very long time. Testers shouldn’t be used as gate-keepers; they should work together with programmers to understand as many aspects of quality as possible. The faster that can happen, the better!

My Experience

Article aside, my least favorite work experiences are those when I’ve been in a “siloed” or dedicated test team and away from the fast feedback of the rest of the development team. My favorite work experiences by far, including my current company, have me on the development team roaming around the product and trying to figure out how to test things, how to improve quality and constantly investigating the product. I’m the “quality guy” much like Alan describes here.

I do think testing helps and often you want a test specialist or a group of testers to help understand the product and pay attention the many different aspects of quality that your product might need to have. Eliminating testing or QA shouldn’t result in faster development (or much faster development) if the teams or roles are in alignment. My personal goal is to be an effective technical investigator, someone who understands quality (or at least spends a good deal of time thinking about it) and who is valuable to the team.

I guess I’m not a fan of “coding with a net”. I think the practice leads to dependency and gives people an excuse for building something bad in the first place. It’s important for the whole team to build quality.