WEBVTT

1
00:00:00.040 --> 00:00:03.799
<v Speaker 1>Depending on which industry report you actually read, the global

2
00:00:03.839 --> 00:00:07.559
<v Speaker 1>cost of failed software projects, howevers somewhere around the three

3
00:00:07.599 --> 00:00:09.560
<v Speaker 1>trillion dollar mark annually.

4
00:00:09.400 --> 00:00:11.359
<v Speaker 2>Which is just a staggering number.

5
00:00:11.560 --> 00:00:14.759
<v Speaker 1>Right, it's massive, And if you've ever been adjacent to

6
00:00:14.759 --> 00:00:18.960
<v Speaker 1>the tech sector, you know the anatomy of this disaster intimately,

7
00:00:19.079 --> 00:00:21.640
<v Speaker 1>Oh absolutely, I mean, the project kicks off with this

8
00:00:22.120 --> 00:00:26.440
<v Speaker 1>flawless vision, a rigid timeline, a highly specific budget, and

9
00:00:26.440 --> 00:00:29.559
<v Speaker 1>then fast forward nine months, exactly, fast forward nine months,

10
00:00:29.920 --> 00:00:33.320
<v Speaker 1>and the deadline is just a distant memory, the budget

11
00:00:33.320 --> 00:00:36.920
<v Speaker 1>has somehow tripled, and the engineering team is completely burning

12
00:00:36.920 --> 00:00:40.439
<v Speaker 1>out trying to ship like a deeply compromised product.

13
00:00:40.759 --> 00:00:44.799
<v Speaker 2>Yeah, and it's so pervasive that corporate culture has essentially

14
00:00:44.880 --> 00:00:47.920
<v Speaker 2>accepted it as a law of physics at this point, right, Like,

15
00:00:48.000 --> 00:00:51.600
<v Speaker 2>the assumption is simply that software development is inherently unpredictable,

16
00:00:51.719 --> 00:00:54.039
<v Speaker 2>so you know, budgets are just destined to blow up.

17
00:00:54.079 --> 00:00:57.280
<v Speaker 1>But what if that unpredictability is actually an illusion? What

18
00:00:57.359 --> 00:01:00.439
<v Speaker 1>if the root cause of these catastrophic failures happen before

19
00:01:00.479 --> 00:01:03.759
<v Speaker 1>a single repository is even open. That's the real question, right,

20
00:01:03.799 --> 00:01:05.719
<v Speaker 1>And what if it all comes down to a fundamental

21
00:01:05.760 --> 00:01:08.799
<v Speaker 1>flaw in how we measure the work, because that is

22
00:01:08.840 --> 00:01:10.400
<v Speaker 1>the mission of today's deep dive.

23
00:01:10.680 --> 00:01:11.439
<v Speaker 2>Yes it is.

24
00:01:11.760 --> 00:01:16.000
<v Speaker 1>We are analyzing a methodology that challenges the entire foundation

25
00:01:16.280 --> 00:01:19.799
<v Speaker 1>of software project planning, which is the Functional Software Sized

26
00:01:19.840 --> 00:01:21.719
<v Speaker 1>Measurement or FSSM.

27
00:01:21.959 --> 00:01:25.200
<v Speaker 2>Yeah, and specifically we are looking at FSSM version one

28
00:01:25.239 --> 00:01:28.799
<v Speaker 2>point zero. This is a really comprehensive system developed by

29
00:01:28.879 --> 00:01:31.480
<v Speaker 2>jos Vier Singh and it was published in partnership with

30
00:01:31.519 --> 00:01:35.599
<v Speaker 2>the IE Computer Society and Wiley, which are heavy hitters, definitely,

31
00:01:36.280 --> 00:01:38.280
<v Speaker 2>And the core premise of this work is that we

32
00:01:38.319 --> 00:01:41.319
<v Speaker 2>actually can accurately measure the true size and complexity of

33
00:01:41.359 --> 00:01:43.359
<v Speaker 2>a software project right at the starting line.

34
00:01:43.400 --> 00:01:44.879
<v Speaker 1>But there's a catch right right.

35
00:01:45.200 --> 00:01:48.480
<v Speaker 2>Provided we abandon the industry's current favored shortcuts.

36
00:01:48.560 --> 00:01:51.280
<v Speaker 1>Okay, let's unpack this because our source material today is

37
00:01:51.599 --> 00:01:55.480
<v Speaker 1>frankly an incredibly dense, highly technical textbook.

38
00:01:55.519 --> 00:01:58.799
<v Speaker 2>It really is. It's meant for software architects and project managers.

39
00:01:59.120 --> 00:02:03.959
<v Speaker 1>Yeah, it's act with acronyms, formulas, deep structural theory. So

40
00:02:04.000 --> 00:02:06.959
<v Speaker 1>our goal today is to extract the underlying mechanisms of

41
00:02:07.000 --> 00:02:10.560
<v Speaker 1>this framework. We are going to figure out how FSSM

42
00:02:10.680 --> 00:02:14.360
<v Speaker 1>actually operates under the hood without getting totally bogged down

43
00:02:14.400 --> 00:02:16.639
<v Speaker 1>in the jargon. Sounds good, and we're going to figure

44
00:02:16.639 --> 00:02:19.960
<v Speaker 1>out why the methods most companies currently use are basically

45
00:02:19.960 --> 00:02:21.680
<v Speaker 1>setting them up for failure.

46
00:02:21.919 --> 00:02:24.400
<v Speaker 2>Right, And to understand the solution, we really have to

47
00:02:24.439 --> 00:02:28.120
<v Speaker 2>isolate the mechanical failure in the current standard first. Okay,

48
00:02:28.280 --> 00:02:30.960
<v Speaker 2>makes sense, Like, if you want to know why projects

49
00:02:31.039 --> 00:02:33.879
<v Speaker 2>budget explodes, you have to look at the tools they

