How did we end up here? Trisha Gee - @trisha_gee Todd Montgomery - - - PowerPoint PPT Presentation

▶
how did we end up here
SMART_READER_LITE
LIVE PREVIEW

How did we end up here? Trisha Gee - @trisha_gee Todd Montgomery - - - PowerPoint PPT Presentation

Mar 01, 2023 321 likes •1.36k views

How did we end up here? Trisha Gee - @trisha_gee Todd Montgomery - @toddlmontgomery Shout out: Martin Thompson - @mjpt777 How bad can things really be? Software Project Success Rates Successful Challenged Failure Ad-hoc 49% 37% 14%

slide-1
SLIDE 1

How did we end up here?

Trisha Gee - @trisha_gee Todd Montgomery - @toddlmontgomery Shout out: Martin Thompson - @mjpt777

slide-2
SLIDE 2
slide-3
SLIDE 3
slide-4
SLIDE 4
slide-5
SLIDE 5
slide-6
SLIDE 6

How bad can things really be?

slide-7
SLIDE 7

Successful Challenged Failure

Ad-hoc 49% 37% 14% Iterative 61% 28% 11% Agile 60% 28% 12% Traditional 47% 36% 17% Software Project Success Rates

  • Dr Dobbs 2010
slide-8
SLIDE 8

< 10 11 - 25 > 25

Ad-hoc 70% 58% 40% Iterative 88% 68% 55% Agile 83% 70% 55% Traditional 69% 51% 50% Software Project Success Rates – by Team Size

  • Dr Dobbs 2010
slide-9
SLIDE 9

Well that‟s the

  • ptimistic view!
slide-10
SLIDE 10

Successful: 32% Challenged: 44% Failure: 24%

– Standish Group Chaos Report 2010

Software Project Success Rates

slide-11
SLIDE 11

< $350,000: 20% $350,000 - $1,000,000: 25% > $1,000,000: 28%

– Gartner 2012

Software Project Failure Rates

slide-12
SLIDE 12

In a study of over 5400 large scale projects (> $15m) 17% go so badly that they threaten the existence of the company undertaking them

– The McInsey Group with Oxford University 2012

slide-13
SLIDE 13

Sacred Cows - It’s BBQ Time!!!

slide-14
SLIDE 14

Enterprise Software

slide-15
SLIDE 15

ent•ter•prise

noun \ˈen-tə(r)-ˌprīz\ : a project or activity that involves many people and that is often difficult : the ability or desire to do dangerous or difficult things or to solve problems in new ways

Source: http://www.merriam-webster.com/

slide-16
SLIDE 16

Naming Matters !!!

slide-17
SLIDE 17
slide-18
SLIDE 18
slide-19
SLIDE 19

Product Management

slide-20
SLIDE 20

Minimum Viable Product ?

slide-21
SLIDE 21

Product Owner ?

slide-22
SLIDE 22
slide-23
SLIDE 23

Technologists ARE part of the business

slide-24
SLIDE 24

Take responsibility for ROI

slide-25
SLIDE 25

How can I get an answer for the minimum investment?

slide-26
SLIDE 26

Agile Methods

slide-27
SLIDE 27
slide-28
SLIDE 28
slide-29
SLIDE 29

Water-scrum-fall

slide-30
SLIDE 30

What really matters?

slide-31
SLIDE 31

Need to focus on learning, feedback cycles, and outcomes

slide-32
SLIDE 32

There is an uncomfortable truth…

slide-33
SLIDE 33

“What would have been different if you were not involved?”

slide-34
SLIDE 34

Shared Mutable State

slide-35
SLIDE 35

“…Shared Mutable State...” the most feared words in computing

slide-36
SLIDE 36

…if not they should be!

slide-37
SLIDE 37
slide-38
SLIDE 38
slide-39
SLIDE 39

Shared Mutable State should only be used for systems programming

slide-40
SLIDE 40

Embrace append-only, single writer, and shared nothing designs

slide-41
SLIDE 41

If you don‟t... math will hunt you down and there is nowhere to hide!

slide-42
SLIDE 42

Universal Scalability Law

2 4 6 8 10 12 14 16 18 20 1 2 4 8 16 32 64 128 256 512 1024

Speedup Processors

Amdahl USL

slide-43
SLIDE 43

Be ruthless in reducing complexity

slide-44
SLIDE 44

Text Encoding

slide-45
SLIDE 45
slide-46
SLIDE 46

But it‟s human readable...

slide-47
SLIDE 47

Binary is hard to work with...

slide-48
SLIDE 48
slide-49
SLIDE 49
slide-50
SLIDE 50

Big Data

slide-51
SLIDE 51

