Argumentem ad novitatum – appeal to novelty – is the fallacy of saying that some mindset, position, or artifact is good because it is new, and newer must mean better. Argumentum ad novitatum is itself named in Latin because of the equivalently fallacious form of argument, argumentum ad antiquitatem; the old ways are inherently better.
If someone on your team comes in effusing about a new UI framework that was just published by a Silicon Valley unicorn to Github or the brand-new Y Combinator funded NoSQL database that the winners of TechCrunch Disrupt used to build their hack, it can be tempting to dismiss the idea of adopting it because newer doesn’t necessarily mean better. That we should choose boring technology. But there’s probably good intention behind the new tool, even if your colleague isn’t getting that over to you.
While you may be hearing about this shiny thing because it is new and exciting, that is probably not the only reason for its existence. Try to look past the excitement and empathise with the people who created it. What problem did they have, and what was it about existing solutions that didn’t work for them? Were they really making a new tool so that it would be newer than the existing tools, or did it do something the others did not? Now, is that something you can use?
This empathy is often absent, particularly when the community around an idea gets larger and enters the main stream. David Chapman identifies three categories of people in the development of a subculture: geeks, MOPs, and sociopaths. The geeks are the people who love the thing, care deeply about it, understand it in great detail, and love exploring it, creating it, or talking about it.
As the geeks explore and share their interest, they attract a community of MOPs (short of Members Of Public). MOPs are less interested in the minutiae and the philosophy, but still want to be associated with the subculture and want to be seen to be associated with it. They adopt its imagery and lexicon, while putting less effort into creation and comprehension of the core parts of the scene. They also provide useful validation (financial or emotional) for the geeks, by legitimising the scene and boosting its numbers.
When the sociopaths turn up, they are like human cuckoos, displacing the geeks from the centre of the scene in order to reap the rewards that come from selling to the MOPs. They are people who are not fanatics about the basis of the scene, and simply see the opportunity to be had in exploiting its existence. They dilute the core principles on which the geeks founded the scene, even to the point where the geeks leave and the subculture is hollowed out.
While Chapman’s article was about scenes and subcultures of the late 20th century, like punk music or the fruitarian diet, we can see parallels in some of the big movements of the software industry.
Richard Stallman and others initiated the Free Software movement in the 1980s based on a political or ethical notion that the people buying and operating computers should have certain freedoms to use them for any purpose, and to study, share, and improve the software employed on those computers. Two motivating events, according to Stallman, were the acquisition by his department at MIT of a Digital Equipment Corporation computer and a Xerox printer. Both ran proprietary software, and both had room for improvement. But here they were, in the Artificial Intelligence lab at a prestigious university, and neither could be improved by the local skilled and motivated programmers because the vendors believed that they owned the software and that the people trying to use their products did not. Stallman came to realise that he disagreed, and that “ownership” of software was anathema.
Later, the term “Open Source” was created by Christine Peterson in a group deliberately seeking to take the activities involved in Free Software and make them palatable to businesses, by removing the ideological connotations attached to the Free Software term. They instead associated the idea of sharing source code with Open Systems, an economic movement promoting interoperability between decidedly proprietary software products like OpenStep and OpenVMS. So it was that Netscape Navigator (the browser that was the predecessor to Firefox) became the world’s first Open Source project, after Eric S. Raymond convinced the development team to use that term.
Now, plenty of pundits will tell you that the Open Source ecosystem has never been healthier, yet Richard Stallman’s problems remain unaddressed. I am writing this article surrounded by computers – the one I’m working at, the one in the audio system it’s connected to, the ones in my phone and my wristwatch; and, yes, just like Stallman, the one controlling my printer. Despite the apparent success of open source, not one of those systems is fully open for me to use, study, share and improve.
To me, Free Software has the hallmarks of a late-stage subculture: the scene has been popularised, the surface ideas taken and turned into mainstream businesses. All that is left is the hype: we are open! Buy our open thing!
Another example: Scrum is currently such a popular anti-hero for showing how the Agile movement “went wrong” that Agile manifesto signatory Ron Jeffries complains about “Dark Scrum” and is even motivated to use scare quotes on the word “Agile”. Undoubtedly, the people at that Snowbird meeting two decades ago were creators and fanatics, keen to “[uncover] better ways of developing software by doing it and helping others do it.” But what of the legion of today’s Certified Scrum Masters and Agile consultants? Do they all have the same deep understanding? Does such an understanding even help now, or is the context of today too far removed from the context of Snowbird in 2001 for the same principles and practices to be relevant? Are they geeks, MOPs, or sociopaths?
Regardless of the answers to these questions, the world’s companies are not done being told that they are all software companies; that software is eating the world; that they are long overdue an “agile transformation” and that if they are failing it is because they are not agiling hard enough.
You pick up the allegorical, digital equivalent of a programming industry trade journal and read that your monolithic backend server is yesterday’s news. It’s 20th-century technology. The new hotness is microservices – breaking each component in your server out into a separate deployable service with its own interface. This, they tell you, is Service-Oriented Architecture done right. Is that relevant? Are the benefits of separating the components worth the increased complexity of deployment, or the performance impact of so many API calls per external request? Only you and your team can answer those questions, but that does not mean that the authors of the article on microservices know nothing that is relevant to your situation.
Whether it’s last decade’s big idea or this morning’s new Javascript framework, it was created by someone motivated to solve a problem they saw. Dismissing these things out of hand – the old because it is yesterday’s news, the new because it is untried and immature – means missing out on fresh perspectives from which to view your work. As with many situations, application of empathy will go a long way. Empathising with the creators of the ideas or projects will help you to see what the world looks like from their position, why they solved things the way they did, and whether that is relevant to your own context. Maybe you agree that the problem they saw is real, but it isn’t one that you have. If so, you have not found a tool that you can use – but you have learned more about your situation and somebody else’s. And that understanding is where design happens.
Cover photo by Dmitry Ratushny on Unsplash.