50
00:02:33.960 --> 00:02:35.960
<v Speaker 2>use to estimate its size in the first place.

51
00:02:36.080 --> 00:02:36.280
<v Speaker 1>Right.

52
00:02:36.360 --> 00:02:40.319
<v Speaker 2>The industry currently relies heavily on a few established methodologies

53
00:02:40.360 --> 00:02:44.479
<v Speaker 2>for functional size measurement, with if POG and COSMIC being

54
00:02:44.479 --> 00:02:45.520
<v Speaker 2>two of the most prominent ones.

55
00:02:45.599 --> 00:02:48.000
<v Speaker 1>Yeah, I see those acronyms pop up and planning documentation

56
00:02:48.080 --> 00:02:51.719
<v Speaker 1>all the time. But functionally, what are if PEG and

57
00:02:51.800 --> 00:02:54.520
<v Speaker 1>COSMIC actually doing when they size up a project?

58
00:02:54.919 --> 00:02:57.879
<v Speaker 2>Well, at their core, they measure size by focusing heavily

59
00:02:57.960 --> 00:03:01.879
<v Speaker 2>on data boundaries and data mode movements. So IFPG, which

60
00:03:01.919 --> 00:03:05.719
<v Speaker 2>stands for the International Function Point Users Group, evaluates logical

61
00:03:05.800 --> 00:03:09.159
<v Speaker 2>data files and the transactions that cross the application's boundary,

62
00:03:09.439 --> 00:03:13.719
<v Speaker 2>and COSMIC COSMIC is the Common Software Measurement International Consortium,

63
00:03:14.199 --> 00:03:19.520
<v Speaker 2>and it similarly focuses on the movement of data, so entries, exits, reads,

64
00:03:19.520 --> 00:03:20.680
<v Speaker 2>and writes, So they.

65
00:03:20.599 --> 00:03:23.840
<v Speaker 1>Are essentially standing at the door of the software and

66
00:03:23.879 --> 00:03:26.639
<v Speaker 1>counting how many pieces of data walk in and out,

67
00:03:27.000 --> 00:03:29.159
<v Speaker 1>and like, how many filing cabinets are in the room.

68
00:03:29.319 --> 00:03:32.639
<v Speaker 2>Yes, that is a highly accurate way to visualize it, right,

69
00:03:32.840 --> 00:03:36.080
<v Speaker 2>And that creates a massive structural blind spot. How so,

70
00:03:36.360 --> 00:03:40.639
<v Speaker 2>because by hyper focusing on data movement, they largely ignore

71
00:03:40.680 --> 00:03:43.919
<v Speaker 2>the algorithmic complexity happening inside the room. Oh I see, yeah,

72
00:03:43.960 --> 00:03:47.759
<v Speaker 2>They bypass the intricate details of user interfaces, the internal

73
00:03:47.800 --> 00:03:52.280
<v Speaker 2>execution flows, complex air handling logic. They just measure a

74
00:03:52.520 --> 00:03:55.360
<v Speaker 2>very limited subset of the software's actual functionality.

75
00:03:55.439 --> 00:03:57.800
<v Speaker 1>But wait, if they're only measuring a fraction of the

76
00:03:57.840 --> 00:04:01.599
<v Speaker 1>actual architectural work, how does a project manager use that

77
00:04:01.759 --> 00:04:05.360
<v Speaker 1>output to generate a budget for the entire system? Because

78
00:04:05.400 --> 00:04:07.919
<v Speaker 1>you can't just hand an incomplete measurement to the finance

79
00:04:07.960 --> 00:04:11.759
<v Speaker 1>department and say fund this exactly.

80
00:04:12.400 --> 00:04:15.439
<v Speaker 2>And this is where the methodology resorts to what Singh

81
00:04:15.520 --> 00:04:19.319
<v Speaker 2>identifies as a critical flaw. Okay, the application of arbitrary

82
00:04:19.439 --> 00:04:25.199
<v Speaker 2>multiplication factors. Because the measurement is incomplete, the planning framework

83
00:04:25.240 --> 00:04:28.839
<v Speaker 2>attempts to compensate by taking that small, verified number of

84
00:04:28.959 --> 00:04:33.079
<v Speaker 2>data movements and multiplying it by a generic factor to

85
00:04:33.120 --> 00:04:35.519
<v Speaker 2>basically guess the size of the unmeasured work.

86
00:04:35.759 --> 00:04:38.600
<v Speaker 1>Wow, okay, it sounds like trying to estimate the cost

87
00:04:38.600 --> 00:04:41.480
<v Speaker 1>of building an entire custom house by only counting the windows.

88
00:04:41.560 --> 00:04:44.480
<v Speaker 1>That's a perfect analogy, right, Like you look at the blueprint,

89
00:04:44.480 --> 00:04:47.160
<v Speaker 1>you count ten windows, and then you apply some random

90
00:04:47.199 --> 00:04:50.040
<v Speaker 1>generic house factor of five to guess the you need

91
00:04:50.160 --> 00:04:53.120
<v Speaker 1>fifty units of wood in twenty units wiring exactly.

92
00:04:53.160 --> 00:04:55.360
<v Speaker 2>And the structural danger of that approach is.

93
00:04:55.480 --> 00:04:58.439
<v Speaker 1>Immense, because what if the house is a glass conservatory, right,

94
00:04:58.920 --> 00:05:02.040
<v Speaker 1>or what if it's a subtrain and concrete bunker. The

95
00:05:02.160 --> 00:05:06.199
<v Speaker 1>ratio of windows to structural materials change is completely based

96
00:05:06.199 --> 00:05:09.319
<v Speaker 1>on the architecture. If you rely on a generic multiplier,

97
00:05:09.480 --> 00:05:14.279
<v Speaker 1>you completely miss the complex plumbing, the specialized electrical grids,

