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

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

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

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

September 21, 2018
Tweet

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
  2. If the problem is the definition ?

  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 »
  4. Software Engineering Arnaud LEMAIRE | @lilobase Lgo.group

  5. What is engineering Practitioners Academia Drive Refine Glenn Vanderburg

  6. Problem space Solution space Goal to achieve Business context Solution

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

    environment } Design Construction Operation { Development
  8. None
  9. Problem space Solution space

  10. -Box, George E. P.; Norman R. Draper Empirical Model-Building and

    Response (1987) « Essentially, all models are wrong, but some are useful. »
  11. Client specification

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

    medium Fast
  13. -Unknown « Models are useless, Modeling is everything » Because

    they are quickly outdated Because we can share a common understanding
  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
  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
  16. Making specific software TECHNIQUE BUSINESS GENERIC SPECIFIC No technical Unfair

    advantage You loose Your specificity DDD
  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
  18. We have no humans in the production side

  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.
  20. Engineering Production Specifications

  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)
  22. Engineering Production Source code The compiler

  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)
  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 »
  25. Engineering is about feedback loop

  26. Empirical Defined Chemical Electrical Civil Aviation Aerospatial

  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.
  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
  29. Something is valuable once it is delivered, before that it

    is just wast Focus on Continuous Integration, everything else will follow…
  30. None
  31. Constraint theory C: C4 A: C5 B: C6 D: C8

    E: C6 Throughput: 4
  32. -Fred Brooks in his 1975 book The Mythical Man-Month «

    adding human resources to a late software project makes it later »
  33. Do not use your previous step at 100%, you are

    creating waste. Adopt a pull based approach on your delivery pipeline
  34. Having the right event horizon

  35. Time Features Time Features Time Features Time Features

  36. The quality of today is the productivity of tomorrow Quality

    is free… (over quality doesn’t exists) – Jean-Baptiste Dusseaut @BodySplash
  37. Know when you can buy technical debt, But beware of

    its management Do you have the time to build it twice ?
  38. Time Features Technical debt Reimbursement

  39. Acknowledge the fact that you can’t foresee the futur Keep

    your options open, work on your technical reversibility
  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
  41. Being a professional

  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
  43. Take your responsibilities It is not « normal » that

    a software doesn’t work But don't let anyone else make commitments for you
  44. Ask for trust, Not toys

  45. Engineering is about designing solution

  46. You need to go beyond Clean code Our job is

    to create application, not writing —beautiful— code
  47. Thanks ! Arnaud LEMAIRE | @lilobase Lgo.group

  48. Going further • Glenn Vanderburg — Real Software Engineering •

    Uncle Bob — The Reasonable Expectations of your new CTO • Jack W Reeves — What Is Software Design?