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). 1 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.

2015 in Review

The beginning of the year seems an appropriate time for looking back at the good and the bad of the previous year. Looking at the data to determine what things I want to continue doing or to develop and what I might want to change.

I had a lofty goal of publishing two posts per month for 2015. I ended the year with 21. Not bad, but I’m going to push my goal higher for 2016 and aim for three. Sometimes when I’m writing I become conflicted about the frequency with which to post. I don’t necessarily want to write about everything little detail. However, when I look back on the posts I have published I’m always happy that I put something out. Still I’d like to side on quality over quantity, so I’m ok if I don’t hit that goal.

Popular posts don’t mean much but they’re still interesting.

Most popular posts of 2015:

Three of those popular posts were time intensive to produce and I’m very proud of them. The other two solve specific problems for me and apparently for others as well. There were quite a few other time intensive posts that I’m proud to have written that just missed the top five but would make it in a top ten list. In summary, I’m happy that what I’m writing is getting some attention.

2015 marked a few big launches: In February I moved to publishing all my writing here instead of at that old blog. In October I launched an open source list of software testing conferences and workshops at and I’m delighted and surprised every time someone commits an update.

A few other tidbits about 2015:
  • Didn’t get to read as many books as I had originally planned to. Not sure if 2016 will be much of an improvement. Most of the books I read are non-fiction / reference and I know that will shift next year to more fiction / sci-fi. On the positive side, I read a lot of blog posts and articles!
  • I haven’t yet sent out the first email to the amazing people on my email list but that will happen soon! 2016 is the year! If you haven’t already, join the email list!
  • I realized I don’t like the layout of this site / template and want to change it’s look and feel. Maybe I’ll get to it in 2016?
  • I taught just a little bit of scuba diving but a lot of software testing. 2016 will be even more.