98
00:05:14.600 --> 00:05:18.560
<v Speaker 1>the foundation requirements. No wonder budgets explode.

99
00:05:18.160 --> 00:05:21.879
<v Speaker 2>And that is the exact mechanism behind those blown software budgets.

100
00:05:22.040 --> 00:05:23.199
<v Speaker 1>It's just wild to me.

101
00:05:23.399 --> 00:05:26.079
<v Speaker 2>Yeah, The planning is built on a foundation of historical

102
00:05:26.079 --> 00:05:30.240
<v Speaker 2>assumptions rather than the factual architecture of the current project.

103
00:05:29.920 --> 00:05:31.839
<v Speaker 1>Which means they aren't really planning at all. Right.

104
00:05:32.240 --> 00:05:36.600
<v Speaker 2>When companies use multiplier based estimations. They are not estimating,

105
00:05:36.920 --> 00:05:41.040
<v Speaker 2>they are guessing. Yeah, because every software architecture is distinct,

106
00:05:41.439 --> 00:05:46.680
<v Speaker 2>those generic multipliers inevitably fail to capture unique complexities, causing

107
00:05:46.680 --> 00:05:49.439
<v Speaker 2>the timeline to slip and the budget to just evaporate.

108
00:05:49.680 --> 00:05:51.959
<v Speaker 1>And for you listening, this is exactly why you should care.

109
00:05:52.399 --> 00:05:56.519
<v Speaker 1>If your company relies on these multiplier based estimations. Your

110
00:05:56.560 --> 00:06:01.040
<v Speaker 1>project planning is built on assumptions, not facts. So if

111
00:06:01.040 --> 00:06:04.600
<v Speaker 1>guessing with historical multipliers is the mechanism of failure, then

112
00:06:04.639 --> 00:06:07.439
<v Speaker 1>the FSSM methodology must provide a way to measure the

113
00:06:07.600 --> 00:06:11.120
<v Speaker 1>entire architecture without relying on those shortcuts. So how does

114
00:06:11.199 --> 00:06:14.920
<v Speaker 1>Jasvier Singh's framework actually measure the whole system? Well.

115
00:06:15.000 --> 00:06:18.319
<v Speaker 2>FSSM, which by the way, operates in full compliance with

116
00:06:18.439 --> 00:06:21.959
<v Speaker 2>the ISOIEES four two one three dot one Standards for.

117
00:06:22.000 --> 00:06:23.920
<v Speaker 1>Software Measurement, right, which is important.

118
00:06:23.959 --> 00:06:28.439
<v Speaker 2>It functions by measuring the complete actual functionality based solely

119
00:06:28.480 --> 00:06:32.720
<v Speaker 2>on the project's foundational blueprint. Okay, it abandons historical statistical

120
00:06:32.800 --> 00:06:33.639
<v Speaker 2>data entirely.

121
00:06:33.920 --> 00:06:37.120
<v Speaker 1>Wait, let's pause on that Isostandard for a second, because

122
00:06:37.199 --> 00:06:41.199
<v Speaker 1>usually when a textbook highlights an isostandard, it implies this

123
00:06:41.480 --> 00:06:45.600
<v Speaker 1>massive checklist of compliance bureaucracy. Sure, what is the mechanical

124
00:06:45.600 --> 00:06:48.120
<v Speaker 1>significance of fourteen one forty three to one in this

125
00:06:48.199 --> 00:06:49.240
<v Speaker 1>specific context?

126
00:06:49.519 --> 00:06:54.040
<v Speaker 2>That specific standard defines the fundamental concepts of functional size measurement.

127
00:06:54.560 --> 00:06:57.759
<v Speaker 2>By adhering strictly to it, FSSM ensures that the size

128
00:06:57.800 --> 00:07:00.800
<v Speaker 2>of the software is derived purely from its functional requirements.

129
00:07:01.319 --> 00:07:05.199
<v Speaker 2>It prevents the methodology from drifting into arbitrary technical adjustments

130
00:07:05.279 --> 00:07:08.639
<v Speaker 2>or environmental modifiers, so it keeps it honest, exactly. It

131
00:07:08.720 --> 00:07:11.639
<v Speaker 2>forces the measurement to remain entirely.

132
00:07:11.279 --> 00:07:14.240
<v Speaker 1>Objective, So it forces the measurement to stay grounded in

133
00:07:14.279 --> 00:07:15.360
<v Speaker 1>the actual blueprint.

134
00:07:15.639 --> 00:07:20.279
<v Speaker 2>Yes, the entire process begins with the Functional Requirement Specifications

135
00:07:20.480 --> 00:07:21.399
<v Speaker 2>or the FRS.

136
00:07:21.519 --> 00:07:22.360
<v Speaker 1>Okay FRS.

137
00:07:22.600 --> 00:07:27.000
<v Speaker 2>FSSM parses this master document and categorizes the requirements into

138
00:07:27.079 --> 00:07:30.759
<v Speaker 2>what it calls software's measurable components or smcs.

139
00:07:31.079 --> 00:07:34.240
<v Speaker 1>Give me a breakdown of how it categorizes those components.

140
00:07:34.360 --> 00:07:35.600
<v Speaker 1>What are we actually looking at?

141
00:07:35.639 --> 00:07:39.480
<v Speaker 2>Well, FSSM segments the architecture into four primary pillars. You

142
00:07:39.480 --> 00:07:44.519
<v Speaker 2>have functional data, functionality, execution, user interfaces, and message exchanges.

143
00:07:44.600 --> 00:07:45.879
<v Speaker 1>Okay, those make sense.

144
00:07:45.720 --> 00:07:49.879
<v Speaker 2>But identifying the pillars isn't enough. The methodology then drills

145
00:07:49.920 --> 00:07:53.360
<v Speaker 2>down into the granular elements within each pillar, isolating the

146
00:07:53.399 --> 00:07:56.959
<v Speaker 2>software component's measurable features or scmfs.

