Entre industrialisation et artisanat, le métier de développeur – Meetup SoftwareCrafters Rennes 2019

Une conférence pour se poser la question de ce qu’est notre métier, et de pourquoi celui-ci est loin de se borner à la simple écriture de code source.

De comment sortir de la posture du développeur en tant que simple exécutant, et pourquoi notre métier a une très forte dimension stratégique.

Enfin en regardant nos pratiques, méthodes et outils, nous replacerons ceux-ci dans leurs contextes en posant la question de ce qu’est l’ingénierie logicielle.

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. -Martin Fowler
 BuildingArchitect « In particular an architect is not responsible for the structural integrity of the building. 
 That's the role of the structural engineer »
6. What is engineering Practitioners Academia Drive Refine Glenn Vanderburg
7. But in our field Practitioners Academia Ignore Dictate Glenn Vanderburg
9. Client specification
10. -Box, George E. P.; Norman R. Draper Empirical Model-Building and Response (1987) « Essentially, all models are wrong, but some are useful. »
11. Problem space Solution space
12. -Unknown « Models are useless, Modeling is everything » Because they are quickly outdated Because we can share a common understanding
13. Problem space Solution space Problem space Solution space Goal to achieve Business context Solution environment } Design Construction Operation { Engineering
14. Problem space Solution space Problem space Solution space Goal to achieve Business context Solution environment } Design Construction Operation { Development
15. Different pace of changes Problem space Solution space Slow to medium Fast
16. 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
17. 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
18. Making specific software TECHNIQUE BUSINESS GENERIC SPECIFIC No technical Unfair advantage You loose Your specificity DDD
19. 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
20. We have no humans in the production side
21. 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.
22. Engineering Production Specifications Architecte Business analyst Developpers
23. 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)
24. Engineering Production Source code The compiler Developpers
25. -Unknown « What goes in production is what developers have understood »
26. « Du téléphone arabe Enterprise Edition™ » Utilisateur final Chef de projet Cahier des charges fonctionnel Lead technique Cahier des charges technique Développeurs
27. « Du téléphone arabe Enterprise Edition™ » Utilisateur final DSI Client MOA AMOA MOE Développeurs
28. 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)
29. -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 »
30. Engineering is about feedback loop
31. Empirical Defined Chemical Electrical Civil Aviation Aerospatial
32. 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.
33. Risk management Reduce your feedback loop Continuous Delivery A delivered feature is no longer a risk !
34. Validation over guess & illusions Smaller batch Tell smaller lies Stop tracking progress, start to experience it
35. A development task has only 3 states Not yet started Finished Almost done
36. C: C4 A: C6 B: C6 D: C8 E: C6 Often the production team You are producing waste And creating stress And because they don’t trust the delivery, they start to pile requests up
37. You need to switch from a push- based to a pull-based approach
38. -Fred Brooks in his 1975 book The Mythical Man-Month « adding human resources to a late software project makes it later »
39. 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
41. Something is valuable once it is delivered, before that it is just wast Focus on Continuous Integration, everything else will follow…
42. Having the right event horizon
43. Time Features Time Features Time Features Time Features
44. The quality of today is the productivity of tomorrow Quality is free… (over quality doesn’t exists) – Jean-Baptiste Dusseaut @BodySplash
45. Know when you can buy technical debt, But beware of its management Do you have the time to build it twice ?
46. Acknowledge the fact that you can’t foresee the futur Keep your options open, work on your technical reversibility
47. 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
48. Being a professional
49. 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
50. - @jasongorman « 1998: "You should build systems out of single-purpose loosely-coupled components 2008: "You should build systems out of single-purpose loosely-coupled components" 2018: "You should build systems out of single-purpose loosely-coupled components" Technology changes so fast! »
51. Ask for trust, Not toys
52. You need to go beyond Clean code Our job is to create application, not writing —beautiful— code
53. Take your responsibilities It is not « normal » that a software doesn’t work But don't let anyone else make commitments for you
55. Thanks ! Arnaud LEMAIRE | @lilobase Lgo.group
56. Going further • Glenn Vanderburg — Real Software Engineering • Uncle Bob — The Reasonable Expectations of your new CTO • Jack W Reeves — What Is Software Design?