Desire Driven Development


Desire verb [ T not continuous ] /dɪˈzaɪər/

to want something, especially strongly.

Cambridge dictionary

Long have I heard and reaped the benefits of TDD (Test Driven Development). But I’m starting to sense that much of the material written and explained about TDD is by fanatics. Don’t get me wrong. I see the value when learning a new tool to overcompensate. If you have never written a test before coding, then I’m all in for trying for a month or two to always write a test before, write the least amount of code, and iterate.

As with most tools, the implementation is as important as to knowing when to use it, and when not to1.

I like the analogy of this learning as an infection. It may be because I’m writing this amid a pandemic, or that the experience was explained to me as being “test-infected”. But either way, I think that TDD is a bacteria.

Not all bacteria are bad. Some are cute and cuddly2 and helps in our digestion. But some are mean and make out belly ache. In order to protect yourself, you need to build up an immunity. And there are, broadly speaking, two approaches:

  • The risky way is to contract the infection. Set out to TDD all the things for a while. Don’t question it, just do it.
  • The hard way is to develop and apply a vaccine. Analyze when to apply the technique; how to simplify a problem or a part of the problem to attack it with TDD. This is difficult to do right, but you can work at it little by little until you develop a potent response.

You can have too much of a good thing.

I’ve come to terms with the idea that I no longer do TDD, but my take of it: Desire Driven Development. When discussing this blog entry, many people did agree that they also find a middle ground between strict TDD and testing3 code.

Desire-Driven Development by Example

If I want to become a famous author, I need to distill the idea down to a few, simple, easy to comprehend steps. Bonus points if they form an acronym.

  1. Start with your Scratchpad. This can be a new test suite. extending an existing one. If your language/technology allows for an interactive workspace or REPL, those too can work. Anywhere where you can code, and it can eventually be run.
  2. Assume that all the code is done already. All features implemented. No bugs. Well-designed, neat, and functional.
  3. Write down the acceptance criteria and what the expected outcome should be. Remember, all the classes, methods, functions that you want exist already, and work exactly as you expect.
  4. Follow down the compile errors, missing methods, classes, runtime checks, et al. until your scratchpad does indeed work as you intended.
    • It might come the time where you’ll need to update the criteria written in step 3. You are allowed to do so but you need to first think hard about the change.
  5. (unchanged4) Refactor as needed.

S.A.W.F.R.

The linchpin of this technique is that I usually want to write and read code in the same way. There is no feasible way that I can know what other people will understand when, in the future, they reason about my code. But I am constant5. Then I should strive to produce code that astonished me the least6. Hopefully, like minded individuals will be equally un-astonished.

And bare in mind, this original code in step 3 has no concept of the inner workings, the details, the implementation. Pure and unadulterated issue-resolving code.

If I gave you my 5 letter acronym7, I can top it of with a 5 words summary:

TDD, but lightweight

The same, but different too

The major distinction between TDD and Desire Driven Development is that the latter focuses on the outer most implementation. The technique spends a lot of time thinking, contemplating, and in awe of what the final implementation will feel like. Anything that is needed to make step 3 possible, I don’t care about testing, or developing. I’ll go so far as to say, I would like to have the most freedom of changing it at a whim. Writing tests for this inner layer makes change harder.

Hairy step 4.

It might come a time where I have a complicated piece of logic that I wished was already there. Then I usually Shahrazad8 and DDD again from that point onwards. But this is a conscious decision I make. I don’t zealously write tests for each intermediate abstraction.

Sometimes, I need to change the beautiful code written in step 3. That is because my squishy human brain9 can cope with the inherent vagueness of my desires, without considering the minutia required for it to be codable, but more often than not; when I realize that additional contextual information is needed (like an extra parameter; or a fatter way of building the environment), I look back at my original assumption and try to make that the default behavior, with as minimal code change to the original desire.

The water shapes the rock, and the rock shapes the water

Whilst writing this, I realized that I, personally, am a big fan of writing my custom DSL10s. I like languages that allow me to express these DSL with little to no extra syntax and I gravitate to statically typed languages with good inference and tooling.

Bonus points when the language’s bottom11 helps the compiler insert error messages which are more appropriate to the context in which it appears12, or in runtime when throw Error() caries with it the stack trace.

These all are great characteristics to have for DDD.

Closing thoughts

The more I think about it; the more I’m convinced that DDD is less about Development, and more about Design. SO I might need to change the title at some point. But for the time being, I’ll try to piggy back on TDD. Maybe DDD is not for everyone or every use case, but it is how I usually code 😺.


  1. “If the only tool you have is a hammer, to treat everything as if it were a nail.” — Wikipedia 

  2. I’m not affiliated with Giant Microbes, but this plush just too cute to pass up. 

  3. I don’t think that putting “testing” and “TDD” at the two ends of the spectrum of writing code is a newfangled idea. 

  4. “““inspired””” by Kent Beck’s Test-Driven Development by Example step 5: Refactor as needed. 

  5. The Ship of Theseus is a thought experiment that raises the question of whether an object that has had all of its components replaced remains fundamentally the same object — (Wikipedia)[https://en.wikipedia.org/wiki/Ship_of_Theseus]. I reckon for this particular aspect of my code reasoning abilities: I’ll always be the same, or more knowledgeable. 

  6. Principle of least astonishment 

  7. Yes. It is an acronym. It should be pronounced as a word. I won’t have another /gɪf/ vs /dʒɪf/ pronunciation battle. So I’m deciding that the pronunciation of SAWFR is: /bɑb/ 

  8. There is a card in Magic: The Gathering™ called Shahrazad that represents a function call, with its stack and return point. It states: “Players play a Magic subgame, using their libraries as their decks. Each player who doesn’t win the subgame loses half their life, rounded up.” 

  9. Cognitive dissonance occurs when a person holds contradictory ideas. — (Wikipedia)[https://en.wikipedia.org/wiki/Cognitive_dissonance] 

  10. Domain-specific language 

  11. Bottom (⊥) refers to a computation that never completes successfully. 

  12. Almost verbatim Haskell’s Prelude undefined docs 

Melian

Random Posts

Deckchecks, Heuristics, and Decision Trees

One of the tools judges employ to thwart attempts to cheat is to require players to write down what cards they will be playing within a particular tournament, and routinely check them. Judges must perform these checks the fastest way possible to not delay the tournament. As such, they developed a myriad of techniques. I feel we under-use the availability of the decklist, so having a clear plan ahead of actually getting the deck in our hands can prove highly effective. In this post, I would like to explore some techniques' inner workings. Propose a hypothesis on why they might work in some situations but not others. Consider unexplored alternatives. And build a heuristic on what method is better for each circumstance. Join me! #mtg

carbn

We are constantly trying to write code that easier for a human to comprehend. These high-level languages gave us the power of expression. And we like this!

We want more expression, and safety in the code we write; but we also want code that humans can understand and reason about. So what if we re-think our current software stack? And have humans evaluate other human’s code.

carbn is a Humans-as-a-Service, cutting edge technology that makes your code run in the distributed brains of our agents.

#raving

The essence of Event Sourcing

Event Sourcing is a somewhat trending topic, and you can find a lot of blog posts on what event sourcing supposedly is. I’ll throw my wrench in the works and try to explain what I see as “Event Sourcing”. #xpost

Haskell para mentes imperativas

En este post quiero explorar algunas cosas que creo que me hubiesen servido para aprender Haskell. Teniendo una base en algún lenguaje imperativo, usar esta para programar en Haskell. #xpost