-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathconfig_control.html
More file actions
144 lines (122 loc) · 4.64 KB
/
Copy pathconfig_control.html
File metadata and controls
144 lines (122 loc) · 4.64 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
<!DOCTYPE html>
<html>
<!--------------------------------------------------------------
-- file : config_control.html
-- purpose : Page for website Piet Lammertse
----------------------------------------------------------------
-- history :
-- 2025-12-01 new
--------------------------------------------------------------->
<head>
<meta charset = "UTF-8"
name = "viewport"
content = "width=device-width, initial-scale=1.0">
<link rel="stylesheet" href="plammertse.css">
<title> Piet Lammertse's memo system </title>
</head>
<body>
<!-- NAVIGATION BAR -------------------------------------------->
<ul>
<li> <a href="index.html"> Home </a> </li>
Configuration control </a> </li>
<li> <a style="background-color:#0000B0;"
href="config_control.html">
Config control </a> </li>
<li> <a href="toyota.html"> Toyota </a> </li>
</ul>
<!-------------------------------------------------------------->
<h2> Configuration control </h2>
<h4> early and frequent prototypes </h4>
<p> I am a firm believer in incremental development,
with short cycles of prototyping, frequent
user demos, and many more or less informal partial tests.
</p>
<p>  
<i> Refer to Sydney Camm : Hurricane, Swift, Hunter, Harrier. And Simodont.</i>
</p>
<p> 
It may come as a surprise to you that I am also a firm believer
in writing up a small requirements document
before each test, stating at the very least its purpose,
and thoroughly documenting the outcome,
especially if it was negative. The maxim is :
"an undocumented test equals a test never done".
And in fact, if a test was not worth writing up,
it should never have been done in the first place.
</p>
<h4> designing to requirements - the "V" model </h4>
<p> At least maintain this fiction after the fact.
Like science in a textbook.
</p>
<p> Keep this logical structure alive if you can,
even if chronologically and historically,
it did not go that way.
</p>
<p> 
<i> But do add footnotes on how it really went. </i>
</p>
<h4> configuration control </h4>
<p> Methodically document everything in sight,
including the history of tests and ideas (and the perpetrators).
</p>
<p>
- normalized databases.
</p>
<p>
- traceability.
</p>
<p>
- note that my memo system is an attempt at normalized knowledge management.
</p>
<h4> should you document which alternatives were rejected </h4>
<p> Yes, I think, within reason. This was anathema in the space industry, and I can see their point
(admitting to the people who pay your company that you were wrong, incompetent, and a waste of money; and confusing everyone by putting "wrong" ideas in their heads, or at the least allow them to read stuff that they should not spend time on).
But I beg to disagree. Corrected mistakes are more instructive than lucky hits,
and help people avoid making the same mistake.
</p>
<h4> my first experience - flight test </h4>
<p> My first job was at an aircraft factory,
where it was my job to collect, handle
and disseminate flight test data.
We are talking 10,000 parameters of in-flight
measurement, organized per flight, and then
per test run (typically 10 to 60 seconds),
and then per parameter (each typically with
its own calibration data), all to be made available
in a few hours after the test flight had landed.
I thought I had seen it all in terms of
permanently traceable data storage and retrieval.
</p>
<h4> my next level experience - space</h4>
<p> Upon joining the $ 1 billion one-shot
ISO satellite project, I soon learned
that the space industry
takes "con­figuration control" to the next level.
Although appalled at first by the bureuacracy
involved in maintaining a sacred design document tree
including a complete history of even the tiniest changes,
I soon found that this was the only way to
manage the decision tree in such a complex
"first time right" project.
</p>
<h4> marked for life </h4>
<p> The configuration control experience
at Space left an indelible mark on me,
and it is probably the reason why I organized
all my thinking into an elaborate personal memo system,
from which this website is a tiny spin-off.
</p>
<p> 
I'm sure I have gone overboard on the time
I spent on maintaining my own documentation
over the years, but I do believe that without it,
I would have spent as much time trying to retrieve
lost information or repeating old mistakes.
I guess it's largely a matter of temperament.
I just like to make slow, but steady progress.
</p>
<!-- FOOTER --------------------------------------------------->
<br> <br>
<div class="footer"> P. Lammertse, 2026 </div>
</body>
</html>