Star Driven Development

July 15, 2019    Development Process

*DD (Star Driven Development)

We were joking with a new co-worker, that is just out of college, about all the *DD’s there out there. I thought it’d be fun to list the ones I could think of and find on the internet

Test Driven Development (TDD)

Write your tests first. Red, Green, Refactor. This approach was introduced and made famous by Kent Beck in the “Test-Driven Development” book in 2003.

Type Driven Development

“Mark Seeman (as far as I’m aware) coined the phrase Type Driven Development, which has become known as a kind of F# version of Test Driven Development. This refers to the idea that you use your types to encode business rules and make illegal states un representable –driving development and rules through the type system, rather than through unit tests.”

From [When to Unit test in F#)[https://freecontent.manning.com/when-to-unit-test-in-f/].

Domain Driven Development (DDD)

Eric Evans wrote Domain-Driven Development in 2003.

“Domain-DrivenDesign is an approach to the development of complex software in which we:

  1. Focus on the core domain.
  2. Explore models in a creative collaboration of domain practitioners and software practitioners.
  3. Speak a ubiquitous language within an explicitly bounded context”

These are from the summary book .

Behavior Driven Development (BDD)

I’ve been interested in BDD since at least 2013 .

Thinking through solutions, before starting to code.

“This was the biggest benefit to me. I like to jump into coding to figure out the problem.”

It’s all about figuring out using language that your users understand (ubiquitous language) and building what they need.

Given, When, Then (Gherkin) is a way to do this.

This is closely related to DDD (Domain DD).

Dan North introduced BDD in March, 2006.

Acceptance Test Driven Development (ATDD)

“Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality.”

reference

Another article from AgileConnection.com

Model Driven Development (MDD)

@Gagege tweeted this article called the Coming Software Apocalypse . MDD caught my attention for my post.

"Model-driven development (MDD) is a format to write and implement software quickly, effectively and at minimum cost." 

reference

Feature Driven Development (FDD)

"Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process. The term "client" in FDD is used to represent what Agile Modeling (AM) refers to as project stakeholders or eXtreme Programming (XP) calls customers." 

reference

Readme Driven Development (RDD)

Tom Preston-Werner’s article introduces this. It’s not as well known as the DD’s above.

Observational Driven Development (ODD)

An article on DZone says “With all the benefits that microservices architecture and cloud-native and serverless applications bring, they also add a lot of complexity from an operations point of view. To successfully support and manage these applications, it has become very important to have full visibility into these distributed applications.”

“Observability-Driven Development (ODD) is a new terminology that has started being used recently to highlight the need for incorporating observability aspects throughout the software development life cycle. ODD encourages a left-shift of the activities required for observability right from the early stages. The common key dimensions of monitoring are logs, metrics, and tracing.”

A few quotes from his article

“a single file that is intended to be read as an introduction to your software”

“all irrelevant unless the software we’re building meets the needs of those that are using it. Let me put that another way. A perfect implementation of the wrong specification is worthless.”

He also mentions Documentation Driven Development (DDD). “RDD could be considered a subset or limited version of DDD”.

“There must be some middle ground between reams of technical specifications and no specifications at all. And in fact there is. That middle ground is the humble Readme.”

I came across this in Eric Elliot’s article on Boeing

Contract Driven Development (CDD)

Jim Coplien and Bob Martin Debate TDD in Oct 23, 2012.

CDD contract

Minute 16

Fear Driven Development (FDD)

In 2014, Scott Hanselman had an article about FDD .

I started using FDD at work after I change something in our API and didn’t get the Database changes synced correctly. Everything seemed to fall apart and QA was unable to test and it seemed to be a huge 🔥. Then it happened again.

My definition: "when developers are afraid to add or refactor code because the fear that they will break something (an unknown scenario or another part of the system). Fear can also come from worrying that they will get blamed and worse because of mistakes."

Fear reduces the desire and ability to experiment. Less experimentation leads to less innovation.

I believe that we shouldn’t blame individuals, but systems that don’t create safety and quick feedback.

Automated testing for safer systems, automated deployment, less bad data (examples: setup of set of data, old now obsolete data sets) in the system, cleaner code (smaller classes) and more documentation about the business rules are all ways I combat FDD.

Chaos Driven Development (CDD) - 07/02/2021

Closely related to FDD, this approach happens when the wave of bugs never ends. Everything is critical. Fixes are made quickly, without automated tests and probably cause other bugs. QA is overwhelmed (needing to manually test because of the lack of automated tests), because developers are throwing fixes at them faster then they can verify other changes. The test environment is constantly changing.

The team is “outrunning their headlights” (from Pragmatic Programmer)

I just made this up, maybe you can notice that I’m living through it now.

Excitement Driven Development (EDD)

An antithesis to Fear DD, Choose Excitement over Fear and “Redefine Fear as Excitement”.

Added 1/27/2021

Pain Driven Development (PDD)

“Only fix problems when they are causing pain”

“You need to pick your battles. You need to actually ship working software. You don’t know when you begin a project where extension is going to be necessary, so you can’t anticipate every way in which you might support the Open-Closed Principle for every class or method in your program. Build and ship working software, and let feedback and new requirements guide you when it comes to applying iterative design improvements to your code. When you’re back in the same method for the Nth time in the last month because yet another requirement has changed how it’s supposed to work, that’s when you should recognize the pain your current design is causing you. That’s where Pain Driven Development comes into play. Refactor your code so that the pain you’re experiencing as a result of its current design is abated.

From WeeklyDevTips has a PDD episode . (Hint: start at 0 and listen to all of the episodes that are about 5 minutes. These will help you a lot.)

Resume Driven Development (RDD #2)

This is really a joke :-). Sometimes we want to make our resume (and egos) better by creating something with the latest tech.

Silverlight, Angular, React, VueJs, SPAs, SignalR, Progressive Web Apps, Blazor, GraphQL, Containers are just a few examples that I’ve seen in the past 12 years. They are all important improvements in our field that need to be evaluated and not just used because it’s the most exciting/latest/coolest approaches. They definitely are important, but not just because you want to use them

Dophamine Driven Development (DDD)

This acronym comes from DDD .

  • “Work in small, manageable increments, and find ways to measure and reward yourself for your work. Minimize the cycle time between when the work is done and when it can be delivered and/or measured.”
  • “Connect your work to a bigger picture for deeper fulfillment.”

This sounds a lot like DevOps, the importance of quick feedback and a great way to work to me :-).

