This document discusses the importance of developing software with a pessimistic mindset by anticipating errors and unexpected inputs rather than assuming everything will work correctly. It recommends techniques like defensive coding with input validation, assertions and error handling, designing by contract to define responsibilities and exceptions, and programming deliberately by expecting the unexpected and writing code that is robust to unintended use cases. The goal is to build software that is resilient to human and technical errors rather than fragile.

1. PESSIMISTIC DEVELOPMENT
YOU CAN'T WRITE PERFECT SOFTWARE

2. I write perfect code.
— Me

4. HOW WE DRIVE
> We like to think we are the best
> We drive defensively
> Anticipate the unexpected

5. WE CODE LIKE
WE DRIVE...

6. WE BELIEVE WE ARE THE
BEST DEVELOPER OUT
THERE.

7. THIS IS SHOWN THROUGH DEFENSIVE
CODING
> We validate
> Use Assertions
> Check for Consistency

8. BUT DON'T
TRUST
YOURSELF

9. BUILDING A PESSIMISTIC APPROACH
> Design By Contract
> Program for the Impossible
> Assertive Programming
> Alert Gracefully

10. DESIGN BY
CONTRACT

11. WHAT DOES A CONTRACT
LOOK LIKE IN REAL LIFE?

12. WHAT DOES A CONTRACT LOOK LIKE IN
CODE?
> Defines Your Rights
> Defines Responsibilities

13. DOCUMENT YOUR CONTACT KEY ELEMENTS
> Responsibility of your code
> Inputs
> Outputs
> Exceptions that can be thrown.

14. CONTRACTS IN CODE
public interface IRepository<TEntityType>
{
ApplicationUser CurrentUser { get; set; }
IQueryable<TEntityType> GetAll();
TEntityType Get(int id);
IQueryable<TEntityType> FindBy(Expression<Func<TEntityType, bool>> predicate);
TEntityType Add(TEntityType entity);
void Delete(TEntityType entity);
void Delete(int entity);
TEntityType Edit(TEntityType entity);
void Save();
}

15. PROGRAM DELIBERATELY
NOT BY COINCIDENCE
> Always be Aware of what you are doing - Stone Soup &
Boiled Frogs
> Don't Code Blindfolded
> Proceed from a plan
> Rely on reliable things -

16. PROGRAM FOR
THE
IMPOSSIBLENO ONE WOULD EVER DO THAT...

17. USERS AREN'T THE ONLY
ONE WHO CREATE
UNEXPECTED

18. THIS CODE WON'T BE USED 30 YEARS
FROM NOW, SO TWO-DIGIT DATES ARE
FINE

19. NO ONE WOULD PASS NULL TO US
SINCE IT COMES FROM THE DATABASE...

20. WE MAKE BIG
ASSUMPTIONS THAT CAN
LEAD TO TROUBLE.

21. EXPECT THE UNEXPECTED
DON'T
var something = obj.prop.name;
DO
var something;
if (obj && obj.prop && obj.prop.name)
{
something = obj.prop.name;
}

22. ASSERTIVE
PROGRAMMING

23. C# EXAMPLE
public ProductDto ConvertProductToDto(Product product)
{
if (product == null) throw new ArgumentNullException("product");
...
return productDto;
}

24. TESTING ASSERTIONS
[TestMethod]
[ExpectedException(typeof(ArgumentNullException),
"A product of null was inappropriately allowed.")]
public void NullProductInConversion()
{
var productDto = new ConvertProductToDto(null);
}

25. HANDLING ASSERTIONS WITH GRACE
> Alert User of Error
> When calling another component/service/module,
expect the unexpected
> Be proactive with assertions in your own code

26. PRACTICAL USES
> Always alert errors in promises error block
> Log API errors to services like BugSnag (and deal with
them)