Presented at Agile meets Architecture (2023-10-05) Video at https://www.youtube.com/watch?v=LLEXAdO3X1o One of the (most overlooked) principles of the Manifesto for Agile Software Development is that "Continuous attention to technical excellence and good design enhances agility". All too often, work that focuses on addressing technical issues is deprioritised in the name of focusing on business value. Is there a case for technical excellence — in code, in architecture, in people — beyond its appearance on a might-as-well-be-hidden page on a manifesto that's over two decades old? Is technical excellence only the concern of technical roles? Is a good architecture in conflict with business value or a vehicle for it? This session looks to go beyond buzzwords to build a case for technical excellence that appeals to all roles in a development organisation, noting that "The best architectures, requirements, and designs emerge from self-organizing teams".

1. The case for
technical
excellence
Kevlin Henney

2. @KevlinHenney
@kevlin@mastodon.social
@kevlin.bsky.social
threads.net/@kevlin.henney
instagram.com/kevlin.henney
about.me/kevlin
linkedin.com/in/kevlin
kevlinhenney.medium.com
kevlin@curbralan.com

4. agile, adjective
▪ able to move quickly and easily
Concise Oxford English Dictionary

5. agile, noun
▪ quick movement
The goal pursued by many organisations ‘doing’ agile

6. agile, noun
▪ busyness
The result of many organisations ‘doing’ agile

7. agile, noun
▪ prioritising business goals over
technical excellence
The practice of many organisations ‘doing’ agile

8. agile, noun
▪ undermining business goals by
ignoring technical excellence
The result of many organisations ‘doing’ agile

10. Continuous attention
to technical excellence
and good design
enhances agility.

11. feature work
⊕
technical work

12. feature work
is
technical work

13. features are
made of
software

14. business value

15. business value
for whom?

16. business value
time frame?

17. prioritise by
business value

18. prioritise by
business value
estimate

20. Architecture represents the
significant design decisions that
shape a system, where significant
is measured by cost of change.
Grady Booch

21. What effect does ignoring quality
have on feature development?
a. It has no effect
b. It reduces the cost
c. It increases the cost

22. What effect does ignoring quality
have in the short-term?
a. It has no effect
b. It reduces the cost
c. It increases the cost

23. What effect does ignoring quality
have in the long-term?
a. It has no effect
b. It reduces the cost
c. It increases the cost

24. technical
debt

25. technical
neglect

27. As an evolving program is continually
changed, its complexity, reflecting
deteriorating structure, increases unless
work is done to maintain or reduce it.
Meir M Lehman
“Programs, Life Cycles, and Laws of Software Evolution”

28. maintenance

30. metaphor
The figure of speech in which a name or
descriptive term is transferred to some
object different from, but analogous to,
that to which it is properly applicable.

31. µεταϕορα
The figure of speech in which a name or
descriptive term is transfer

33. Metaphor is pervasive in
everyday life, not just in
language but in thought
and action.

34. The essence of metaphor
is understanding and
experiencing one kind of
thing in terms of another.

35. TIME IS MONEY
ARGUMENT IS WAR
ARGUMENTS ARE BUILDINGS
HAPPY IS UP; SAD IS DOWN
LOVE IS A JOURNEY

37. The aphysical and
invisible domain of
software is more about
metaphor than matter.

38. To be considered good, a metaphor
has to offer a number of points of
useful correspondence with what is
being described.
Kevlin Henney
“On Exactitude in Technical Debt”
oreilly.com/radar/on-exactitude-in-technical-debt

39. Another quality of a good metaphor
is that it should not have too many
obvious points of conflict.
Kevlin Henney
“On Exactitude in Technical Debt”
oreilly.com/radar/on-exactitude-in-technical-debt

40. The third quality of a metaphor that
makes it effective is familiarity to its
audience.
Kevlin Henney
“On Exactitude in Technical Debt”
oreilly.com/radar/on-exactitude-in-technical-debt

41. Technical Debt is a wonderful metaphor
developed by Ward Cunningham.
In this metaphor, doing things the quick
and dirty way sets us up with a technical
debt, which is similar to a financial debt.
Martin Fowler
martinfowler.com/bliki/TechnicalDebt.html (2003)

42. Martin Fowler
martinfowler.com/bliki/TechnicalDebt.html (2003)
Technical Debt is a wonderful metaphor
developed by Ward Cunningham.
In this metaphor, doing things the quick
and dirty way sets us up with a technical
debt, which is similar to a financial debt.

43. Shipping first time code is like going into
debt. A little debt speeds development
so long as it is paid back promptly with a
rewrite.
Ward Cunningham
c2.com/doc/oopsla92.html

44. Ward Cunningham
c2.com/doc/oopsla92.html
The danger occurs when the debt is not
repaid. Every minute spent on not-quite-
right code counts as interest on that debt.

45. Although we know that by definition no metaphor
is perfect, there are two common ways in which
the metaphor is misapplied: assuming technical
debt is necessarily something bad; equating
technical debt with a financial debt value.
Kevlin Henney
“On Exactitude in Technical Debt”
oreilly.com/radar/on-exactitude-in-technical-debt

46. technical
debt

47. unmanaged
technical
debt

48. Technical debt is not the cost of repaying
the debt: it is the cost of owning the debt.
These are not the same.
Kevlin Henney
“On Exactitude in Technical Debt”
oreilly.com/radar/on-exactitude-in-technical-debt

49. That is the message of the technical debt metaphor:
it is not simply a measure of the specific work needed
to repay the debt; it is the additional time and effort
added to all past, present, and future work that comes
from having the debt in the first place.
Kevlin Henney
“On Exactitude in Technical Debt”
oreilly.com/radar/on-exactitude-in-technical-debt

50. twitter.com/yvonnezlam/status/1376628481878990852

51. maintenance

52. action

53. inaction

54. neglect
Want of attention to what ought
to be done; the fact of leaving
something undone or unattended
to; negligence.

55. John Seddon
Freedom from Command & Control — A better way to make work work
Value demand represents the demands customers
make for the things they want, things that are of
value to them. Failure demand is created by the
organisation not working properly.
Failure demand is demand caused by a failure to
do something or do something right.

56. The best architectures,
requirements, and
designs emerge from
self-organizing teams.