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.

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.

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

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.

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)

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!



comments powered by Disqus

Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!

Support me and download Brave!

Use Brave