147
00:07:57.000 --> 00:07:59.199
<v Speaker 1>Okay, I have to push back on the practicality of this,

148
00:07:59.360 --> 00:08:03.959
<v Speaker 1>For it every single measurable feature in a massive enterprise application.

149
00:08:04.759 --> 00:08:06.759
<v Speaker 1>That sounds like an administrative nightmare.

150
00:08:06.800 --> 00:08:08.279
<v Speaker 2>It does sound intimidating, Yeah.

151
00:08:08.120 --> 00:08:11.160
<v Speaker 1>Right, Like if a system has thousands of features, documenting

152
00:08:11.160 --> 00:08:15.160
<v Speaker 1>and measuring each one individually before development even begins, doesn't

153
00:08:15.199 --> 00:08:18.360
<v Speaker 1>that take forever? Isn't that the exact reason the industry

154
00:08:18.399 --> 00:08:20.879
<v Speaker 1>adopted those multiplier shortcuts in the first place.

155
00:08:21.160 --> 00:08:24.480
<v Speaker 2>Well, the perceived bottleneck is exactly why the industry relies

156
00:08:24.560 --> 00:08:29.240
<v Speaker 2>on shortcuts. But FSSM addresses this by simplifying the actual

157
00:08:29.279 --> 00:08:30.040
<v Speaker 2>measurement math.

158
00:08:30.120 --> 00:08:31.279
<v Speaker 1>Oh really Yeah.

159
00:08:31.319 --> 00:08:35.879
<v Speaker 2>While extracting the features requires analytical rigor, calculating their size

160
00:08:35.879 --> 00:08:40.600
<v Speaker 2>does not require advanced calculus or complex algorithmic modeling. It

161
00:08:40.639 --> 00:08:47.200
<v Speaker 2>relies on standard arithmetic addition, multiplication division, No advanced mathematics required.

162
00:08:47.320 --> 00:08:50.759
<v Speaker 1>Okay, but how does basic math capture structural complexity?

163
00:08:51.279 --> 00:08:54.480
<v Speaker 2>Because FSSM assigns a specific value known as a software

164
00:08:54.519 --> 00:08:58.679
<v Speaker 2>component's feature point or SCFP to each granular feature.

165
00:08:58.360 --> 00:08:59.000
<v Speaker 1>The future point.

166
00:08:59.000 --> 00:09:02.240
<v Speaker 2>Okay, the calculation and evaluates the base data elements involved

167
00:09:02.240 --> 00:09:05.159
<v Speaker 2>in a feature and cross references them against the complexity

168
00:09:05.200 --> 00:09:08.000
<v Speaker 2>of the execution logic required to process them. I see,

169
00:09:08.039 --> 00:09:10.480
<v Speaker 2>you calculate the points for the relational data, the points

170
00:09:10.480 --> 00:09:13.279
<v Speaker 2>for the computational logic, the points for the user interfaces,

171
00:09:13.559 --> 00:09:14.960
<v Speaker 2>and you literally just sum them up.

172
00:09:15.039 --> 00:09:18.639
<v Speaker 1>So you are basically building a highly accurate cumulative point

173
00:09:18.679 --> 00:09:20.039
<v Speaker 1>score feature by feature.

174
00:09:20.320 --> 00:09:24.279
<v Speaker 2>Exactly. What's fascinating here is that while that upfront analysis

175
00:09:24.320 --> 00:09:28.039
<v Speaker 2>does require a time investment, the return on that investment

176
00:09:28.200 --> 00:09:32.039
<v Speaker 2>is the complete elimination of assumption errors. Right. Taking the

177
00:09:32.080 --> 00:09:35.360
<v Speaker 2>time to properly index the structural components on the front

178
00:09:35.440 --> 00:09:39.639
<v Speaker 2>end prevents the architectural surprises that cause nine month delays

179
00:09:39.679 --> 00:09:40.360
<v Speaker 2>on the back end.

180
00:09:40.440 --> 00:09:43.080
<v Speaker 1>Right, because it turns out that software components refuse to

181
00:09:43.159 --> 00:09:48.240
<v Speaker 1>scale in predictable fixed mathematical proportions. No, they definitely don't.

182
00:09:48.600 --> 00:09:51.080
<v Speaker 1>Here's where it gets really interesting, because the textbook provides

183
00:09:51.120 --> 00:09:54.440
<v Speaker 1>some fascinating paradoxes to prove why we can't just rely

184
00:09:54.600 --> 00:09:56.240
<v Speaker 1>on proportional scaling.

185
00:09:56.440 --> 00:09:59.879
<v Speaker 2>Yeah, these examples perfectly illustrate the danger of abstracting away

186
00:10:00.039 --> 00:10:00.799
<v Speaker 2>all those details.

187
00:10:00.840 --> 00:10:03.000
<v Speaker 1>So let's look at the database paradox. If we use

188
00:10:03.039 --> 00:10:06.080
<v Speaker 1>the older methods that just count operations, we run into

189
00:10:06.120 --> 00:10:12.159
<v Speaker 1>a massive logical flaw. Imagine Application A requires fifty distinct

190
00:10:12.240 --> 00:10:15.879
<v Speaker 1>data tables, but each table only requires a single memory

191
00:10:15.879 --> 00:10:19.440
<v Speaker 1>read or write operation that gives us fifty total operations.

192
00:10:19.519 --> 00:10:20.639
<v Speaker 2>Fifty operations. Got it?

193
00:10:20.840 --> 00:10:24.919
<v Speaker 1>Now consider application B. It only requires two data tables,

194
00:10:25.360 --> 00:10:29.919
<v Speaker 1>but the architecture demands twenty five read or write operations

195
00:10:29.919 --> 00:10:32.759
<v Speaker 1>for each That also totals fifty operations.

196
00:10:32.960 --> 00:10:36.039
<v Speaker 2>Right, and under a methodology that merely counts data movements,

