Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

If the problem is the definition ?

Slide 3

Slide 3 text

-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 »

Slide 4

Slide 4 text

Software Engineering Arnaud LEMAIRE | @lilobase Lgo.group

Slide 5

Slide 5 text

What is engineering Practitioners Academia Drive Refine Glenn Vanderburg

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Problem space Solution space

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Client specification

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

We have no humans in the production side

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

Engineering Production Specifications

Slide 21

Slide 21 text

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)

Slide 22

Slide 22 text

Engineering Production Source code The compiler

Slide 23

Slide 23 text

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)

Slide 24

Slide 24 text

-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 »

Slide 25

Slide 25 text

Engineering is about feedback loop

Slide 26

Slide 26 text

Empirical Defined Chemical Electrical Civil Aviation Aerospatial

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Having the right event horizon

Slide 35

Slide 35 text

Time Features Time Features Time Features Time Features

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Time Features Technical debt Reimbursement

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Being a professional

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Ask for trust, Not toys

Slide 45

Slide 45 text

Engineering is about designing solution

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Thanks ! Arnaud LEMAIRE | @lilobase Lgo.group

Slide 48

Slide 48 text

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