Entre industrialisation et artisanat : le métier de développeur – AgilePaysBasque 2018

Transcript

1. Hacker, Artist, Craftsman or Engineer? - Mike Valenty
   Software Engineer vs. Code Artist - codesqueeze
   Am I an engineer? - The Philosopher Developer
   Software Craftsmanship is not Software Engineering
   Programming is not a craft | Dan North
   Don't be a Coder, Engineer, or Developer: be a Software Artisan
   

   View Slide

2. If the problem is the
   definition ?
   

   View Slide

3. -Billy Vaughn Koen in Definition of the Engineering Method
   « The engineering method is the use of heuristics to
   cause the best change in a poorly understood or
   uncertain situation within the available resources »
   

   View Slide

4. Software Engineering
   Arnaud LEMAIRE | @lilobase
   Lgo.group
   

   View Slide

5. What is engineering
   Practitioners
   Academia
   Drive Refine
   Glenn Vanderburg
   

   View Slide

6. Problem space
   Solution space
   Goal to achieve
   Business context
   Solution environment
   }
   Design
   Construction
   Operation
   {
   Engineering
   

   View Slide

7. Problem space
   Solution space
   Goal to achieve
   Business context
   Solution environment
   }
   Design
   Construction
   Operation
   {
   Development
   

   View Slide

8. View Slide

9. Problem space
   Solution space
   

   View Slide

10. -Box, George E. P.; Norman R. Draper
    Empirical Model-Building and Response (1987)
    « Essentially, all models are wrong,
    but some are useful. »
    

    View Slide

11. Client specification
    

    View Slide

12. Different pace of changes
    Problem space
    Solution space
    Slow to medium
    Fast
    

    View Slide

13. -Unknown
    « Models are useless,
    Modeling is everything »
    Because they are quickly outdated
    Because we can share a
    common understanding
    

    View Slide

14. Problem space
    Solution space
    Kafka
    Database engine
    Spark
    Java
    REST
    React
    Symfony
    Spring
    This is what you
    must discuss with the
    business
    Not that !
    Data base schema
    Blockchain
    

    View Slide

15. If you stay in the solution space you
    will be treated as specialized technician
    Start with the why and the what,
    and not with the how
    

    View Slide

16. Making specific software
    TECHNIQUE BUSINESS
    GENERIC
    SPECIFIC
    No technical
    Unfair advantage
    You loose
    Your specificity
    DDD
    

    View Slide

17. You need to be confortable outside of
    your confort zone
    This is not what we have studied, what we have
    been trained for and what we are familiar with
    

    View Slide

18. We have no humans
    in the production side
    

    View Slide

19. The final goal of any engineering activity is
    to create some kind of documentation.
    
    When a design effort is complete, the
    design documentation is given to the
    manufacturing team.
    
    This is a different set of people with a
    different set of skills from those of the
    design team.
    
    If the design documents truly represent a
    complete design, the manufacturing team
    can proceed to build the product.
    

    View Slide

20. Engineering
    Production
    Specifications
    

    View Slide

21. After reviewing the software development
    life cycle today,
    
    it appears that the only software
    documentation that actually seems to
    satisfy the criteria of an engineering design
    are the source code listings.
    This is the compiler
    -Jack Reeve
    What is software design (1992)
    

    View Slide

22. Engineering
    Production
    Source
    code
    The compiler
    

    View Slide

23. Living Documentation
    • Behavior Driven Development, Specifications by
    examples…
    
    • Generate docs from your tests, your code, your commit…
    
    • Architecture Decision Records
    
    • Importez votre code dans la documentation (asciidoctor)
    

    View Slide

24. -The Verraes Hypothesis
    « Any tool that lets a non-programmer build
    executable programs will eventually become
    sufficiently complicated that the user is effectively a
    programmer »
    

    View Slide

25. Engineering is about
    feedback loop
    

    View Slide

26. Empirical Defined
    Chemical
    Electrical
    Civil
    Aviation
    Aerospatial
    

    View Slide

27. Formals methods were developed to save money
    when prototyping is too costly.
    The cost is not in the final integration, it is in the
    feedback loop length.
    

    View Slide

28. Feedback loops in software
    engineering
    Time
    Seconds
    Minutes
    Hours
    Days
    Months
    Statements
    & methods
    Classes &
    Interface
    Design
    Architecture
    Features
    Priorities
    Solution
    IDE
    Pair programming
    Unit tests
    System metaphor
    Continuous
    Integration
    On site customer
    Collective ownership
    Acceptance testing
    Type system
    Planning game
    Short releases
    

    View Slide

29. Something is valuable once it is delivered, before
    that it is just wast
    Focus on Continuous Integration, everything else
    will follow…
    

    View Slide

30. View Slide

31. Constraint theory
    C: C4
    A: C5 B: C6 D: C8 E: C6
    Throughput: 4
    

    View Slide

32. -Fred Brooks in his 1975 book The Mythical Man-Month
    « adding human resources to a late
    software project makes it later »
    

    View Slide

33. Do not use your previous step at 100%,
    you are creating waste.
    Adopt a pull based approach on
    your delivery pipeline
    

    View Slide

34. Having the right
    event horizon
    

    View Slide

35. Time
    Features
    Time
    Features
    Time
    Features
    Time
    Features
    

    View Slide

36. The quality of today is the
    productivity of tomorrow
    Quality is free…
    (over quality doesn’t exists)
    – Jean-Baptiste Dusseaut @BodySplash
    

    View Slide

37. Know when you can buy technical debt,
    But beware of its management
    Do you have the time to build it twice ?
    

    View Slide

38. Time
    Features
    Technical debt
    Reimbursement
    

    View Slide

39. Acknowledge the fact that you can’t
    foresee the futur
    Keep your options open,
    work on your technical reversibility
    

    View Slide

40. Complexity has
    four distinct heads
    • States. When there are many elements in the system and each can
    be in one of a large number of states, then figuring out what is
    going on and what you should do about it grows impossible.
    
    • Interdependencies. When each element in the system can affect
    each other element in unpredictable ways, it's easy to induce
    harmonics and other non-linear responses, driving the system out
    of control.
    
    • Uncertainty. When outside stresses on the system are
    unpredictable, the system never settles down to an equilibrium.
    
    • Irreversibility. When the effects of decisions can't be predicted and
    they can't be easily undone, decisions grow prohibitively expensive.
    Taming Complexity with Reversibility — Kent Beck
    

    View Slide

41. Being a professional
    

    View Slide

42. You need to know the foundations
    Not mastering your tool
    When you know the fundamentals, you don’t need
    to learn new tools, you understand them
    

    View Slide

43. Take your responsibilities
    It is not « normal » that a software doesn’t work
    But don't let anyone else make
    commitments for you
    

    View Slide

44. Ask for trust,
    Not toys
    

    View Slide

45. Engineering is about
    designing solution
    

    View Slide

46. You need to go beyond
    Clean code
    Our job is to create application,
    not writing —beautiful— code
    

    View Slide

47. Thanks !
    Arnaud LEMAIRE | @lilobase
    Lgo.group
    

    View Slide

48. Going further
    • Glenn Vanderburg — Real Software Engineering
    
    • Uncle Bob — The Reasonable Expectations of your new CTO
    
    • Jack W Reeves — What Is Software Design?
    

    View Slide