197
00:10:36.279 --> 00:10:40.399
<v Speaker 2>both applications receive the exact same functional size score.

198
00:10:40.440 --> 00:10:44.960
<v Speaker 1>Which is just absurd from an engineering standpoint. Complete designing, normalizing,

199
00:10:45.000 --> 00:10:49.120
<v Speaker 1>and mapping the relational integrity of fifty separate database tables

200
00:10:49.120 --> 00:10:53.320
<v Speaker 1>requires a completely different tier of architectural planning, state management,

201
00:10:53.639 --> 00:10:56.639
<v Speaker 1>and database expertise than setting up just two tables, even

202
00:10:56.639 --> 00:10:59.120
<v Speaker 1>if those two are hit frequently. Right, the operation count

203
00:10:59.200 --> 00:11:02.879
<v Speaker 1>is identical, but the actual structural effort is vastly different.

204
00:11:02.919 --> 00:11:07.120
<v Speaker 2>And FSSM captures this discrepancy because it measures the data classes,

205
00:11:07.159 --> 00:11:10.159
<v Speaker 2>the attributes, and the relational architecture. It doesn't just look

206
00:11:10.159 --> 00:11:12.080
<v Speaker 2>at surface level read write transactions.

207
00:11:12.159 --> 00:11:14.679
<v Speaker 1>Yeah, and the text highlights a similar issue with what

208
00:11:14.720 --> 00:11:18.159
<v Speaker 1>they call the interface paradox. If an application has two

209
00:11:18.240 --> 00:11:21.200
<v Speaker 1>user screens that are accessed fifty times in a specific

210
00:11:21.200 --> 00:11:25.440
<v Speaker 1>workflow that generates one hundred input output operation, right, compare

211
00:11:25.519 --> 00:11:28.000
<v Speaker 1>that to a system with one hundred unique user screens

212
00:11:28.039 --> 00:11:32.200
<v Speaker 1>that are only accessed once. Again, one hundred operations either way.

213
00:11:32.480 --> 00:11:35.720
<v Speaker 2>But the front end development overhead is entirely mismatched.

214
00:11:35.759 --> 00:11:36.159
<v Speaker 1>Totally.

215
00:11:36.200 --> 00:11:40.360
<v Speaker 2>Building one hundred distinct user interfaces involves massive UI and

216
00:11:40.480 --> 00:11:44.360
<v Speaker 2>UX design, distinct state management for every single screen, and

217
00:11:44.519 --> 00:11:49.000
<v Speaker 2>extensive component testing. Right, But two screens accessed frequently, that's

218
00:11:49.039 --> 00:11:53.279
<v Speaker 2>just an exercise, and efficient routing multiplying operations completely obscures

219
00:11:53.279 --> 00:11:54.600
<v Speaker 2>the actual labor required.

220
00:11:54.720 --> 00:11:56.840
<v Speaker 1>And to scale this up to the macro level, the

221
00:11:56.919 --> 00:12:00.720
<v Speaker 1>text compares the engineering of a telecon call handle application

222
00:12:01.120 --> 00:12:02.960
<v Speaker 1>to a radar processing application.

223
00:12:03.200 --> 00:12:05.799
<v Speaker 2>Right, And it's a vital comparison because it highlights how

224
00:12:05.960 --> 00:12:10.360
<v Speaker 2>entirely different software domains allocate complexity. A telecom application is

225
00:12:10.440 --> 00:12:14.720
<v Speaker 2>dominated by message communication and impute output routing. Okay, it

226
00:12:14.799 --> 00:12:20.039
<v Speaker 2>constantly orchestrates signals between external modules, but it rarely requires

227
00:12:20.080 --> 00:12:23.080
<v Speaker 2>heavy computational logic or deep memory manipulation.

228
00:12:23.600 --> 00:12:27.600
<v Speaker 1>Whereas a radar application operates on completely different physical principles.

229
00:12:27.879 --> 00:12:30.799
<v Speaker 1>It takes in raw signal data and runs intense filtering

230
00:12:30.799 --> 00:12:36.360
<v Speaker 1>and extraction algorithms exactly. It is computationally heavy, but requires

231
00:12:36.480 --> 00:12:39.480
<v Speaker 1>very little in terms of user interface or external messaging.

232
00:12:39.559 --> 00:12:43.960
<v Speaker 2>And this is exactly why taking a generic complexity multiplier

233
00:12:44.039 --> 00:12:47.200
<v Speaker 2>derived from the historical budget of a telecom project and

234
00:12:47.240 --> 00:12:50.919
<v Speaker 2>applying it to a radar project results in a catastrophic failure.

235
00:12:51.600 --> 00:12:55.879
<v Speaker 2>The foundational proportions of what makes each system complex are

236
00:12:55.960 --> 00:12:57.799
<v Speaker 2>diametrically opposed. Right.

237
00:12:57.840 --> 00:13:00.559
<v Speaker 1>It's like trying to measure the engineering requirements of a

238
00:13:00.600 --> 00:13:04.000
<v Speaker 1>heavy duty agricultural tractor by using the standards of a

239
00:13:04.039 --> 00:13:04.799
<v Speaker 1>commuter sedan.

240
00:13:04.919 --> 00:13:06.440
<v Speaker 2>Oh, that's a great way to put it.

241
00:13:06.639 --> 00:13:10.600
<v Speaker 1>They're both technically vehicles with wheels and an engine, but

242
00:13:10.840 --> 00:13:14.320
<v Speaker 1>the core physics, the torque requirements, the structural stresses, they

243
00:13:14.320 --> 00:13:17.639
<v Speaker 1>are completely different. If you use sedan multipliers to build

244
00:13:17.679 --> 00:13:20.559
<v Speaker 1>a tractor, the machine will literally tear itself apart the

245
00:13:20.559 --> 00:13:21.240
<v Speaker 1>moment you put.

