A blank page can be very intimidating, even for a Test-driven developer. Where do we start? Write a test, right? Not always.

I’ve heard TDD learners say: “I don’t know what my code needs to do, how can I write a test? I need to write some code first.” I used to make a flippant reply to that, like: “You don’t know what your code needs to do! How could you possibly start with the code! Tests describe what the code must do. How can you write the code if you don’t know what the code is supposed to do?”

Sometimes, it’s simply a matter of software with interface, boundaries and constraints understood or under your control. When it’s simply a matter of software, take some guidance from ZOMBIES! Start with the simplest cases (Zero an One) to get the Interface in place, generalize (to Many) and then make sure the anticipated Exceptional and Boundary cases are all covered with Simple test scenarios. ZOMBIES can really help, except when they can’t.

With my most recent green-field side-project, interacting with Commercial Off The Shelf hardware and software (COTS),I found that unknowns prevented me from writing tests. I totally get that helpless feeling (again) of not knowing what test to write! In Hexagonal Architecture (a.k.a. Ports and Adapters), we strive to separate the land where ZOMBIES rule and where we need something else. In the core of the hexagonal architecture, ZOMBIES rule, in the Adapters we need to discover what works.

In this session we’ll look at how ZOMBIES help sneak up on the solution. In the adapters we need a DIRECT approach to Determine, discover and Isolate Risk, and Encapsulate Current Technology. DIRECT helps isolate and understand things out of our control.

In this talk we’ll explore the challenges and risks developing a real-time water pressure measuring system. We’ll look at how to get to a walking skeleton of the product together by discovering what is needed to get this stack of technologies elements working together:

* Analog to digital converter (ADC)
* Serial peripheral interface (SPI)
* Micro-controller
* IoT radio
* IoT mesh network
* Little Linux box
* Web-server
* JSON and javascript driven browser.

In a multi-layered system like this there are unknowns hide at every boundary. We’ll look at how we address the unknowns DIRECTly, striving to get to where ZOMBIES can guide. Integration is considered from the beginning because that is where the risk is.

There are more risks than strictly technical risks. Business risk assessment will impact technical choices. If we can build it, will it be affordable and profitable? How do we track progress in the face of significant risk. We’ll look at both the technical approach and how to keep progress and risk mitigation visible.


You must be a Member to view this post and you are currently not logged in.

You can either log in below or sign up here.