The document discusses the history of software engineering and opportunities for its evolution. Over the past 70 years, software projects often ran over budget and time, produced low quality software, and failed to meet requirements. However, the document suggests there are opportunities to improve outcomes by having developers better understand the business domain, having business stakeholders better understand IT, incorporating more mathematics, and designing systems with statelessness and no data sharing to improve composability. To build the future of software engineering, we must learn from its past.

1. The software evolution
hasn’t happened yet

2. http://www.ouarzy.com
@ouarzy

3. Soft vs Hard

4. I’m the law

5. Soft vs Hard

6. Crisis!

7. NATO

8. Let’s do engineering!

9. But it doesn’t work…

10. Let’s try harder!
Cycle en V
Agile
OOP Scrum
FP
RAD
CRUD
XPORM
VueJS
Micro-Services Serverless
React
CQRS/ES
DDD

11. 70 years later… (or 50 after NATO)

12. Results
* Projects running over-budget
* Projects running over-time
* Software was very inefficient
* Software was of low quality
* Software often did not meet requirements
* Projects were unmanageable and code difficult to maintain
* Software was never delivered

13. We’re a cost center
Outcome
(external consultancy)
Income
(core business) Sales
Products
Office
It Department

14. A doom’s profession?

15. Opportunities…

16. Opportunities…
More types

17. Opportunities…
Dev should know your Domain
Business should know your IT

18. Opportunities…
More maths?
stateless + no data sharing = composability

19. Opportunities…

20. Think

21. Conclusion
If we want to evolve, we have to know the past
to build the future.

22. References
Alan Kay
Victor Bret
David West

23. http://www.ouarzy.com
@ouarzy
Merci