Save 37% off PRO during our Black Friday Sale! »

Et si la solution c'était le problème - Agile France 2016

Et si la solution c'était le problème - Agile France 2016

Notre profession aime le challenge : inventer des solutions à des problèmes complexes !

Mais si votre dernière prise de tête sur un code source n'était pas vraiment liée à la difficulté du problème, mais juste au fait que vous ne résolviez pas le bon problème ?

Une ode à la prise de recul avant de foncer tête baissée sur la solution.

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

June 17, 2016
Tweet

Transcript

  1. AGILE FRANCE ET SI LA SOLUTION C’ÉTAIT LE PROBLÈME ?

    @lilobase
  2. IF THE PROBLEM WAS THE SOLUTION ? @lilobase

  3. PROBLEM ?

  4. does the problem even exists ?

  5. Creating a problem Leads to Fought by of your own

    feature creep YAGNI
  6. « Often the right solution is to not write code

    at all solution at all
  7. solving the root cause, not the symptoms…

  8. Solving symptoms is a Leads to Fought by temporary solution

    instability root cause analysis
  9. « You need to be a problem founder before being

    a problem solver finder solver
  10. Wrong problem definition…

  11. Wrong problem statement makes Leads to Fought by errors bugs

    tests
  12. « TDD is a form of Property based testing is

    deductive reasoning inductive reasoning
  13. Searching the solution in the technical field…

  14. Searching solutions in the Leads to software with Fought by

    technical field no added value DDD
  15. « You are not paid for the technical problem you

    solve, but for the business one business technical
  16. Reinventing the [square] wheel…

  17. Making your own Leads to Fought by wheel bad implementation

    benchmarking
  18. « So, no, you shouldn't reinvent the wheel. Unless you

    plan on learning more about wheels, that is. learning wheel - Jeff Atwood
  19. changing the problem perspective…

  20. Wrong perspectives make Leads to Fought by complications accidental complexity

    simplicity Ockham razor principle
  21. « Our job, as a software developer is to contains

    accidental complexity contain complexity
  22. Scaling is not linear in complexity…

  23. Scaling with the Leads to Fought by same solution software

    collapse decoupling software engineering
  24. Micro-services

  25. « Exploration is searching for new solutions while exploitation is

    improving what already works. - Alan Key Exploration exploitation
  26. Scaling implies entropie

  27. Scaling without managing Leads to Fought by entropy software rot

    refactoring
  28. « I’m not a great programmer; I’m just a good

    programmer with great habits - Kent Beck habits great
  29. « If I were given one hour to save the

    planet, I would spend 59 minutes defining the problem and on minute resolving it. -Albert Einstein 59 1
  30. WHEN SOLVING A NEW PROBLEM 1. Do I solve an

    existing problem ? 2. Am I sure I don’t fix a symptom ? 3. Do I have the right problem definition ? 4. Am I searching the solution in the business domaine (and not in the technical field) ? 5. Do I have the right perspective (is the complexity of my problem aligned with the business complexity) ? 6. When scaling an existing solution : restart from 1
  31. « Life is really simple, but we insist on making

    it complicated. -Confucius
  32. MERCI ! @lilobase