Communications Battery life and bandwidth?

slide-52
SLIDE 52

Synchronous Comms

slide-53
SLIDE 53

Bad things will happen!!!

slide-54
SLIDE 54

Synchronous Communication is the crystal meth of distributed programming

slide-55
SLIDE 55

Causes a coupling in location and time

slide-56
SLIDE 56

Errors need to be first class messages

slide-57
SLIDE 57

Are your micro services

  • n crystal meth?
slide-58
SLIDE 58

Abstraction

slide-59
SLIDE 59

“All non-trivial abstractions, to some extent, are leaky.”

  • Joel Spolsky
slide-60
SLIDE 60

“The detail of underlying complexity cannot be ignored.”

slide-61
SLIDE 61

“the purpose of abstracting is not to be vague, but to create a new semantic level in which

  • ne can be absolutely precise”
  • Dijkstra
slide-62
SLIDE 62

We could say the main issue is that people don‟t understand abstractions...but...

slide-63
SLIDE 63

Sins committed in the name of Abstraction

slide-64
SLIDE 64

ORMs !!!

slide-65
SLIDE 65

Functional Programming

slide-66
SLIDE 66

What is the biggest issue with functional programming?

slide-67
SLIDE 67

Functional Programmers

slide-68
SLIDE 68

Functional programming is

NOT

the answer to multi-core

slide-69
SLIDE 69

Software Transactional Memory was a failed experiment!

slide-70
SLIDE 70

Universal Scalability Law

2 4 6 8 10 12 14 16 18 20 1 2 4 8 16 32 64 128 256 512 1024

Speedup Processors

Amdahl USL

slide-71
SLIDE 71

No Mechanical Sympathy?

slide-72
SLIDE 72

However there is genuine brilliance in functional programming

slide-73
SLIDE 73

Collaborate and great things can happen...

slide-74
SLIDE 74

Throw hardware at it… development is too expensive

slide-75
SLIDE 75

The free lunch is over… we cannot be sloppy anymore…

slide-76
SLIDE 76

Code must be simple and composable

slide-77
SLIDE 77

Cache Sub-System

L1(D) - 32K L2 - 256K L3 – 8-20MB LF/WC Buffers L1(I) – 32K L0(I) – 1.5k µops

32 Bytes / cycle

System Agent TLB Pre-fetchers TLB Pre-fetchers

128 bits / cycle

MOB Memory Controller QPI

QPI Bus Memory Channels 16 Bytes / cycle Ring Bus

PCI-e Controller

32 Bytes / cycle 32 Bytes / cycle

slide-78
SLIDE 78

Patterns of access and locality are key to performance

slide-79
SLIDE 79

Accumulated Improvement Time Bandwidth Latency

Memory Sub-System Performance

slide-80
SLIDE 80

Accumulated Improvement Time Network Bandwidth Response Time Storage Capacity CPU Cores Memory Capacity

slide-81
SLIDE 81

What does this mean for software?

slide-82
SLIDE 82
slide-83
SLIDE 83

Think in terms of transformation and flow of data – not code!

slide-84
SLIDE 84

Diversity

slide-85
SLIDE 85

Testosterone Driven Development

slide-86
SLIDE 86
slide-87
SLIDE 87

What did the Carnegie Mellon studies show?

slide-88
SLIDE 88
slide-89
SLIDE 89
slide-90
SLIDE 90

Fake it until you make it…

slide-91
SLIDE 91

“As soon as you realise that most people don‟t know what they are doing the world makes a lot more sense…”

– Farley’s second law

slide-92
SLIDE 92

We need to look seriously at training programmers

slide-93
SLIDE 93

Coaching and Apprenticeships

slide-94
SLIDE 94

“The most important thing I've accomplished, other than building the compiler, is training young people.”

  • Grace Hopper
slide-95
SLIDE 95

“'Do you think we can do this?' I say, „Try it.‟ And I back 'em up. They need that. I keep track of them as they get older and I stir 'em up at intervals so they don't forget to take chances.

  • Grace Hopper
slide-96
SLIDE 96

In closing…

slide-97
SLIDE 97

What are the greatest achievements

  • f the human race?
slide-98
SLIDE 98

The Scientific Method

slide-99
SLIDE 99

Understanding of Evolution

slide-100
SLIDE 100

Don‟t feel bad… We are living in the era of Software Alchemy

slide-101
SLIDE 101
slide-102
SLIDE 102

Questions?

@trisha_gee – Trisha Gee @toddlmontgomery – Todd Montgomery @mjpt777 – Martin Thompson

“It does not matter how intelligent you are, if you guess and that guess cannot be backed up by experimental evidence – then it is still a guess.”

  • Richard Feynman