Caveman BDD: Re-centering our approach to software

Weakly typed programming languages have two alleged advantages. Speed of development, and lack of boilerplate. There’s some mental overhead associated with constantly reasoning about whether or not an abstract concurrent static method class unsigned generic interface System.out bigint is appropriate for your use case, or so the argument goes.

But what if we applied the same argument to natural languages? Popular natural languages like English have a bunch of boilerplate too. There are all these cases, tenses, prepositions, clauses, infinitives, conjunctions, which, in analogy to keywords in a strong typing system, have little semantic content themselves, but are supposed to aid in clarifying the relationships between the more meaningful entities: the nouns, verbs, and adjectives. So what if we ditched the boilerplate? What if we embraced a terser English?

We would sound like cavemen, is what. That’s not a bad thing. We’ve been culturally conditioned to perceive caveman-speak as unsophisticated, uncivilized, unprofessional, etc. Yet the truth is, you gain precisely the same advantages as you do with a weakly-typed programming language: speed of writing and reduced mental overhead when reading. Consider the text of this post up to this point, rewritten in caveman:

Weak type program language good. Fast develop. Boilerplate bye-bye. Small code easy think.

Caveman-speak good too. English too wordy. Cases? Prepositions? Clauses? Blah blah blah. Verb good. Noun good. Adjective good. Definite article stupid. Conjunctive phrase stupid. Compound sentence stupid. Qualifying phrase stupid. Caveman not have stupid.

Think caveman-speak unsophisticated? You stupid. Think caveman-speak unprofessional? Doubleplus stupid. Caveman efficient. See?

Perhaps it doesn’t communicate the same level of nuance as did the long-form English, but how much of that nuance was truly necessary, anyway? The central ideas, I think, are a lot clearer in the caveman version, and I believe this to be true in general.

Neolithic speak good. Modern speak feature bloat.

The Caveman invasion has already happened

As software developers, we may not have considered the merits of caveman-speak as such, but it is not a new idea for us. There’s an adage that good code is to some extent “self-documenting.” You are able to understand “self-documenting” code without thinking too hard because it is broken down into small digestible pieces and has useful variable names and method signatures. But what are variable names and method signatures? English nouns, verbs, and adjectives. Sound familiar? Nouns, verbs, adjectives broken down into small digestible pieces — “self-documenting code” is nothing more than caveman-speak in disguise! We programmers have been speaking — and idealizing — caveman-speak all along, we just may not have realized it.

Introducing Caveman BDD

Now that our tacit appreciation of caveman-speak has awakened and been transformed into a firm, active conviction of its usefulness, a natural question arises. How might we expand our use of caveman-speak to improve the efficiency of our workflow? Because of network effects, caveman is not likely to be a viable replacement for legacy English in the conversational domain, at least not for the present. But as programmers, any of our non-conversational written natural language output has the potential for improvement by switching to caveman. In particular, at Livestream we have invented something we call “Caveman BDD” for use in describing and testing software functionality.

The principles of Caveman BDD are very simple. Really, there’s only one principle. Ditch unnecessary words, starting with the “user” in “user story.”

Here is an example of a typical BDD user story.

When the user clicks the ok button

and his password contains only numbers

then a box appears telling him that his password must be at least 7 characters, contain a capital letter, a lowercase letter, a symbol, and an irrational number

Which words in this user story can be removed? For starters, we do not need to specify that it is “the user” who clicks the button. Who else is going to click the button? Do you expect the button to grow impatient and click itself?

The word “click” can also be omitted. “Hover” would be another matter, but when you hear button you automatically think “click.” It is the typical action for a button, and can easily be inferred.

Almost all of the final line is extraneous. Appearance is the default behavior for a box, and presumably, the password requirements can be inferred from the other failure cases.

After all these removals, we are left with the much cleaner Caveman BDD story.

When ok button

and number-only password

then annoying box

Sure, it’s missing that whole “look Mom, I made a well-formed English sentence!” aesthetic, characteristic of traditional BDD, but it communicates the meaning clearly, and the important ideas are front and center. Imagine scrolling through a spec with dozens and dozens of these, searching for one in particular. No more digging through a sea of meaningless words to try and puzzle out what the story is actually about.

A whole new approach

Caveman BDD is not just a handy tool to improve how expressive a few documents and test cases are. It is a complete re-centering of our approach to software.

Every piece of software should begin as a Caveman BDD description. TDD taught us to design our software to be tested, from the beginning. BDD taught us to design our software for the end user, from the beginning. The lesson of Caveman BDD is to design our software with economy, from the beginning. If the words we use to specify what software to build are full of unnecessary bloat, should it come as a surprise that the software that gets written turns out that way too?

Caveman BDD and Javascript

At Livestream, we do our BDD with the mocha framework for testing. Mocha provides two magic words, describe for describing your scenario, and it for making assertions. It’s almost perfect, although describe can be a bit of a mouthful. So, when we are doing Caveman BDD we begin the file with

const ug = describe

The word “ug” has the advantage of being terser and also caveman-thematic. Behold:

ug('ok button', () => {
  ug('number-only password', () => {
    it('annoying box', callback => {
      password = "139553"
      clickOk(assertAnnoyingBoxVisible(callback))
    })
  })
})

The future of Caveman BDD

There’s no doubt about it. Fighting for adoption of Caveman BDD is going to be an uphill battle. Even at Livestream, the very place where Caveman BDD was invented, the powers that be are still struggling to overcome their preconceptions of Caveman as unprofessional and inexpressive. Perhaps someday, they will come to realize its advantages and embrace it for the blessing it truly is. Perhaps not.

—

Please note, the opinions expressed in the article are the author’s own, and do not necessarily reflect those of anybody else at Livestream.

—

You program good? We hire.

I tweet.