Ben Scofield

Summarized using AI

Great Developers Steal

Ben Scofield • February 02, 2012 • Burbank, CA

In the talk titled "Great Developers Steal," Ben Scofield explores the concept of intellectual borrowing in software development, drawing parallels to music. He introduces the idea that great developers, like great artists, build upon existing ideas rather than create entirely new concepts from scratch. This discussion revolves around three main forms of borrowing in music: sampling, influence, and covers, which are analogously applied to software development.

Key points discussed include:
- Sampling: This method involves taking snippets of existing music, akin to using libraries in software, where developers integrate other people's code into their projects. An example is the work of Girl Talk, who masterfully combines samples into new compositions.
- Influence: Comparison is made to how musicians like Jimi Hendrix inform the work of others. In software, similar patterns arise when developers adopt ideas from various frameworks, as seen in the evolution of unit testing tools like JUnit derived from Smalltalk programming.
- Covers: These are similar to porting concepts in software; they can be faithful or poorly executed adaptations of established ideas. A good example is NUnit, which is critiqued for not fully translating the essence of JUnit into the .NET context.

The session emphasizes the importance of understanding and interpreting outside influences. Scofield highlights how borrowing can enhance creativity and problem-solving in programming. He mentions significant developments like BDD (Behavior Driven Development) and how frameworks often share lineage, driving innovation through cross-pollination of ideas.

He encourages developers to seek ideas from various programming languages and frameworks, describing this practice as a necessary form of adaptation and education in the developer's journey. Scofield concludes by underscoring the necessity of borrowing and adapting rather than literal copying in lifeblood of creativity in software. By shifting perspectives from stealing to adaptation, developers can leverage external innovations to solve challenges effectively.

Great Developers Steal
Ben Scofield • February 02, 2012 • Burbank, CA

If you take a look at software today, you'll see more smart people building things than there ever have been before. The problem? They're all working in different languages, on different platforms, with different concepts. To take advantage of the full breadth of work that's being done, we need to stay on top of things happening in other communities, and we need to bring good ideas back to Ruby. In this session, we'll look at how to identify great code and concepts, and how to bring them back to our community.

LA RubyConf 2012

