In these slides I'll try to show how different delusions can drive our development and how we can counteract them. Going through operations, design and testing I'll provide examples based on real experience fighting against those delusions. As spoiler I can tell you that we'll have a look on exciting topics like Command Query Responsibility Segregation, Distributed Systems or Testing Trade-Offs.

1. DELUSION DRIVEN
DEVELOPMENT
AND WHY YOU SHOULDN'T DO IT
Created by /Felipe Fernández @felipefzdz

2. ABOUT ME
FELIPE FERNÁNDEZ
Work as Software Craftsman for
Currently with
Blog: http://codurance.com/blog/author/felipe-fernandez
Twitter:
Codurance
Crowdmix
@felipefzdz

3. DEFINING DELUSION
“An idiosyncratic belief or impression
maintained despite being contradicted by
reality or rational argument, typically as a
symptom of mental disorder.”

4. ABOUT THE TALK
1. Operations
2. Testing
3. Design

5. 1. OPERATIONS

6. OPERATIONS
I’LL HAVE A LOOK WHENEVER IS NEEDED

7. 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

8. OPERATIONS: I’LL HAVE A LOOK WHENEVER IS NEEDED
DIAGNOSIS METHODOLOGIES
Debugging
Querying datastores
Logging

9. OPERATIONS: I’LL HAVE A LOOK WHENEVER IS NEEDED
DISTRIBUTED DIAGNOSIS METHODOLOGIES
Debugging -> LOL
Querying datastores -> Fragmentation
Logging -> Madness

10. OPERATIONS
I’LL HAVE A LOOK WHENEVER IS NEEDED
Please don't, it could be really hard and you want to be
prepared

11. OPERATIONS
I NEED TO REMOVE THAT DUPLICATION NOW

12. OPERATIONS: I NEED TO REMOVE THAT DUPLICATION NOW
GENERALISING DEPLOYMENT PIPELINES
DIY deployment pipelines
Microservices context

13. OPERATIONS: I NEED TO REMOVE THAT DUPLICATION NOW
GENERALIZATION ASSUMPTIONS
Versioning
Checking
Continuous integration

14. OPERATIONS
I NEED TO REMOVE THAT DUPLICATION NOW
Do it when you're stable enough

15. OPERATIONS
I GUESS THAT IS READY

16. OPERATIONS: I GUESS THAT IS READY
CREATING REAL WALKING SKELETONS
That includes provisioning and deploying
Smoke test as driver

17. OPERATIONS: I GUESS THAT IS READY
GOOS PHILOSOPHY
Address your non-functional challenges asap
Antidote against technical debt

18. OPERATIONS
I GUESS THAT IS READY
Don't guess, double check

19. 2. TESTING

20. TESTING
THE PARTS ARE WORKING, SO THE WHOLE

21. TESTING: THE PARTS ARE WORKING, SO THE WHOLE
DISTRIBUTED TESTING
Don't give up on unit testing
But that's not enough

22. TESTING: THE PARTS ARE WORKING, SO THE WHOLE
CONTRACT TESTING
Start designing your APIs with respect
The customer is always right

23. TESTING: THE PARTS ARE WORKING, SO THE WHOLE
SMOKE TESTING
We need more than a red test
Centralised logging and correlation ids

24. TESTING
THE PARTS ARE WORKING, SO THE WHOLE
Don't understimate the complexity of distributed systems

25. TESTING
TESTING IS ALWAYS GOOD

26. TESTING: TESTING IS ALWAYS GOOD
TESTING TRADE-OFFS
Micro unit tests
Slow tests
Hard to read/write tests

27. TESTING: TESTING IS ALWAYS GOOD
TRADE-OFFS ARE JUST TRADE OFFS
Micro unit tests
Slow tests
Hard to read/write tests

28. TESTING
TESTING IS ALWAYS GOOD
As long as you understand the trade-offs

29. 3. DESIGN

30. DESIGN
LANGUAGE APPROXIMATIONS ARE OK

31. DESIGN: LANGUAGE APPROXIMATIONS ARE OK
BOUNDED CONTEXTS
Core DDD concept
Impact mapping or even Event Storming can help you to
identify them

32. DESIGN: LANGUAGE APPROXIMATIONS ARE OK
HEXAGONAL ARCHITECTURE

33. DESIGN
LANGUAGE APPROXIMATIONS ARE OK
Often I think that our profession is closer to literature than
maths

34. DESIGN
BUSINESS NEEDS ARE STABLE

35. DESIGN: BUSINESS NEEDS ARE STABLE
CQRS

36. DESIGN: BUSINESS NEEDS ARE STABLE
CQRS
Extremely perfomant
Adds overhead

37. DESIGN
BUSINESS NEEDS ARE STABLE
That's not true. Design with that in mind.

38. THANK YOU

39. ANY QUESTIONS?