This document discusses challenges with software projects from the perspective of CEOs and managers. It uses construction and airport projects as metaphors to illustrate how custom software systems are complex and unique like large infrastructure projects. Planning for software is difficult as initial plans often prove wrong, so failures need to be planned for through feature slip deadlines and time slip requirements. Software complexity grows exponentially with team size due to communication overhead, but techniques like pair programming can help manage this. Ultimately, prioritizing speed and features over quality will undermine the business, so an iterative approach focusing on delivering working software regularly is recommended.

1. Software Engineering
for CEOs
Gabe Hamilton

2. And Product Managers, Tech Writer, Implementers, etc...
all the members of a software ecosystem.

3. a lot of companies are Software companies

4. and you’re
wondering...
When will it
be done?
*specifically when will Mario Kart 8 be done

5. Or you’re an engineer who needs to Communicate about software projects.

6. And engineers forget
Engineers become Director, CTO, CEO
and start wondering,
“when will it be done?”

7. The Problem with
Software Projects

8. Problems
The right Metaphor
Diseconomy of Scale
Knowledge Work Trilemma

9. Problems
The right Metaphor - Planning
Diseconomy of Scale - Communication
Knowledge Work Trilemma - Speed / Features /
Quality

10. Planning
Scaling Communication
Speed / Features / Quality
Problems Solutions
Agile planning
Pair Programming
Feature-Slip Iterations
Team Size
Hiring

11. Planning
Communication
Speed / Features / Quality
Problems Tech Solutions
Test Driven Development
Distributed Version Control
Continuous Integration
Deployment Pipeline

12. Problems
The right Metaphor - Planning

13. Construction
Everyone has at least some familiarity with
Construction so it’s a natural metaphor.
And it works fairly well
For the right kind of construction project

14. Building houses is a good metaphor for
installing software
Repeat roughly the same process many times and expect some variability.
Putting together a shed takes days, building a house takes weeks.
Installing a program on your computer takes 10 minutes, setting up a server
may take a few days.

15. Building something new
Something that
has never been
done before.
Software that will
make a mark on
the world!

16. Custom Software Systems
Have more in common with large,
ambitious construction projects.
Huge bridges, tunnels under the
ocean, mag-lev rail lines.
Billion dollar projects

17. In other words things that fail

18. Airports are a good metaphor for
software engineering.

19. Major Airports
Start operating when
partway done.
Each one is different.
Try difficult new things.

20. Projected Cost: $1.1 Billion
Actual Cost: $4.8 Billion 16 months late
Unique feature: automated baggage system

21. Projected Cost: $7.5 Billion
Actual Cost: $20 Billion
Unique feature: built on the ocean

22. https://www.infoq.com/articles/standish-chaos-2015

23. In my experience
10 large,
multi-year
software
projects.
Three that were
“challenged”, ie
way over time
and budget.
Each of the
three had a
well defined
plan of what
to build over
the next year.
Two were built over five years.
One was stopped after two years.

24. Solutions
We have found a useful metaphor for discussing
software.
It has construction and operations at the same
time. It is complex and unique.
However it is a cautionary tale, “Don’t build
software as a mega-project unless you want to fail
like a mega-project.”

25. Solutions
Fortunately we
don’t have the
same
constraints as a
mega-construc
tion project.
We can plan viable standalone
pieces.
We can deliver those pieces and
get feedback (MVPs)
Especially if we plan to open
before the whole thing is
complete.

26. Solutions
We can plan for failure.
If we know our plan won’t
be right, how do we fail
gracefully.
Deadlines need to be
feature slip.
Required features need
to be time slip.

27. Diseconomy of Scale
Programs are extremely complex.
To change one you need to know how it works.
*where ½ = lots. Other half is rumored to consist of perspiration & inspiration.
Software is ½*
communication

28. Imagine a
flowchart
that explains what
1 programmer
wrote today.