Defect Driven Testing (DDT) - Bonus

This one doesn’t fit as well, but I was just watching Kelvin Henney on Code Risk . TDD, then DDT is in response to an observation, you write a test to catch and demonstrate this weakness doesn’t exist. The system is never done.

Defer Decisions Development (DDD) - Bonus

I made this one up. I’ve been reading Clean Architecture by Uncle Bob Martin for a weekly book study group at Omnitech . In Part V “Architecture”, Uncle Bob teaches that we should defer “details” (Database, UI, communication layers) as long as possible. We due this by isolating from the “policy” (business rules) and abstracting where needed.

I highly suggest this book!

Agile also teaches us to “delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative.”

Component Driven Development (CDD)

The CDD article is UI focused and seems related to my Defer Decisions Development and Clean Architecture. “Let components drive the development of your applications.”

Deadline Driven Development (DDD)

Defect Driven Development (DDD)

Hammock Driven Development (HDD)

Hammock Driven Development - Rich Hickey .

Uncle Bob said “In some ways these blogs remind me of Rich Hickey’s now famous talk on Hammock Driven Development; which I enthusiastically support. Of course I completely agree that you should think before you code. It is never a bad idea to think through a problem or how to solve it. Please, please, think. Lay in the Hammock. Take some time. Think. Think. Think.”

Bureaucracy Driven #Development (BuDD)

From The Art of Business Value by Mark Schwartz . Not all bureaucracy is bad. It actually helps us be efficient and productive and applies the rules to all in the same way. However, we don’t want it to become too rigid and static. This is a very good read. I’m planning on writing an article about it soon.

The CD pipeline is an automation bureaucracy/rules that have been established.

Business Intelligence Driven Development (BiDD)

From The Art of Business Value by Mark Schwartz .

Outcomes of the work is important to experiment and evaluate business value decisions. Use BI dashboards to help determine if your hypothesis of value that will be created was achieved. Release in small batch sizes and capture value as soon as possible. Pivot when necessary. These are all Lean Startup and agile ideas.

Grenade Driven Development (GDD)

A new addition on 12/18/2020 from IT Revolution .

"If the developer can use Grenade Driven Development to hand off the pain of poor quality and is only responsible for coding, then there's no incentive." ~ Bryan Finster

Railway Oriented Programming

A useful approach to error handling in Functional Programming

From F# for fun and profit .

What did I miss?

There has to be more *DDs. I kept finding them in searches and articles. Help me out and add yours in the comments below!



Watch the Story for Good News
I gladly accept BTC Lightning Network tips at [email protected]

Please consider using Brave and adding me to your BAT payment ledger. Then you won't have to see ads! (when I get to $100 in Google Ads for a payout, I pledge to turn off ads)

Use Brave

Also check out my Resources Page for referrals that would help me.


Swan logo
Use Swan Bitcoin to onramp with low fees and automatic daily cost averaging and get $10 in BTC when you sign up.