Delusion Driven Development
And why you shouldn't do it
Created by Felipe Fernández / @felipefzdz
About Me
Felipe Fernández
- Work as Software Craftsman for Codurance
- Currently with Crowdmix
- Blog: http://codurance.com/blog/author/felipe-fernandez
- Twitter: @felipefzdz
Defining delusion
“An idiosyncratic belief or impression maintained despite being contradicted by reality or rational argument, typically as a symptom of mental disorder.”
About the talk
- 1. Operations
- 2. Testing
- 3. Design
1. Operations
Operations
I’ll have a look whenever is needed
Operations: I’ll have a look whenever is needed
Diagnosis in distributed environments
- When your tests are not enough
- You need to query the state of your system
Operations: I’ll have a look whenever is needed
Diagnosis methodologies
- Debugging
- Querying datastores
- Logging
Operations: I’ll have a look whenever is needed
Distributed diagnosis methodologies
- Debugging -> LOL
- Querying datastores -> Fragmentation
- Logging -> Madness
Operations
I’ll have a look whenever is needed
Please don't, it could be really hard and you want to be prepared
Operations
I need to remove that duplication NOW
Operations: I need to remove that duplication NOW
Generalising deployment pipelines
- DIY deployment pipelines
- Microservices context
Operations: I need to remove that duplication NOW
Generalization assumptions
- Versioning
- Checking
- Continuous integration
Operations
I need to remove that duplication NOW
Do it when you're stable enough
Operations
I guess that is ready
Operations: I guess that is ready
Creating real walking skeletons
- That includes provisioning and deploying
- Smoke test as driver
Operations: I guess that is ready
GOOS Philosophy
- Address your non-functional challenges asap
- Antidote against technical debt
Operations
I guess that is ready
Don't guess, double check
2. Testing
Testing
The parts are working, so the whole
Testing: The parts are working, so the whole
Distributed testing
Don't give up on unit testing
But that's not enough
Testing: The parts are working, so the whole
Contract testing
Start designing your APIs with respect
The customer is always right
Testing: The parts are working, so the whole
Smoke testing
We need more than a red test
Centralised logging and correlation ids
Testing
The parts are working, so the whole
Don't understimate the complexity of distributed systems
Testing
Testing is always good
Testing: Testing is always good
Testing trade-offs
- Micro unit tests
- Slow tests
- Hard to read/write tests
Testing: Testing is always good
Trade-offs are just trade offs
- Micro unit tests
- Slow tests
- Hard to read/write tests
Testing
Testing is always good
As long as you understand the trade-offs
3. Design
Design
Language approximations are ok
Design: Language approximations are ok
Bounded Contexts
Core DDD concept
Impact mapping or even Event Storming can help you to identify them
Design: Language approximations are ok
Hexagonal Architecture
Design
Language approximations are ok
Often I think that our profession is closer to literature than maths
Design
Business needs are stable
Design: Business needs are stable
CQRS
Design: Business needs are stable
CQRS
Extremely perfomant
Adds overhead
Design
Business needs are stable
That's not true. Design with that in mind.