246
00:13:21.159 --> 00:13:24.799
<v Speaker 2>In the field exactly. And that analogy perfectly transitions us

247
00:13:24.840 --> 00:13:27.919
<v Speaker 2>to the ultimate payoff of the FSSM methodology.

248
00:13:28.000 --> 00:13:30.080
<v Speaker 1>Okay, let's get into the payoff once we.

249
00:13:30.080 --> 00:13:34.039
<v Speaker 2>Have accurately measured the entire system feature by feature and

250
00:13:34.159 --> 00:13:38.600
<v Speaker 2>generated an accurate cumulative score of software components feature points.

251
00:13:39.120 --> 00:13:41.919
<v Speaker 2>We have to translate that data into a format that

252
00:13:42.000 --> 00:13:43.840
<v Speaker 2>a business can actually use for resourcing.

253
00:13:43.960 --> 00:13:46.759
<v Speaker 1>Right, Because an engineering manager can't just hand a developer

254
00:13:46.799 --> 00:13:49.840
<v Speaker 1>a feature point, they have to allocate hours, days, and

255
00:13:49.879 --> 00:13:53.519
<v Speaker 1>head account Right. So, how does FSSM bridge the gap

256
00:13:53.559 --> 00:13:57.519
<v Speaker 1>between abstract points and actual time without falling back into

257
00:13:57.519 --> 00:13:58.919
<v Speaker 1>the trap of those multipliers.

258
00:13:58.960 --> 00:14:02.639
<v Speaker 2>Well, it utilizes a translation mechanism called Software size and

259
00:14:02.720 --> 00:14:04.440
<v Speaker 2>Effort estimations.

260
00:14:04.000 --> 00:14:06.159
<v Speaker 1>Or ses oka sees.

261
00:14:06.440 --> 00:14:10.399
<v Speaker 2>Because FSSM has mapped the granular complexity of every component,

262
00:14:10.720 --> 00:14:14.320
<v Speaker 2>it can establish a direct mathematical correlation between a specific

263
00:14:14.360 --> 00:14:16.919
<v Speaker 2>feature point and standard engineering capacity.

264
00:14:17.039 --> 00:14:19.320
<v Speaker 1>How does that correlation actually work mechanically?

265
00:14:19.600 --> 00:14:22.320
<v Speaker 2>Instead of looking at how fast a previous team worked

266
00:14:22.360 --> 00:14:25.559
<v Speaker 2>and assuming the new team will match it, FSSM evaluates

267
00:14:25.559 --> 00:14:28.919
<v Speaker 2>the inherent complexity of the task itself. It takes the

268
00:14:28.919 --> 00:14:32.320
<v Speaker 2>feature points and maps them directly to actual person days.

269
00:14:33.039 --> 00:14:36.360
<v Speaker 2>Assuming a standard eight hour workday. It separates the effort

270
00:14:36.360 --> 00:14:40.399
<v Speaker 2>allocations into distinct life cycle phases. Oh wow, Yeah, it

271
00:14:40.440 --> 00:14:43.399
<v Speaker 2>calculates exactly how many standard person days are required for

272
00:14:43.440 --> 00:14:48.320
<v Speaker 2>analysis for design, for coding, and for testing, completely independent

273
00:14:48.440 --> 00:14:50.200
<v Speaker 2>of past statistical assumptions.

274
00:14:50.799 --> 00:14:54.440
<v Speaker 1>So it standardizes the effort required for the architecture rather

275
00:14:54.519 --> 00:14:57.840
<v Speaker 1>than guessing based on the unpredictable variables of the personnel.

276
00:14:58.120 --> 00:15:01.440
<v Speaker 1>That provides a factual baseline for SIS scheduling exactly. But

277
00:15:01.519 --> 00:15:05.200
<v Speaker 1>the methodology pushes even further than just development effort, doesn't

278
00:15:05.200 --> 00:15:09.840
<v Speaker 1>it It separates static characteristics from dynamic characteristics. So what

279
00:15:09.879 --> 00:15:12.279
<v Speaker 1>does this all mean for when the software is actually running?

280
00:15:12.639 --> 00:15:16.200
<v Speaker 2>This is arguably the most powerful diagnostic tool within the framework.

281
00:15:16.440 --> 00:15:22.159
<v Speaker 2>It introduces the concept of software performance quality Indicators spqis break.

282
00:15:21.919 --> 00:15:25.240
<v Speaker 1>Down the distinction between static and dynamic measurement in this context.

283
00:15:25.240 --> 00:15:28.559
<v Speaker 2>For me, sure, so, static measurement evaluates the code as

284
00:15:28.600 --> 00:15:31.799
<v Speaker 2>it rests in their repository. It measures the architectural effort

285
00:15:31.840 --> 00:15:33.720
<v Speaker 2>required to design and write the logic.

286
00:15:33.919 --> 00:15:35.799
<v Speaker 1>Okay, so design effort right.

287
00:15:35.960 --> 00:15:39.759
<v Speaker 2>The dynamic measurement evaluates how that architecture behaves when the

288
00:15:39.759 --> 00:15:43.879
<v Speaker 2>system is actually executed and real time processing begins.

289
00:15:44.159 --> 00:15:48.440
<v Speaker 1>The textbook uses this brilliant scenario to illustrate the danger

290
00:15:48.440 --> 00:15:49.519
<v Speaker 1>of confusing.

291
00:15:49.080 --> 00:15:50.919
<v Speaker 2>The two oh the loop scenario.

292
00:15:51.200 --> 00:15:55.000
<v Speaker 1>Yes, consider a developer writing a single disc memory read

293
00:15:55.039 --> 00:15:59.879
<v Speaker 1>operation from a static perspective, evaluating the design and coding effort,

294
00:16:00.120 --> 00:16:03.240
<v Speaker 1>That is a highly trivial task. It registers as a

