I did a bit of reading about test-driven development (TDD), which led me to behavior-driven development (BDD). I started out by looking at some slides on TDD by Andrzej Krzywda which provide a nice overview:

  • TDD (at a high level) is about visualizing goals
  • Software developers are responsible for the visualization of other people’s goals
  • Guidelines:
    • write tests BEFORE writing production code
    • have many tests
    • 3D rule = Defense (Tests), Design, and Documentation
    • there is always exactly one test failing
  • Definitions
    • Acceptance test: a test from the user’s perspective
    • Unit test: a test of a class

Andrej argues that Rails focuses on acceptance tests because it is a mature community (from a TDD perspective) and because of the available tools. I’m not sure why REST makes it so controllers don’t need testing, but it makes sense to me that the focus is on tests of the model. Andrej goes on to introduce behavior-driven development (BDD). He recommends that you start with user stories. RSpec is a tool that helps with that. With BDD, you create executable specifications, not tests. You want to look at what your code does, not the internals of how it does it.

Bryan Helmkamp (via Andrej’s blog) provides a quote from Robert Martin:

Unit tests: “Make sure you write the code right.”

Scenarios: “Make sure you write the right code.”

“BDD is what you are doing already if you are ding TDD very well” notes Dave Astels, one of the creator’s of RSpec in “Beyond Test Driven Development: Behaviour Driven Development“, Google TechTalk March 17, 2006. Further notes from that talk:

  • If you focus on testing your classes, then the structure of your test code mirrors the structure of your production code. What happens when you refactor and you change that structure? do you then re-write your tests? If you focus on behavior you don’t have to. When you refactor, the behavior of your application doesn’t change
  • Get away from state-based testing. If you depend on specific variables in your code, the inner state of your app, that will be a barrier to re-factoring. Instead of focusing on assertions, set expectations.

I found the link to Dave Astel’s talk in a good thread on RSpec that is worth reading, where I also found the following memorable quotes:

“any time your code does something unexpected, write a test.”

Eric Hodel

When I do TDD, I approach it with a Jeckle and Hyde perspective. When Iwrite a test, I am writing a specification of how the code should work.

When I start writing code, I become the laziest programmer you can imagine, writing only enough code to pass the specification as it is written at that moment. If it is not called out in the spec, it doesn’t get written.

When I switch back to test writing, I cuss out that lazy programmer (i.e. me just a few moments ago) and write additional specs to force the code to do exactly what I want.

The tension between Dr. Jeckle (the spec writer), and Mr. Hyde (the programmer) causes Dr. Jeckle to write better specs and Mr. Hyde to write lean, correct code.

Jim Weirich

“A language that doesn’t affect the way you think about programming is not worth knowing.”  — A. Perlis

Sapir-Whorf hypothesis (aka linguistic relativity hypothesis) asserts lanugage influences how you think, that “different language patterns yield different patterns of thought.” It seems like the Heisenberg uncertainty principal, where measuring a particle also affects it. Dave Astels refers to the Sapir-Whorf theory in his talk on behavior driven development. He describes that Sapir-Whorf “challenges the possibility of perfectly representing the world with language, because it implies that the mechanisms of any language condition the thoughts of its speaker community.” Dave argues that the use of the word “test” in test-driven development (TDD) causes programmers to focus on validating the inner state of their code rather than in verifying the expected result, as in behavior-driven development (BDD). In large part changing the language we use to describe how we validate out code leads us to develop a more effective and resilient form of code validation.

While wikipedia cites some arguments against this theory, it seems intuitive to me. In fact whether learning a spoken language or a programming language I have found that the language I am thinking in does in fact change how I think. For a spoken language, specific words will have different connotations. In a different language, I’ll use different idioms and patterns of words that lead me to express a subtly different meaning, to focus on a specific aspect of what I am seeking to communicate. For programming, the choice of language will influence how I solve a specific problem. It makes sense to pick a specific language for a task in order to influence the flavor of solution that results.

Jennifer Taylor provides fresh insight on the minority of women in computer science by looking at causes of The Decline of Women in Computer Science from 1940-1982. From the pioneering work of Ada Lovelace as the first programmer for the difference engine in the 1800s to those who worked as human computers in the early 20th century to the group who programmed the first computing machine to support the war effort In the 1940s, women played a significant role in the nascent field of computer science.

“The rationale for selecting female programmers was partly due to the scarcity of qualified male labor during the war, but another significant factor was the expectation that women would be uniquely suited to this position, which demanded great ‘patience, persistence, and a capacity for detail’ – qualities that many employers attributed to the feminine sex.” (Taylor references Denise W. Gruer, “Pioneering Women in Computer Science,” 1, from the Adele Mildred Koss papers, 1993-1998, 1 folder, Schlesinger Library)

Despite this auspicious beginning, the participation of women in computer science declined steadily from the 1940s to the early 1980s. One factor that Taylor identifies is the association of computer science with engineering schools. Unlike the hard sciences and mathematics, the engineering discipline was particularly hostile to women. While noting that degrees awarded to women in computer science grew from the 1960s to the 1980s, Taylor points out the overall low participation of women in the field, relative to its beginnings in the 1940s.

The contrast between Taylor’s thesis and the chart above is not adequately explained. It is interesting to note the sharp decline in women in CS from 1966 to 1967. I wish I had the source data from this graph, but the early data set my be so small so that the decline is not significant. There were only a few universities which had computer science departments in the mid-60s. (Purdue University had the first in 1962, followed by Stanford University and Carnegie Mellon University (CMU) in 1965. However, I think Taylor’s point is that the number of women in the field declined after the war from a majority of women programmers to a small minority. The increase in women from the mid-70s to the mid-80s merits further study. If we could replicate such a phenomenon, we could create a more balanced environment in the field.

The whole article is worth reading for it includes a number of interesting historical quotes and offers a rare insight into the early beginnings of computer software development. I’ll quote the conclusion below:

It is doubtless the case that there are more nuances to the masculinization of computing than what could be covered by this short analysis, but the main components of the transition seem clear – that the early advantage of women in computing was largely diminished by a post-war society trying to return to “normalcy,” that the establishment of male-dominated academic and corporate structures marginalized women’s working habits and culture, and that the ubiquity of computing in the home triggered early gender socialization of computers as being a male domain. The positive outcome of this history, however, is the strong evidence that computing is not inherently a male domain, that it is indeed a socially constructed stereotype, and that women’s interests and technical capabilities are not a matter of “innate” differences. The historic accomplishments of the generations past are proof that women can succeed in computing, and understanding the forces that caused their decline is the first step toward fixing the today’s continuing gender inequalities in computer science.

read the original article