Begin The Discipline

BDD Behavior Driven Discipline

For the past few years, I've been using Behavior Driven Development (BDD) to build apps. We also incorporate it into our design process, referring to it as Behavior Driven Design. Today, I'll overview our approach using the modular app platform Oqtane on ASP.Net Blazor, and introduce a new concept: Behavior Driven Discipline.

Last night, while gaming with friends, I sketched our project process to share with my development team as the 2025 playbook. This organic method is adaptable to any web project and uses Oqtane for examples, though it can apply to other modular frameworks. The six-step process forms the acronym ICECAP.

By “discipline,” I mean following these steps exactly, even without immediate benefits. Over multiple projects, this process will become indispensable.

Discipline: The art of sticking to your goals even when it’s tough. It’s about having control over your actions, maintaining focus, and being committed to your plan. Sounds simple, yet incredibly challenging.

The six step checklist for the Discipline

I’m big on checklists. If you have not read “The checklist Manifesto” DM me and I’ll send you a copy. It’s not even about software engineering. It’s about doctors and pilots and how to make less mistakes. Even when you are at the pinnacle of your skills.

• Interview Stakeholders

• Codify the Specs

• Extract the Modules

• Compose the Pages

• Assemble the Code

• Prove the Work

ICECAP is our iterative software delivery method with effective feedback loops. I'll explore each topic in future posts, but here’s an overview.

Interview Stakeholders

Effective stakeholder meetings require clear communication. Share the agenda beforehand and state the meeting’s purpose. Record meetings and use AI tools for summaries and transcriptions. Start with, “We’re discussing practical solutions to our problem by examining current processes and envisioning future improvements.” Facilitate the discussion, listen actively, gather all perspectives, and ask clarifying questions. Follow up as needed to gain a comprehensive understanding of the issue from all angles.

Codify the Specs

The output from interview transcriptions and meeting summaries can serve as valuable input for drafting specifications. AI chatbots are effective at writing classic BDD specs. Collaborate to list all the scenarios discussed in the meeting using standard agile use case language: "As a [user role], I need to [perform an action], so I can [accomplish a goal]."

As a BDD project lead, I need to convert the stakeholder interview assets, so I can completely codify the specifications in a way that’s understandable by the app builders and the stakeholders

After recording the scenarios, detail each with a series of BDD behaviors using the Gerkin format: "Given..., When..., Then..." These should contain enough detail to facilitate app building.

Given a set of BDD scenarios, When I follow the BDD process, Then I’ll produce detailed behaviors that builders can use to make and test modules.

This process provides a deeper understanding of how the app will function with explicitly testable details. Numerous BDD resources are available online to guide through this process. Examples will be provided in the specific post.

Codifying the specifications allows for the creation of feedback loops with stakeholders. At this point, schedule a meeting to review the specifications with stakeholders and create the first asset for validation.

Extract the Modules

Given a set of behaviors, there is a method for translating these into functional units known as modules, specifically Oqtane Modules. An Oqtane module represents a segment of functionality within an application that can be deployed independently. The architecture of a module is divided into two main components: client and server.

On the client side, the module encompasses UI elements, client state management, and services provided by Oqtane, as well as routing, dependency injection (DI), and other single-page application (SPA) features from Blazor. On the server side, it includes an API layer similar to ASP.Net MVC, data repositories, and models shared between the client and server.

The relationship between behavior specifications and coding elements can be determined through a process of noun/verb extraction. Nouns identify a module, while verbs denote the actions associated with that module. Oqtane modules focus on a data model and provide various components to perform different actions. Multiple actions and components can be incorporated into a single module to meet the specific requirements of a scenario.

Compose the Pages

Oqtane is an example of a composable UI framework, among many others. If you haven't read Atomic Design, you should. Without delving deeply into atomic design theory, it progresses from single controls to grouping them into reusable components, then to modules. With a set of modules, we can create pages with various modules to help users achieve different goals. This goal-oriented approach to UI flow aligns with BDD. Instead of building an app for users to navigate and edit things, we’ll build pages and workflows that match user tasks directly. Revisiting behaviors, composing pages from modules, and facilitating goal-seeking efficiently is the aim. Different paths may exist for users with various capabilities. Page composition studies and applies this skill.

Assemble the Code

This covers coding and its related aspects. As a professional developer, you are expected to follow patterns and write testable, maintainable code. While I may share Oqtane and Blazor tips, detailed coding guidance won't be provided.

Prove the Work

This step occurs at the end of most other steps, culminating in a final proof. The work is verified by demonstrating every scenario and behavior in the production app through demo meetings and a sign-off process. Additional feedback points include:

• After codifying the specs, meet with stakeholders to review each scenario. Limit the meeting to a few scenarios and thoroughly discuss behaviors. Ensure no behaviors are missed and consider the process on both sides of the scenario. Understanding the broader workflow can reveal opportunities for integration and automation.

• Before finalizing and coding, review the draft pages and modules with stakeholders to gather feedback and avoid costly mistakes.

• Code assembly involves mini-proofs like PRs and automated tests. This final proof complements them.

The month of November will be dedicated to discussing this topic in detail. It will benefit my team to document it. Drawing from decades of agile projects, I aim to establish an optimal level of process to facilitate continuous app delivery. This process is applied across 3-4 simultaneous projects. By maintaining a consistent tech stack with Oqtane and Blazor, and adhering to this BDD discipline, we can operate efficiently while minimizing the risk of burnout.