295
00:16:03.279 --> 00:16:04.320
<v Speaker 1>minimal point of work.

296
00:16:04.480 --> 00:16:07.600
<v Speaker 2>But the architecture dictates that the single memory read operation

297
00:16:07.799 --> 00:16:11.039
<v Speaker 2>is placed inside an execution loop designed to trigger one

298
00:16:11.080 --> 00:16:14.600
<v Speaker 2>thousand times every time a user initiates a specific workflow.

299
00:16:14.799 --> 00:16:17.440
<v Speaker 1>Right and dynamically, that single line of code is no

300
00:16:17.519 --> 00:16:22.639
<v Speaker 1>longer trivial at runtime. It generates massive memory traffic and saturates.

301
00:16:22.200 --> 00:16:23.200
<v Speaker 2>The bus exactly.

302
00:16:23.440 --> 00:16:26.480
<v Speaker 1>If the measurement methodology only looks at the static code structure,

303
00:16:26.840 --> 00:16:30.120
<v Speaker 1>it categorizes the application as low effort and low impact.

304
00:16:30.600 --> 00:16:33.320
<v Speaker 1>It completely fails to account for execution.

305
00:16:33.000 --> 00:16:36.919
<v Speaker 2>Frequency, and that traditional method leaves the infrastructure team completely blind.

306
00:16:37.200 --> 00:16:40.440
<v Speaker 2>They provision standard servers for a quote unquote simple application,

307
00:16:40.919 --> 00:16:44.519
<v Speaker 2>and the system immediately bottlenecks at the database layer upon launch.

308
00:16:44.679 --> 00:16:45.320
<v Speaker 1>Disastrous.

309
00:16:45.440 --> 00:16:51.159
<v Speaker 2>But FSSM uses software operational indicators or sois to actively

310
00:16:51.240 --> 00:16:54.519
<v Speaker 2>flag these dynamic stress points during the measurement phase.

311
00:16:55.000 --> 00:16:57.600
<v Speaker 1>Let's look at another dynamic scenario from the text, involving

312
00:16:57.600 --> 00:17:01.080
<v Speaker 1>decision trees. Okay, imagine a standard branch in the logic.

313
00:17:01.720 --> 00:17:05.079
<v Speaker 1>If a condition is true, the application executes a series

314
00:17:05.119 --> 00:17:08.279
<v Speaker 1>of heavy memory rights to update a massive data structure.

315
00:17:08.799 --> 00:17:11.759
<v Speaker 1>If the condition is false, it simply routes the user

316
00:17:11.880 --> 00:17:14.440
<v Speaker 1>to a static display screen statically.

317
00:17:14.519 --> 00:17:17.759
<v Speaker 2>The architectural effort is split. The developer must design and

318
00:17:17.799 --> 00:17:21.440
<v Speaker 2>code both the complex memory rights and the simple routing logic,

319
00:17:21.799 --> 00:17:24.079
<v Speaker 2>so the static points reflect both paths right.

320
00:17:24.200 --> 00:17:26.920
<v Speaker 1>But the business logic dictates that, based on real world

321
00:17:27.039 --> 00:17:30.640
<v Speaker 1>user behavior, this decision branch will evaluate as true seventy

322
00:17:30.680 --> 00:17:31.400
<v Speaker 1>five percent.

323
00:17:31.160 --> 00:17:33.319
<v Speaker 2>Of the time, which means that seventy five percent of

324
00:17:33.359 --> 00:17:35.680
<v Speaker 2>the time this module is executed, it is hammering the

325
00:17:35.680 --> 00:17:39.519
<v Speaker 2>infrastructure with intense memory rights. A methodology that only measures

326
00:17:39.519 --> 00:17:42.680
<v Speaker 2>the static code sees a balanced fifty to fifty logic fork,

327
00:17:43.200 --> 00:17:46.880
<v Speaker 2>but fssm's software operational indicators evaluate the.

328
00:17:46.880 --> 00:17:48.960
<v Speaker 1>Dynamic load, so they see it coming. Yes.

329
00:17:49.519 --> 00:17:52.960
<v Speaker 2>They flag the fact that this specific decision node will

330
00:17:53.000 --> 00:17:57.160
<v Speaker 2>heavily bias toward intense memory utilization, allowing the architects to

331
00:17:57.200 --> 00:18:01.079
<v Speaker 2>provision memory caching or optimize the data base layer long

332
00:18:01.119 --> 00:18:02.440
<v Speaker 2>before the code is even written.

333
00:18:02.960 --> 00:18:05.359
<v Speaker 1>It's like putting the software architecture in a wind tunnel

334
00:18:05.400 --> 00:18:08.519
<v Speaker 1>before you start manufacturing the parts. You aren't just weighing

335
00:18:08.519 --> 00:18:12.160
<v Speaker 1>the static components. You are simulating the aerodynamic stress and

336
00:18:12.200 --> 00:18:14.400
<v Speaker 1>fluid dynamics to see where the chassis is going to

337
00:18:14.440 --> 00:18:15.359
<v Speaker 1>snap under pressure.

338
00:18:15.599 --> 00:18:18.079
<v Speaker 2>That's a really good way to visualize it. The methodology

339
00:18:18.119 --> 00:18:22.440
<v Speaker 2>moves beyond simple sizing and provides genuine diagnostic telemetry regarding

340
00:18:22.480 --> 00:18:26.839
<v Speaker 2>the health, stress points, and performance requirements of the proposed architecture.

341
00:18:26.960 --> 00:18:30.039
<v Speaker 1>This completely reframes how project planning should be handled. I mean,

342
00:18:30.440 --> 00:18:33.319
<v Speaker 1>if we synthesize everything we've extracted from the text today,

343
00:18:33.680 --> 00:18:37.319
<v Speaker 1>the primary takeaway for anyone managing, building, or fiancing a

344
00:18:37.359 --> 00:18:41.400
<v Speaker 1>project is that relying on partial measurements and historical multipliers