29. Collect each day’s in a book
Add a page
explaining how
it relates to
yesterday’s
flowchart.

30. Give this book to the new person
Would you like
everyone else’s book
from this month?

31. Brooks’s law
adding [people] to a late
software project makes it
later
"Nine women can't make a baby in one month."

32. Communication Paths
1 person
2 people
what was I doing 3
months ago?

33. Communication Paths
3 people
4 people
3 paths
6 paths

34. # of Communication Paths
1st person has a path to each of the others
2nd person needs a path to everyone except the 1st, …
4 people = 6 paths = 3 + 2 + 1
5 people = 10 paths = 4 + 3 + 2 + 1
It’s the Summation of 1..N-1 = (N-1 x N) / 2
yay, combinatorial growth

35. 6 people
8 people
15 paths
21 paths?
?
?
?

36. 12 people
20 people
66 paths
190 paths
100 people ~5,000 paths
?
? ?
?

37. Now wait
We have 65 years of solutions to this
problem, just in software.
Hierarchy, teams, departments; Procedural,
Imperative, Functional, OO Programming;
APIs; Extreme, Agile, Scrum, Kanban Iterations;
project, product, development - lead, manager,
architects.

38. Many forms of Communication
More managers: build system managers, report managers.
Teams that build and maintain layers of communication
between other teams (APIs).
Technical debt as lack of communication, lurking problems
and inefficiencies throughout the code.

39. Solutions
The Surgical Team
We can only cluster 8
people around each
patient.
Pair Programming
Consistently pay
communication costs
upfront.
Hiring
Great people who get
more done means less
communication load.
Version Control, CI,
Branching / Merging
strategies
Communication flows
and gateways.

40. Trilemma: you can constrain two, the
third will move.
Speed, Features, Quality

41. Speed Features
Quality
Development Cost
Sales
Sales
Maintenance Cost
There are many constraints in building software, most of them are tied to the core
tradeoff between Speed, Features, and Quality.

42. Speed Features
Quality
There is a lot of pressure in favor of Speed and Features
And for decades this was the dominant shape

43. 4pts
Next round, you have 6 points
Start with 10 points
Quality determines the speed limit
Every few months you have to reallocate.
4pts
2pts

44. Speed Deal Value
Quality
Sales for example
Same tradeoff in other knowledge work
I need you to sell $100K to these 25 customers this month

45. Our sales team will have the same problems
Bad requirements: these couple customers aren’t qualified
Can they be sold in a month?
I don’t know, I haven’t talked to anyone at the company yet.
Ok we sold them all!
Just don’t look at how we had to squeeze quality to do so (sold features we
don’t have, unrealistic timelines, etc)

46. Speed Features
Quality
Some options
A strategy from Open Source projects: Even / Odd releases
Stability release New feature release

47. Solutions
Agile planning
Deliver regularly
(Iterations)
Feature-Slip what makes
it into those iterations.
Hold Quality Constant
with
Pair Programming
Test Driven Development
Continuous Integration

48. Solutions
Next level
Continuous Delivery

49. “In Summary
“We need to get these
features in by the
deadline”
will kill your business.

50. CREDITS
Special thanks to all the people who made and
released these awesome resources for free:
╺ Presentation template by SlidesCarnival
╺ Photographs by Unsplash
Image Attributions
CEO cat http://mrg.bz/z9CBmN
Mountain http://mrg.bz/taTQ1v
4 books http://www.morguefile.com/archive/display/189153
Software Engineer
http://en.wikipedia.org/wiki/File:Coding_Shots_Annual_Plan_h
igh_res-5.jpg
Flowchart
http://commons.wikimedia.org/wiki/File:Euclid_flowchart_1.pn
g
Single Textbook http://en.wikipedia.org/wiki/File:Textbook.JPG
Fred Brooks
http://commons.wikimedia.org/wiki/File:Frederick_Brooks_IMG
_2261.jpg

51. Software Engineering
for CEOs
Gabe Hamilton