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
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-DrivenDesign is an approach to the development of complex software in which we:
These are from the summary book.
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.
“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.”
@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."
"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."
Tom Preston-Werner’s article introduces this. It’s not as well known as the DD’s above.
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 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
Jim Coplien and Bob Martin Debate TDD in Oct 23, 2012.
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.
“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.)
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
This acronym comes from DDD.
This sounds a lot like DevOps, the importance of quick feedback and a great way to work to me :-).
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.
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.”
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.”
Empowering Protip: When Git gives you a complicated merge conflict, rub your hands together and say loudly "FINALLY, A WORTHY ADVERSARY!"— Rúnar (@runarorama) July 16, 2019
I first learned about DDD as Defect Driven Development. 😂— Victor Rentea (@VictorRentea) July 17, 2019
First bug: there is no homepage.
Gets you accustomed with fixing bugs. With Maintainance Wars.
Uncle Bob said “In some ways these blogs remind me of Rich Hickey’s now famous talk on Hammock Driven Developmeny; 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.”
There has to be more *DDs. I kept finding them in searches and articles. Help me out and add yours in the comments below!
Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!