345
00:18:41.640 --> 00:18:43.279
<v Speaker 1>is a guaranteed recipe for disaster.

346
00:18:43.640 --> 00:18:48.720
<v Speaker 2>Absolutely true, project stability can only be achieved through comprehensive measurement.

347
00:18:49.240 --> 00:18:52.680
<v Speaker 2>The estimates must be derived directly from the functional requirements

348
00:18:52.680 --> 00:18:57.000
<v Speaker 2>specifications cataloging the actual architecture feature by feature.

349
00:18:57.599 --> 00:19:01.519
<v Speaker 1>By utilizing a framework like FSSM, you can translate those

350
00:19:01.599 --> 00:19:06.319
<v Speaker 1>architectural realities into accurate eight hour person days for development

351
00:19:06.759 --> 00:19:11.319
<v Speaker 1>while simultaneously predicting the dynamic run time performance of the system.

352
00:19:11.559 --> 00:19:14.599
<v Speaker 1>And the immediate value for you as a listener navigating

353
00:19:14.640 --> 00:19:17.720
<v Speaker 1>this space is that knowing this equips you to ask

354
00:19:17.759 --> 00:19:21.359
<v Speaker 1>the exact right questions in your next planning meeting. Exactly

355
00:19:21.599 --> 00:19:24.079
<v Speaker 1>when a timeline and a budget are presented, you can

356
00:19:24.119 --> 00:19:27.000
<v Speaker 1>look at the architecture and ask, are we measuring the

357
00:19:27.039 --> 00:19:29.920
<v Speaker 1>actual structural complexity of this system or are we just

358
00:19:30.000 --> 00:19:32.680
<v Speaker 1>counting the windows and applying a generic multiplier?

359
00:19:32.799 --> 00:19:36.000
<v Speaker 2>And if the answer involves historical multipliers, you know the

360
00:19:36.079 --> 00:19:38.839
<v Speaker 2>underlying foundation is completely compromised.

361
00:19:39.079 --> 00:19:41.519
<v Speaker 1>Yeah. Before we wrap up this deep dive, I want

362
00:19:41.559 --> 00:19:44.200
<v Speaker 1>to leave you with a final thought provoking question for

363
00:19:44.240 --> 00:19:46.640
<v Speaker 1>you to mull over that builds on the mechanisms we've

364
00:19:46.680 --> 00:19:47.279
<v Speaker 1>discussed today.

365
00:19:47.319 --> 00:19:48.119
<v Speaker 2>Okay, let's hear it.

366
00:19:48.319 --> 00:19:52.200
<v Speaker 1>We've spent this entire session exploring how granular feature by

367
00:19:52.240 --> 00:19:57.079
<v Speaker 1>feature measurement uncovers the hidden complexities and software architecture, proving

368
00:19:57.119 --> 00:20:01.160
<v Speaker 1>that relying on generic multipliers destroys projects. But what if

369
00:20:01.200 --> 00:20:05.920
<v Speaker 1>we applied that exact same logic to human organizational workflows?

370
00:20:06.039 --> 00:20:09.680
<v Speaker 2>Wait, applying functional size measurement to corporate structure?

371
00:20:09.839 --> 00:20:13.319
<v Speaker 1>Think about it. Consider the massive corporate restructurings that happen

372
00:20:13.400 --> 00:20:16.200
<v Speaker 1>constantly and the fact that they so frequently fail to

373
00:20:16.279 --> 00:20:20.599
<v Speaker 1>yield the promised efficiency. What if the reason corporate restructurings

374
00:20:20.640 --> 00:20:24.279
<v Speaker 1>fail is the exact same reason software projects fail.

375
00:20:24.440 --> 00:20:25.640
<v Speaker 2>Oh wow, right.

376
00:20:25.720 --> 00:20:30.759
<v Speaker 1>Executive management often views fifty highly unique specialized employee roles

377
00:20:31.160 --> 00:20:34.680
<v Speaker 1>simply as headcount. They apply a generic multiplier to determine

378
00:20:34.680 --> 00:20:37.039
<v Speaker 1>how many people a manager can oversee, or how many

379
00:20:37.079 --> 00:20:38.359
<v Speaker 1>tasks the department can handle.

380
00:20:38.440 --> 00:20:40.160
<v Speaker 2>They're just counting boundaries, exactly.

381
00:20:40.480 --> 00:20:43.200
<v Speaker 1>They measure the boundaries, the titles, and the salaries, but

382
00:20:43.279 --> 00:20:47.279
<v Speaker 1>they completely ignore the algorithmic complexity of the employee's daily

383
00:20:47.359 --> 00:20:48.640
<v Speaker 1>operational workflows.

384
00:20:48.799 --> 00:20:51.839
<v Speaker 2>So they are managing the static org chart but ignoring

385
00:20:51.880 --> 00:20:53.920
<v Speaker 2>the dynamic run time of the company itself.

386
00:20:54.279 --> 00:20:57.640
<v Speaker 1>Exactly are we trying to architect our corporate structures by

387
00:20:57.720 --> 00:21:02.240
<v Speaker 1>only counting the windows? Management refuses to measure the actual,

388
00:21:02.640 --> 00:21:06.640
<v Speaker 1>granular functionality of their employees' daily operations. Perhaps a blown

389
00:21:06.759 --> 00:21:10.920
<v Speaker 1>organizational budget is just as inevitable as a blown software budget.

390
00:21:11.079 --> 00:21:13.160
<v Speaker 2>That is a really fascinating way to look at it.

391
00:21:13.279 --> 00:21:16.200
<v Speaker 1>Definitely something to critically evaluate the next time a restructuring

392
00:21:16.200 --> 00:21:19.200
<v Speaker 1>memo hits your inbox. Thanks for joining us on this

393
00:21:19.279 --> 00:21:19.799
<v Speaker 1>deep dive.