00:00:23.920 Okay, so the title of this talk is "Great Developers Steal," and I'm sure all of you are familiar with the quote, "Good artists copy; great artists steal," which is attributed to Pablo Picasso, Banksy, and many others. The reason that this quote is interesting, and the reason it gets repeated so often, is because we have these intrinsic associations with the words used. We think that stealing is bad, so if it's a great artist, why are they stealing? Is it plagiarism? Is it outright copying? Is it forgery? The interplay between what these words mean in common usage and what they imply in this specific context is what makes this quote intriguing. I hope that after this talk, you'll understand how this applies to us in software development.
00:00:54.680 Before I get into that, we need to talk a little bit about music and how stealing works in that realm. There are three main ways to steal in music: sampling, influence, and covers. Let’s begin with sampling. Sampling is as close to stealing music as you can get unless you actually go and steal someone's digital masters and claim them as your own. Sampling is the practice of taking a chunk of a piece of music and incorporating it into another piece of music. A master of this today would probably be Girl Talk. There was an infographic in Wired about a year ago that broke down by time signature what samples were used in Girl Talk's songs, which is fascinating.
00:01:28.119 You can see that, for example, Beyoncé is sampled from 0 to 11 seconds, DJ Snippet from 0 to 21 seconds, and there are overlaps with Bill Collins' music. It’s an amazing feat to take these tiny snippets and assemble them into a new piece of art. Yet, if you think about it, there is actually no sound in this song that Girl Talk created; it all comes from other people’s works. He's essentially stolen these little pieces from elsewhere. There are numerous legal issues surrounding sampling, but it remains a fascinating phenomenon.
00:02:05.360 The least direct form of stealing, I think, is influence. Look at artists like Jimi Hendrix, The Beatles, Ella Fitzgerald, or Frank Sinatra; their influences have shaped vast swaths of the music landscape. Ask any great guitarist, and they will likely credit Hendrix as one of their influences — someone they’ve studied and replicated in their solos. Jazz musicians still try to replicate the incredible solos performed by others just to capture the underlying feeling and make it part of their unique style. This isn’t about stealing the exact notes; it’s about borrowing the essence and style, making it your own.
00:02:43.600 Finally, let's discuss covers. Covers can be tricky to define. We intuitively understand what a cover is: a song that was popularized by someone and then performed by someone else. However, covers differ significantly in many ways. They can have different melodies, lyrics, styles, and themes. Usually, the lyrics are closer to the original, but just because the same words are used doesn’t mean they convey the same meanings every time they're sung.
00:03:10.360 Consider the short story "Pierre Menard, Author of the Quixote" by Jorge Luis Borges. It’s written as an academic dissertation studying Pierre Menard, who rewrote "Don Quixote" word for word, not by copying Cervantes, but by trying to embody the mindset of Cervantes from 300 years earlier while rewriting it. This led to each word meaning something completely different because of the context in which they were created. We can look at that as a way of examining covers as well. Like, an easy listening song that is covered by a death metal band—same exact words but entirely different meanings.
00:03:41.280 Now, not all covers are created equal. Some covers are poorly executed, aesthetically unpleasing, or fail to differentiate sufficiently from the original song. Good covers, however, often redefine genre boundaries, allowing the original song to be expressed in a new light. For instance, you might have a great jazz cover by another jazz artist or a pop song performed by another pop artist, but the really interesting cases are where genres cross and that can create new interpretations of the same song.
00:04:11.920 So, let’s take an example. This is Frank Sinatra's version of "Luck Be a Lady," a song he performed in "Guys and Dolls." It was covered in 1993 by The Toasters before they became big. This cover is obviously and significantly different from how Frank would have sung it. I picked this song because when I was working at a movie theater in 1993, a customer brought in a two-CD album set filled with covers of Frank Sinatra songs by punk and alternative rock bands. It was filled with many excellent covers, like this one, that made the song their own while expressing emotions Sinatra might not have intended.
00:04:58.720 However, it was also filled with poorly executed covers, where punk bands tried to adapt Sinatra’s jazz standards in a way that didn’t resonate. Bad covers can be deficient for two reasons: they can be aesthetically unpleasing, or they fail to make a meaningful change to the song. On the other hand, the best covers are those that thoughtfully reinterpret a song, allowing for the expression of different meanings depending on genre.
00:05:26.080 To illustrate this further, let’s look at some bad covers. Some actually become lonely experiences such as when a computer-generated cover of a song becomes a disappointment. There was one I performed that I hope you'll appreciate that was just downright hollow. Bad covers can indeed strip away the substance that makes the original song great.
00:05:49.880 Now, let’s discuss how we can relate this discussion to software development. In software, I think we have direct analogies for each of these types of theft: libraries for sampling, influence from one framework to another, ports as covers, and design patterns as the equivalent of standards. Libraries involve using other people's code—whether it’s your code from the past re-used in a new context or others' contributions to build something new, just like Girl Talk creating an entire application from other people’s efforts. I'd love to see a Rails Rumble competition where participants didn't write any new code; they only glued together existing pieces.
00:06:53.160 Influences in the software world can be seen through patterns like xUnit. The xUnit pattern originated when Kent Beck collaborated with Smalltalk programmers. Every team created their own version of this pattern, each unique to its context. A notable example occurred one stormy night when Kent Beck and Eric Gamma flew across the Atlantic and decided to program together. They created JUnit, a distillation of the ideas present in xUnit—moving concepts over to Java without merely transferring code from Smalltalk. Instead, they translated ideas and practices that were influenced by the original, demonstrating that influence in software can manifest similarly to influence in music.
00:07:24.480 Now, let’s consider ports; they serve as the closest equivalent in software to covers. Ports, like good or bad covers in music, can either faithfully translate an idea into another context or suffer from flaws. For instance, NUnit was originally a line-by-line port of JUnit to .NET. However, it contained elements specific to Java that would never execute in a .NET application, which made it a bad cover. In contrast, Michael Feathers' CPPUnit exemplifies the ideal port since he translated not the code but the ideas behind unit testing from Java to C++ successfully.
00:08:57.880 In software, different programming languages are adept at expressing different paradigms, much like how genres in music express different emotions. It’s important to note how Ruby allows for unique expressions of code that may be cumbersome in languages like Java. If programming languages were completely equal, it wouldn’t matter what we were doing independently; we wouldn't learn anything new or develop new insights. This leads to the point where patterns are unsurprisingly analogous to standards; they emerge not from copying but from collective experiences and independent discoveries.
00:09:36.720 To illustrate this point, let’s look at the genealogy of some software. The origins of BDD (Behavior Driven Development) can be traced to conversations that Dan North had with various people around JBehave, the first emergence of BDD. After that, Dan North wrote RBehave, which then transformed into Cucumber, influenced by both RSpec and PHP Spec, which in turn drew ideas from numerous frameworks. So, while these frameworks are related, each has distinct heritage and lineage.
00:10:23.000 When discussing Ruby on Rails, you can see how other frameworks like KPHP or Grails—which were essentially attempts to clone Rails—came about. For a time, KPHP would release an updated version a month after Rails to include the latest features, which I would argue turned into a bad copy. ASP.NET MVC also reimplemented various ideas from existing frameworks but did so in a more direct manner than Rails intended. You can observe this pattern across various web frameworks where developers observe ideas that worked in one context and decide to replicate them in another.
00:12:38.560 When looking into frameworks like Whiskey in Python, one could argue how similar it is to Rack in Ruby. Hack is another example in Hack, a new language based on PHP many lessons can be gleaned from how one framework can influence the design of another. That’s why it’s fascinating to trace lineage and understand how similar patterns emerge from the subconscious desires to recreate successful concepts.
00:13:01.320 Sinatra is perhaps the most copied web software in the world. If you look through any language, you’ll find dozens of clones based on its original concept. For example, Flask, Nancy, Slim, and more exist as various iterations of Sinatra's web framework principles. Each one adheres to the core functionalities but often adopts a different syntax that reflects the conventions of their environment. This cross-language sharing of ideas illustrates how important it is to not just innovate, but to understand and interpret existing ideas.
00:14:33.920 So, why should we steal? Because it offers opportunity. While learning new languages, you often come across aspects of them that you wish you had in your own domain. For example, Sean Cribbs developed a Ruby version of 'Web Machine,' which brought some of the advanced concepts from Erlang back into Ruby. Learning is often an exercise in adaptation; you take concepts that resonate from one language and bring them into your preferred language.
00:15:36.320 The second reason to steal is for self-education. When learning a new programming language or framework, you might replicate an application like a blog in that language to familiarize yourself with it. For instance, while trying to refresh my Italian before a honeymoon, I read a beloved book in Italian to ease the learning curve. This strategy can be applied to programming as well to cement knowledge through practical experience.
00:16:14.840 Finally, there’s need-driven theft. Sometimes you’re faced with a unique problem that the tools within your realm can't solve, so looking outward becomes necessary. There’s a case from my experience working on iOS, where unit testing was a challenge. By examining existing frameworks for other platforms, developers can realize solutions that were missed and adapt them accordingly.
00:16:50.480 Once you decide to go out and search for these solutions, GitHub, Bitbucket, and various language-specific repositories become crucial tools. If you’re trying to adapt existing pieces of software, look deeply at their activity levels, documentation quality, and whether they've been cited in prominent works. This will indicate whether you are investigating valuable resources. Checking their history is important to not only understand their purpose but also to avoid pitfalls in implementing them in your own projects.
00:17:31.720 Remember, when you come across strong opinions about certain practices or technologies, these discussions can lead to insightful discoveries. For example, the blog OK Cupid Trends demonstrates how people react to diverging opinions and judgments in social contexts. There’s real value in seeing where commonalities exist among seemingly disparate paradigms.
00:18:50.760 As we wrap it up, I just want to emphasize that while stealing has a negative connotation, the concept of borrowing and adapting ideas is fundamental to creativity in software development. Instead of stealing literal implementation, I recommend acceptance testing large portions of code, focusing on inputs and outputs, capturing the intent rather than the syntax. Thank you for your time.
Explore all talks recorded at LA RubyConf 2012
+6