I’m not sure how I came across the book Exponential Organizations (by Salim Ismail, Michael S. Malone & Yuri Van Geest) but it ended up on my library reservation list and was a fairly quick read. The book’s central theme is that new technologies allow for a new type of organization – the “ExO” (Exponential Organization) – that can out-achieve more traditional styles of company. The authors claim that:
An ExO can eliminate the incremental, linear way traditional companies get bigger, leveraging assets like community, big data, algorithms, and new technology into achieving performance benchmarks ten times better than its peers.
This blog post isn’t intended to be an in-depth review of the book which, although I found interesting, was far too laden with buzzwords to make it an enjoyable (or even credible) read at times. The content hasn’t aged well, as you might expect when it contains case studies of these hyper-growth companies – many of which went on to implode. A new study of ExO’s from 2021 will form the second edition of the book coming later in 2022, though.
The motivation for this blog post arose from the following quote (which appears on page 140 of the 2014 paperback edition):
One of the reasons Facebook has been so successful is the inherent trust that the company has placed in its people. At most software companies (and certainly the larger ones), a new software release goes through layers upon layers of unit testing, system testing and integration testing, usually administered by separate quality assurance departments. At Facebook, however, development teams enjoy the full trust of management. Any team can release new code onto the live site without oversight. As a management style, it seems counterintuitive, but with individual reputations at stake – and no-one else to catch shoddy coding – Facebook teams end up working that much harder to ensure there are no errors. The result is that Facebook has been able to release code of unimaginable complexity faster than any other company in Silicon Valley history. In the process, it has seriously raised the bar.
I acknowledge that the authors of this book are not well versed in software testing and the focus of their book is not software development. Having said that, writing about testing as they’ve done here is potentially damaging in the broader context of those tangential to software development who might be misled by such claims about testing. Let’s unpack this a little more.
The idea that “separate quality assurance departments” were still the norm when this book was written (2014) doesn’t feel quite right to me. The agile train was already rolling along by then and the move to having testers embedded within development teams was well underway. What they’re describing at Facebook sounds more in line with what Microsoft, as an example, were doing around this time with their move to SDETs (Software Development Engineers in Test) as a different model to having embedded testers focused on the more human aspects of testing.
The idea that “development teams enjoy the full trust of management” and “Any team can release new code onto the live site without oversight” is interesting with the benefit of hindsight, given the many public issues Facebook has had around some of the features and capabilities included within its platform. There have been many questions raised around the ethics of Facebook’s algorithms and data management (e.g. the Cambridge Analytica scandal), perhaps unintended consequences of the free rein that has resulted from this level of trust in the developers.
It’s a surprisingly common claim that developers will do a better job of their own testing when there is no obvious safety net being provided by dedicated testers. I’ve not seen evidence to support this but acknowledge that there might be some truth to the claim for some developers. As a general argument, though, it doesn’t feel as strong to me as arguing that people specializing in testing can both help developers to improve their own testing game while also adding their expertise in human testing at a higher level. And, of course, it’s nonsense to suggest that any amount of hard work – by developers, testers or anybody else – can “ensure there are no errors”.
While I can’t comment on the validity of the claim that Facebook has released complex software “faster than any other company in Silicon Valley history”, it doesn’t seem to me like a claim that has much relevance even if it’s true. The claim of “unimaginable complexity”, though, is much more believable; given the benefit of hindsight and the evidence that suggests they probably don’t fully understand what they’ve built either (and we know that there are emergent behaviours inherent in complex software products, as covered expertly by James Christie in his many blog posts on this topic).
The closing sentence claiming that Facebook has “seriously raised the bar” doesn’t provide any context, so what might the authors be referring to here? Has Facebook raised the bar in testing practice? Or in frequently releasing well-considered, ethically-responsible features to its users? Or in some other way? I don’t consider Facebook to be high quality software or a case study of what great testing looks like, but maybe the authors had a different bar in mind that has been raised by Facebook in the area of software development/delivery/testing.
In wrapping up this short post, it was timely that Michael Bolton posted on LinkedIn about the subject matter that is so often lacking in any discussion or writing around software testing today – and his observations cover this paragraph on testing at Facebook perfectly. I encourage you to read his LinkedIn post.
Rockin' and Testing All Over The World 