http://www.ieee-scam.org/2021/#keynotes From the NATO conferences held 50 years ago that blessed its usage, the term "software engineering" has been used by the industry as shorthand for "keeping code easy to understand and evolve by teams." We often use the term in contrast with "computer science," generally understood as "the science (and art) of efficiently solving abstract computational problems." This goal has ultimately become the kingmaker of paradigms, programming languages, design patterns, architectures, and even code editors. Object-Orientation, Test-Driven Development, Agile Methods, refactoring, Continuous Integration, Domain-Driven Design are examples of what the industry has produced and consumed over decades, focused on building and maintaining increasingly larger codebases that can stand the test of time. In the last decade, I have seen a subtle yet increasingly more evident shift in priorities. Over the last decade, small companies with just a few engineers need to build systems that support hundreds of millions of users before it even has a working business model. After a long trial-and-error period, we have established things like microservices, serverless computing, and crash-only software as the most practical way to build this type of software. In this new mindset, the rules have changed. We don't build software to last—we don't know if our companies will last! So instead, we make software focusing on time-to-market and the ability to quickly adapt to new requirements as our businesses pivot, searching for the holy grail of product/market fit. In this session, I will walk you through how I perceive the changes that this industry has been through since I first started my career twenty years ago and what implications and new open questions this new reality brings to the field of software engineering. Phil Calçado is Senior Director of Engineering at SeatGeek, where he leads the team that builds the live events platform used by 44 million people worldwide. Before SeatGeek, he has led the platform team at Meetup/WeWork, worked on Linkerd—the pioneering Service Mesh, and headed product engineering for DigitalOcean and SoundCloud, both pioneers in the adoption of Microservices architectures.

1. The inevitable
Phil Calçado | @pcalcado
https://philcalcado.com
emergence of
write-only
software

2. the first time I
worked on a
large system as
in 2004

3. my company
had first
developed that
system in 1994

4. it was
(arguably) the
1st prepaid
billing system
for GSM
networks ever

5. and ten years later
we were still fixing
bugs and adding
features to it

6. For the next
ten years, I was
obsessed with
maintainable
software

7. books, workshops,
articles, meetups

8. expressive code
Literate Programming
Domain-Driven Design
Domain-Speci
fi
c Languages

9. executable specifications
Documentation
Test-Driven Design
Behavior-Driven
Development

10. release management
Long-lived Branches
Continuous Integration
Continuous Delivery

11. a huge
industry
was built
on these

12. "model software
development as
closely as possible
to the business”

13. we’ve been
talking about
this forever

15. it’s just that
the business
keeps getting
more fast-paced

17. and it gets
even more
interesting…

18. investors put
money on teams,
not products

20. pivot-driven
development?

21. an
oversimplified
real-world
illustration

23. I inherited the
“member list”
project

26. 8 engineers
2 consultants
24 months
$500k/year infra cost

27. “what is the biggest
business challenge we
have?”

29. “we have no idea what
we are supposed to do”

30. User Experience
Database
Database
Database
User Experience
Consumer
Website
Admin
Web App
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda
λ
Lambda

31. 2 engineers
1 consultant
3 months
<$10k/year infra cost

32. some practical
implications

33. APIs are more
important than
internal code quality

34. complexity is moving
to the platform
Circuit breakers
Timeouts
Biz Logic
Timeouts
Telemetry
RPC code
Distributed state
Client-side
Service Discovery
Service
Plaform

35. these are table stakes

36. finally: do not get too
attached to your code

37. Phil Calçado | @pcalcado
https://philcalcado.com