WalkingSkeleton.md
... ...
@@ -0,0 +1,156 @@
1
+# Title: Walking Skeleton
2
+
3
+## Introduction
4
+
5
+A walking skeleton is a bare-bones initial version of an application, that
6
+demonstrates end-to-end communication, and is fully delivered. Starting with a
7
+walking skeleton helps to discover external forces that put constraints on the
8
+development. It frontloads work that is typically only done later in the
9
+development process, which flushes out issues where they occur most often: in
10
+the boundaries where the application touches the outside world. Once the walking
11
+skeleton is done it's possible to focus on the "meat and organs", i.e. the
12
+actual functionality, and iterate upon it rapidly.
13
+
14
+## History
15
+
16
+The original definition of Walking Skeleton is credited to Alistair Cockburn,
17
+who defined it in the book _Crystal Clear: A Human-Powered Methodology for Small
18
+Teams_ (2004). It gained wider acceptance through the _GOOS_ book, _Growing
19
+Object Oriented Software Guided by Tests_ (Steve Freeman, Nat Pryce, 2009).
20
+Their definition is as follows.
21
+
22
+> A “walking skeleton” is an implementation of the thinnest possible slice of
23
+> real functionality that we can automatically build, deploy, and test
24
+> end-to-end.
25
+
26
+## Structure & Boundaries
27
+
28
+Our skeleton is what holds us upright, and is largely what defines the space we
29
+take up in the world. The same holds true for our walking skeleton. It contains
30
+all the bits needed to stand up a working system. All the "boilerplate" setup,
31
+project and dependency management, repo and code organization, infrastructure,
32
+CI, deployment scripts. While it may not _do_ much (it does almost nothing), it
33
+should be fully deployed in a way that is automated and repeatable, and that is
34
+estimated to be good enough in terms of infrastructure and deployment process to
35
+last until the "v1", the first version that gets put in front of users.
36
+
37
+The second aspect of a skeleton, the fact that it defines the rough shape and
38
+size, is perhaps even more important. Our application has a certain surface
39
+area, it "touches" the world in various ways. It needs to be network accessible,
40
+to respond to HTTP requests, which requires a domain to be set up, and SSL
41
+certificates. It has a certain memory footprint. It talks to a database, to 3rd
42
+party services. It lives on (often virtualized) hardware. It writes logs and
43
+emits errors, which should be captured.
44
+
45
+These are the boundaries of the application, and they impose constraints. Drives
46
+have a fixed size. Networks have latency and bandwidth limitations. There are
47
+memory limitations, rate limits, certificates that expire. There are secrets and
48
+configuration that needs to be managed. Only by going through the paces of
49
+deploying an application "for real" can we really discover the impact these
50
+constraints have.
51
+
52
+## Ensemble
53
+
54
+Borrowing (again) from Christopher Alexander, we believe strongly in the
55
+"ensemble" view of design. A (software) designer should not be concerned merely
56
+with the designed object per se (the code), but with the ensemble of the object
57
+and the world around it. After all we don't deliver bits and bytes, we build
58
+tools, and what we ultimately deliver is the use of those tools. And so
59
+everything from the people that use it or are impacted by it (and their
60
+experience) to the software, and back, is part of the _thing_, including
61
+infrastructure, deployment pipelines, and even the people handling support
62
+requests.
63
+
64
+This means ultimately humans are the true boundaries of our systems, and
65
+everything from the human-computer interface on must be considered part of that
66
+system.
67
+
68
+This includes the people administering the system. And this is where Walking
69
+Skeleton truly shines as a way to discover constraints. Who has access where?
70
+Who is able to set up the credit card? Who is able to change the DNS? Who in the
71
+department we are integrating with can tell us why their API is giving a 500
72
+response?
73
+
74
+While figuring out the operational side of a deployment (infrastructure,
75
+provisioning) can be time consuming, unpredictable, and generally has a terrible
76
+feedback loop, it can be a walk in the park compared to figuring out this human
77
+infrastructure. Not to mention that often the second is a blocker for the first.
78
+
79
+And yet it's all too common for individuals and teams to build entire fleshed
80
+out applications, before they even begin the process of figuring these things
81
+out. One beautiful day they are ready to release, and start figuring out
82
+deployment. They hit snags at every level. It takes days just to figure out who
83
+to even ask to get the necessary permissions to access the infrastructure. They
84
+find out they are storing things on disk or in memory while the production VM
85
+doesn't have persistent disks, and runs multiple instances so they get state
86
+inconsitencies. The prod version of a vendor API requires different headers than
87
+the test version they were using, and the cloud vendor only hosts an older
88
+version of their database software, and doesn't bundle an extension they were
89
+relying on.
90
+
91
+## Walking Skeleton As Team Enabler
92
+
93
+Very early in the life of a new software project it can be difficult to have
94
+multiple people in a team work productively on the same code base. This gets
95
+easier once the basic structure is in place. Once there's a clear place to put
96
+things, basic conventions are established, and dev experience concerns are
97
+addressed (see also [[DevEnvironmentLauncher]]).
98
+
99
+This too is in scope for a walking skeleton, to have a good process to manage a
100
+local dev environment, that resembles as closely as is practical the production
101
+setup.
102
+
103
+Once all of that stuff is sorted, people can focus on the actual behavior, the
104
+features, the requirements. They can do so with a fast feedback loop (for
105
+instance through a REPL, or tests), iterate in small steps, and see the fruit of
106
+their work in a live running environment, the same one the end users will
107
+eventually use, which is extremely gratifying, but also ensures that from the
108
+get go every change is validated in a real world environment.
109
+
110
+## Walking Skeleton vs MVP vs Spike
111
+
112
+A Walking Skeleton is not an MVP (Minimal Viable Product). It is _a lot_
113
+smaller. It is not meant to be a viable product. For a simple database-backed
114
+web application, a Walking Skeleton needs to demonstrate that it can get a value
115
+from an HTML form to the database, and render it again as HTML.
116
+
117
+
118
+## Tensions
119
+
120
+## Pattern Description
121
+
122
+## Examples
123
+
124
+## Further Reading
125
+
126
+## History
127
+
128
+- end to end
129
+- all connections in place with the world outside of the application code itself
130
+- deployment, networking, storage, third party APIs, etc
131
+- discover the boundaries, surface area
132
+- boundaries define the negative space the app exists in
133
+- boundaries exert forces, opposing forces cause tensions
134
+- includes process, secret management, payment accounts, access keys
135
+- includes getting the right people the right credentials
136
+- may include observability (since that is a connection ie a boundary)
137
+- does not need to implement features or functionality beyond an artificial demonstration that the connections are working
138
+- focus is not on function but on non functioning requirements
139
+- goal is to establish a baseline for iterating
140
+- figure out not just the form itself (app), but the ensemble of form+context
141
+- find out the parts that aren't under your control, or which may take time because they need to be done through third parties
142
+
143
+As opposed to a spike
144
+- all about functionality/features
145
+- Discovery of internal rather than external forces
146
+- ignore "non functional" requirements
147
+
148
+
149
+
150
+https://www.defmyfunc.com/2019_10_18_walking_skeleton/
151
+
152
+- I also refer to a walking skeleton as v0, with v1 (PoC) adding first functionality but not polished, suitable for internal testing or beta users, and v2 being first "user grade" version
153
+ - v0 -> it doesn't do anything, but we're ready to add functionality, without having to go back and figure out unrelated things like deployment, storage, etc.
154
+ - v1 -> PoC, it ticks all the boxes in terms of functionality, but it may not be pretty
155
+ - v2 -> production ready
156
+- walking skeleton is related to "shift left", get more of what is typically late stage practices (deployment, QA, etc) earlier in the process