1
00:00:00,000 --> 00:00:09,000
Well, hello everybody. Here we are in Austin, Texas at the TeleLogic User Group 2008. I

2
00:00:09,000 --> 00:00:13,000
think it's Innovation 2008, if I recall correctly. And we've got another guest with us. Would

3
00:00:13,000 --> 00:00:16,000
you like to introduce yourself? My name is Harry Kaneman. I'm a technical consultant

4
00:00:16,000 --> 00:00:22,000
with Rocket Gang. We provide a training service and product resale on the TeleLogic brand,

5
00:00:22,000 --> 00:00:27,000
as well as the IBM Rational brand. We're on the system side. So we've been involved with

6
00:00:27,000 --> 00:00:37,000
systems development since the late 80s, early 90s. And from that perspective, we've been

7
00:00:37,000 --> 00:00:45,000
very tied to the Rational brand, who was acquired by IBM about 2001, I believe. So we've been

8
00:00:45,000 --> 00:00:49,000
worked in the system space for quite some time, and we've worked with the Rational tool.

9
00:00:49,000 --> 00:00:55,000
TeleLogic is in that same space as well. So with TeleLogic, what they bring to the table

10
00:00:55,000 --> 00:01:02,000
is a, I'd say, a newer tool set, if you will. The thing we're seeing with customers is this,

11
00:01:02,000 --> 00:01:09,000
that a lot of our traditional Rational customers are running into a few issues with their customers.

12
00:01:09,000 --> 00:01:16,000
Their customers are expecting UML2O, SysML, DODAF, and the tooling that Rational provided in the past

13
00:01:16,000 --> 00:01:23,000
didn't support those languages. So tools like System Architect, tools like Rhapsody provide the customer

14
00:01:23,000 --> 00:01:27,000
the ability to do that, as well as the ability to execute their models.

15
00:01:27,000 --> 00:01:34,000
Another thing that our customers, customers are demanding. So our customers, the system

16
00:01:34,000 --> 00:01:40,000
developers, their customers are demanding executable models. I mean, we're hearing actually from

17
00:01:40,000 --> 00:01:46,000
procurement people saying, quit giving us PowerPoint and Visio diagrams as system architectures of

18
00:01:46,000 --> 00:01:53,000
our systems, hand us instead executable models. So that better convinces the customer that we

19
00:01:53,000 --> 00:01:57,000
understand the scope of the system, the behavioral aspects of the system, before we spend lots and

20
00:01:57,000 --> 00:01:59,000
lots of money to go execute it.

21
00:01:59,000 --> 00:02:00,000
Right.

22
00:02:00,000 --> 00:02:05,000
I come from a, I don't know what you systems guys call it, but just like software, software.

23
00:02:05,000 --> 00:02:06,000
You know, more traditional.

24
00:02:06,000 --> 00:02:07,000
Sure.

25
00:02:07,000 --> 00:02:08,000
Software for computers sort of space, right?

26
00:02:08,000 --> 00:02:09,000
Correct, yeah, yeah.

27
00:02:09,000 --> 00:02:14,000
And, you know, I can sympathize with the idea of like, quit giving me Word documents.

28
00:02:14,000 --> 00:02:15,000
Right?

29
00:02:15,000 --> 00:02:16,000
For requirements.

30
00:02:16,000 --> 00:02:17,000
Exactly.

31
00:02:17,000 --> 00:02:20,000
Like, give me something that I can plug into the system that actually helps me, you know,

32
00:02:20,000 --> 00:02:25,000
get started at least with what you're wanting. Because the translation between, you know,

33
00:02:25,000 --> 00:02:29,000
PowerPoints or Word documents or whatever into actual, into whatever that next step is, is

34
00:02:29,000 --> 00:02:31,000
where a lot of the sort of loss occurs.

35
00:02:31,000 --> 00:02:35,000
What's been the evolution in the system space of that? I mean, is it just now happening that

36
00:02:35,000 --> 00:02:36,000
there's actually executable things?

37
00:02:36,000 --> 00:02:40,000
A lot of this, in my opinion, isn't really new. It's just catching on.

38
00:02:40,000 --> 00:02:41,000
Right.

39
00:02:41,000 --> 00:02:44,000
And I think the tooling's catching up. I think, for example, what we described earlier,

40
00:02:44,000 --> 00:02:49,000
the fact that ROSE and ROSE Real Time, for example, didn't support the ability for

41
00:02:49,000 --> 00:02:54,000
systems engineers to execute their models and write behavioral models, where tools like

42
00:02:54,000 --> 00:03:01,000
Rhapsody provide that. So, going back to your question about how has it evolved, I think

43
00:03:01,000 --> 00:03:06,000
that the systems that we build today, especially in the last decade, have gotten so complex from

44
00:03:06,000 --> 00:03:08,000
a behavioral understanding perspective.

45
00:03:08,000 --> 00:03:09,000
Yeah.

46
00:03:09,000 --> 00:03:13,000
I mean, it wasn't 15 years ago that a cell phone had 10 buttons and a send and an end.

47
00:03:13,000 --> 00:03:14,000
Right.

48
00:03:14,000 --> 00:03:15,000
And that was the interface to a cell phone.

49
00:03:15,000 --> 00:03:16,000
Yeah.

50
00:03:16,000 --> 00:03:19,000
It's not hard to understand the behavioral interface of that type of system.

51
00:03:19,000 --> 00:03:25,000
I mean, look at any cell phone you go get at Sprint or Verizon today. Think about specifying

52
00:03:25,000 --> 00:03:30,000
and understanding and contextualizing in system context that type of a system, and then expressing

53
00:03:30,000 --> 00:03:31,000
that to all the people that go build it.

54
00:03:31,000 --> 00:03:32,000
Right.

55
00:03:32,000 --> 00:03:37,000
You know, the methods we used a short time ago, they don't scale. So, we need new approaches

56
00:03:37,000 --> 00:03:41,000
and new techniques and languages to communicate, like SysML, like Dora.

57
00:03:41,000 --> 00:03:47,000
And that seems to be in the systems area. There's that explosion in features, which, you know,

58
00:03:47,000 --> 00:03:52,000
that's the bright side of it. And the sort of, the problem that creates is a lot more complexity

59
00:03:52,000 --> 00:03:55,000
and everything, and then a lot of interdependencies between things like that.

60
00:03:55,000 --> 00:04:00,000
I'm curious, in the systems space, like, it seems like, you know, what we software guys

61
00:04:00,000 --> 00:04:03,000
would call embedded, the embedded market, whatever pieces of hardware.

62
00:04:03,000 --> 00:04:04,000
Right.

63
00:04:04,000 --> 00:04:07,000
It seems like more and more of those are, no matter what hardware you have, it's sort

64
00:04:07,000 --> 00:04:09,000
of on the network, and it's networked together.

65
00:04:09,000 --> 00:04:10,000
Oh, yeah.

66
00:04:10,000 --> 00:04:15,000
And I mean, that seems like a whole other dimension of complexity that suddenly, the interaction

67
00:04:15,000 --> 00:04:18,000
for a device isn't just someone's fingers, it's like other devices out there.

68
00:04:18,000 --> 00:04:21,000
Correct. And a system is no longer just a single node.

69
00:04:21,000 --> 00:04:22,000
Right.

70
00:04:22,000 --> 00:04:26,000
A system is a collection of a lot of interoperable nodes.

71
00:04:26,000 --> 00:04:28,000
What we're looking at from that perspective now is system of systems.

72
00:04:28,000 --> 00:04:29,000
Yeah.

73
00:04:29,000 --> 00:04:33,000
To say that I have a large system that spans, you know, globally.

74
00:04:33,000 --> 00:04:39,000
I mean, a system might be global. Well, the mission for that system or the business case

75
00:04:39,000 --> 00:04:42,000
for that system spans a bunch of other systems as well.

76
00:04:42,000 --> 00:04:43,000
Right, right.

77
00:04:43,000 --> 00:04:47,000
So, you have to drill down and understand the business requirements or the mission requirements

78
00:04:47,000 --> 00:04:50,000
at the top and then push those down to the individual systems.

79
00:04:50,000 --> 00:04:51,000
Right.

80
00:04:51,000 --> 00:04:52,000
Which then you go build.

81
00:04:52,000 --> 00:04:56,000
And if that system is a very large system as well, then you've got to drill that one.

82
00:04:56,000 --> 00:04:57,000
It's interesting.

83
00:04:57,000 --> 00:05:01,000
It has some of the echoes of, we were talking with someone earlier in our little series here

84
00:05:01,000 --> 00:05:02,000
about enterprise architecture.

85
00:05:02,000 --> 00:05:03,000
Mm-hmm.

86
00:05:03,000 --> 00:05:07,000
And there's this same idea of, you know, you find yourself feeling like you're a puppet

87
00:05:07,000 --> 00:05:08,000
master or whatever.

88
00:05:08,000 --> 00:05:14,000
You're sort of looking down at all these interdependent things and getting that diagram, if you will,

89
00:05:14,000 --> 00:05:18,000
or that model that fits everything together seems like it's integral for very complex systems.

90
00:05:18,000 --> 00:05:19,000
Oh, absolutely.

91
00:05:19,000 --> 00:05:25,000
And along those lines, so enterprise architecture, you know, is what large organizations say,

92
00:05:25,000 --> 00:05:29,000
"Hey, we've invested a lot of money in a bunch of disparate systems and we have a bunch of processes

93
00:05:29,000 --> 00:05:30,000
that run across those.

94
00:05:30,000 --> 00:05:32,000
We know because we're a large business.

95
00:05:32,000 --> 00:05:33,000
Well, what are we doing?

96
00:05:33,000 --> 00:05:35,000
And how can we optimize them?

97
00:05:35,000 --> 00:05:39,000
And what other systems do we need in place to better optimize those and reduce some of our costs?"

98
00:05:39,000 --> 00:05:40,000
Right.

99
00:05:40,000 --> 00:05:45,000
Well, it's the same thing in kind of mission critical, you know, mission critical systems that are not IT.

100
00:05:45,000 --> 00:05:47,000
They're more defense, aerospace, et cetera.

101
00:05:47,000 --> 00:05:49,000
You know, building a Boeing plane.

102
00:05:49,000 --> 00:05:50,000
Sure.

103
00:05:50,000 --> 00:05:52,000
There's a lot of different systems that have to collaborate on the plane.

104
00:05:52,000 --> 00:05:55,000
And then, as you pointed out from a network perspective, the plane has to collaborate with the ground.

105
00:05:55,000 --> 00:05:59,000
Boeing 777 had a requirement that it had to radio the ground.

106
00:05:59,000 --> 00:06:05,000
When it detected an error internally as it monitored its health, it would forward a request to the ground crew that said,

107
00:06:05,000 --> 00:06:08,000
"I have a problem, and when I land, you need to replace this part on me."

108
00:06:08,000 --> 00:06:09,000
Right, right.

109
00:06:09,000 --> 00:06:10,000
Yeah.

110
00:06:10,000 --> 00:06:14,000
So, you know, you need that kind of -- so that there's a system that is, again, a system of systems.

111
00:06:14,000 --> 00:06:18,000
So, that way, the plane isn't taken offline while we go try to figure out what's wrong with it.

112
00:06:18,000 --> 00:06:19,000
Sure, sure.

113
00:06:19,000 --> 00:06:20,000
We can keep it flying and keep it operational.

114
00:06:20,000 --> 00:06:24,000
We talked about sort of moving towards more executable models of things.

115
00:06:24,000 --> 00:06:30,000
But, like, what are other -- both processes and tools in the system that you use to cope with these more complicated areas?

116
00:06:30,000 --> 00:06:35,000
I mean, you know, it would seem like, at the very minimum, there's a lot more documenting things.

117
00:06:35,000 --> 00:06:39,000
For as sort of, like, bad as a word that can be, but there's a lot of things to keep track of.

118
00:06:39,000 --> 00:06:45,000
And I wonder how you do that without the process becoming the end product, and you instead focus on the product.

119
00:06:45,000 --> 00:06:49,000
In the IT space, for example, agile practices have emerged.

120
00:06:49,000 --> 00:06:52,000
And agile practices advocate continuous development.

121
00:06:52,000 --> 00:06:58,000
And our measure of success is working software, not weighing how much documentation we produce.

122
00:06:58,000 --> 00:06:59,000
Right.

123
00:06:59,000 --> 00:07:01,000
Those types of measures and metrics.

124
00:07:01,000 --> 00:07:04,000
Large systems use, to some degree, a lot of those same metrics.

125
00:07:04,000 --> 00:07:06,000
The difference is they have to do more planning up front.

126
00:07:06,000 --> 00:07:07,000
Right.

127
00:07:07,000 --> 00:07:12,000
You know, they need to do more planning, and they need to better understand their system.

128
00:07:12,000 --> 00:07:21,000
I think that with large, complex systems, the biggest challenge we have is understanding what we're going to build, and then planning the build.

129
00:07:21,000 --> 00:07:26,000
And just like any software development, you know, we run into bottlenecks, we run into surprises along the developments.

130
00:07:26,000 --> 00:07:27,000
We have to keep re-planning.

131
00:07:27,000 --> 00:07:28,000
Right.

132
00:07:28,000 --> 00:07:29,000
You know, you want it to be an agile plan, per se.

133
00:07:29,000 --> 00:07:35,000
You don't want to, it's not like building a building where we have a plan, we just execute it, and everything works out as planned.

134
00:07:35,000 --> 00:07:49,000
So there is a blend of some agile practices, and the projects that are the most successful, and the most ones that are on time and on budget, are those that recognize that our plans that we produce up front.

135
00:07:49,000 --> 00:07:52,000
Granted, we're doing more work up front, more system engineering type efforts up front.

136
00:07:52,000 --> 00:07:53,000
Right.

137
00:07:53,000 --> 00:07:58,000
But the projects that are most successful are the ones that recognize that we will have to change, and we should plan for change.

138
00:07:58,000 --> 00:08:02,000
Like, how do you figure out how much up front planning you actually have to do without going overboard?

139
00:08:02,000 --> 00:08:07,000
The primary difference is, I'll use this analogy, you know, we're in Austin, Texas, they have great barbecue here.

140
00:08:07,000 --> 00:08:08,000
Sure.

141
00:08:08,000 --> 00:08:12,000
So there's probably some guy down the street here that's got one of the best barbecues in the city.

142
00:08:12,000 --> 00:08:16,000
But when he makes his barbecue, he probably just tastes it.

143
00:08:16,000 --> 00:08:21,000
You know, a little bit of this, a little bit of that, doesn't have any necessarily standard formula that he uses.

144
00:08:21,000 --> 00:08:22,000
Right.

145
00:08:22,000 --> 00:08:25,000
He probably has some ingredients, you know, probably some list.

146
00:08:25,000 --> 00:08:29,000
Well, contrast that to, what if you have to scale that?

147
00:08:29,000 --> 00:08:32,000
What if now you're an entire franchise of barbecues?

148
00:08:32,000 --> 00:08:33,000
Right.

149
00:08:33,000 --> 00:08:39,000
You know, we're not just that expert, not just that key programmer that's an expert in their field.

150
00:08:39,000 --> 00:08:41,000
We have to scale this to thousands of places.

151
00:08:41,000 --> 00:08:44,000
Well, that's the type of things we do with our large systems.

152
00:08:44,000 --> 00:08:53,000
You know, you have extremely individually talented developers that in isolation, you know, they're extremely good and they can be very productive, kind of like the guy with his barbecue.

153
00:08:53,000 --> 00:08:54,000
Right.

154
00:08:54,000 --> 00:09:02,000
The challenge is, how do you scale that to a 500 person team, a 1,000 person team, and have all the collaboration and integration that's going to happen with it?

155
00:09:02,000 --> 00:09:11,000
So, from that perspective, I think you can appreciate the fact, if we don't go in with a reasonable plan, we'll have a bunch of people just running around all over the place.

156
00:09:11,000 --> 00:09:12,000
Tasting everything, right?

157
00:09:12,000 --> 00:09:13,000
Right.

158
00:09:13,000 --> 00:09:15,000
And there'll be no food left for the customers.

159
00:09:15,000 --> 00:09:17,000
Absolutely.

160
00:09:17,000 --> 00:09:20,000
People just feed themselves with those giant documents, right?

161
00:09:20,000 --> 00:09:21,000
Exactly.

162
00:09:21,000 --> 00:09:24,000
So, you need some sense of plan.

163
00:09:24,000 --> 00:09:27,000
And another big thing is we live in a little different environment.

164
00:09:27,000 --> 00:09:30,000
With large systems, they are big dollar things.

165
00:09:30,000 --> 00:09:36,000
And correctly, a customer is going to want to see incremental milestones, accomplishments.

166
00:09:36,000 --> 00:09:51,000
You know, so they're going to want to, before we commit a lot of money, they're going to want to have some confidence in the plan and the confidence of the ability of the developer, the development company, to go off and build the system that they propose to build.

167
00:09:51,000 --> 00:10:01,000
So, if there isn't a good plan and a compelling case, then, you know, I don't think anybody would want to go forward with a multi-million dollar, multi-billion dollar system that we're going to do.

168
00:10:01,000 --> 00:10:08,000
While we do plan up front, the most productive organizations that I've seen, anyway, are the ones that recognize the plan is going to change.

169
00:10:08,000 --> 00:10:09,000
So, we are continually planning.

170
00:10:09,000 --> 00:10:10,000
Right.

171
00:10:10,000 --> 00:10:12,000
You know, it's not like, it's not a waterfall approach.

172
00:10:12,000 --> 00:10:17,000
It's a traditional waterfall approach where we do all our plan and then we just go execute it and everything will work out fine.

173
00:10:17,000 --> 00:10:17,000
Right.

174
00:10:17,000 --> 00:10:19,000
You know, we do some initial planning.

175
00:10:19,000 --> 00:10:22,000
Let's go build those pieces while we're doing some more planning to build those pieces.

176
00:10:22,000 --> 00:10:24,000
It's more planning to build those pieces.

177
00:10:24,000 --> 00:10:33,000
And the construction aspect or building those pieces, that's giving feedback to the system engineering folk to say, "Hey, this plan you came up with isn't working right."

178
00:10:33,000 --> 00:10:34,000
Right.

179
00:10:34,000 --> 00:10:37,000
Or, "The pieces we thought we were going to be able to integrate were not going to be able to integrate."

180
00:10:37,000 --> 00:10:39,000
Or, "That hardware doesn't work like we thought it was going to work."

181
00:10:39,000 --> 00:10:40,000
Right.

182
00:10:40,000 --> 00:10:42,000
So, we're constantly having to replan.

183
00:10:42,000 --> 00:10:53,000
And another thing I was curious about, and I've talked with some people in the systems area about it, is the idea that, and we're talking about this up front, that software plays more and more of a key role in systems.

184
00:10:54,000 --> 00:10:55,000
Right.

185
00:10:55,000 --> 00:11:02,000
And at the same time, it seems like software hasn't been in the systems area for as long as software has been in sort of like the generic computer area.

186
00:11:02,000 --> 00:11:03,000
Correct.

187
00:11:03,000 --> 00:11:10,000
And so, in that sense, it seems like people who are using, who are developers in the systems area are sort of like newer at it.

188
00:11:10,000 --> 00:11:18,000
And it means that they're sort of, to put it in a positive way, they can not learn the bad habits that we have on the other side of the house.

189
00:11:18,000 --> 00:11:19,000
Right, right.

190
00:11:19,000 --> 00:11:21,000
And I wonder, like you're saying you do a lot of training and things like that.

191
00:11:21,000 --> 00:11:30,000
And I wonder when you encounter people who are sort of new to the software world, like how you sort of try to get them to avoid the bad habits of like the old software world.

192
00:11:30,000 --> 00:11:36,000
On the systems side, so a lot of the system engineers, they aren't the software people and they're not going to develop the software.

193
00:11:36,000 --> 00:11:37,000
Right.

194
00:11:37,000 --> 00:11:41,000
Their job is to understand this complex system.

195
00:11:41,000 --> 00:11:47,000
But to bring up a good point, we in the software space for a long time have been dealing with complex systems.

196
00:11:47,000 --> 00:11:54,000
The complexity of our software systems prior to, as you pointed out, a lot of software being pushed into these large embedded systems.

197
00:11:54,000 --> 00:11:55,000
Right.

198
00:11:55,000 --> 00:12:02,000
We've been having to deal with complexity for quite a while and we have tools and techniques like use cases and user stories and those types of things.

199
00:12:02,000 --> 00:12:12,000
It's been interesting to observe the either embracing or the resistance of some system engineers and those types of folks to these other techniques.

200
00:12:12,000 --> 00:12:19,000
You talk to some system engineers and say, "Oh, use cases? How the system is going to react from a user perspective? That's a software thing."

201
00:12:19,000 --> 00:12:20,000
That's not what we do with system engineers.

202
00:12:20,000 --> 00:12:21,000
Right.

203
00:12:21,000 --> 00:12:25,000
Like, "Well, do you really want to leave the behavior of your system up to the software developers?"

204
00:12:25,000 --> 00:12:30,000
You know, and if you explain it to them that way, they think about it for a minute and say, "Well, not really."

205
00:12:30,000 --> 00:12:34,000
Okay, well then, what's the best way to express the behavior requirements to your development team then?

206
00:12:34,000 --> 00:12:35,000
Yeah, yeah.

207
00:12:35,000 --> 00:12:38,000
You know, this is something we in the software world have learned from the past.

208
00:12:38,000 --> 00:12:48,000
You know, describing user stories in the Agile world or use cases in the IT world, in the IT systems world, is the best approach to describing systems.

209
00:12:48,000 --> 00:12:54,000
Some people look at that and look at it as a good resource for them.

210
00:12:54,000 --> 00:12:57,000
Other people kind of shunt it and say, "Hey, that wasn't invented here."

211
00:12:57,000 --> 00:12:59,000
That came from the software world. That's something we should use.

212
00:12:59,000 --> 00:13:00,000
I'll share with you a little story.

213
00:13:00,000 --> 00:13:04,000
I was just delivering, a couple, three weeks ago, a class on SysML.

214
00:13:04,000 --> 00:13:12,000
And it was to a group of system engineers, and we were talking about use cases and talking about activity diagrams, all things in SysML.

215
00:13:12,000 --> 00:13:21,000
And one of the person in the back of the room said, "When you get to something I haven't already done before, why don't you wake me up and tell me?"

216
00:13:21,000 --> 00:13:24,000
So some people come with a lot of resistance, you know.

217
00:13:24,000 --> 00:13:26,000
"When you get to something useful, why don't you come and tell me?"

218
00:13:26,000 --> 00:13:28,000
Yeah, it's nice to meet you too.

219
00:13:28,000 --> 00:13:29,000
Yeah, exactly.

220
00:13:29,000 --> 00:13:34,000
So that's an extreme example, but I think it's a personality for people.

221
00:13:34,000 --> 00:13:41,000
Some people like to embrace change and like to find new techniques and see how can I apply them on my project and try to make it better.

222
00:13:41,000 --> 00:13:44,000
And other people, they like what they've been doing forever.

223
00:13:44,000 --> 00:13:46,000
It's an interesting point you raised about the use case thing.

224
00:13:46,000 --> 00:13:52,000
I mean, it makes me think of to use a sort of now like archaic word, sort of peripherals for computers, right?

225
00:13:52,000 --> 00:13:57,000
Where I think every single scanner that I've gotten, like flatbed scanner, like it's a great piece of hardware.

226
00:13:57,000 --> 00:14:00,000
And then you use the software and it's just like terrible.

227
00:14:00,000 --> 00:14:01,000
Right.

228
00:14:01,000 --> 00:14:10,000
And you can tell that the focus was on, you know, more of the systems engineers, the people making the hardware and they sort of just, you know, let those people over there do the software.

229
00:14:10,000 --> 00:14:11,000
Yeah.

230
00:14:11,000 --> 00:14:15,000
And it would be nice if there was that more unified caring of all parties throughout the process.

231
00:14:15,000 --> 00:14:19,000
That's a prime example of no one looking at the system from the user's perspective.

232
00:14:19,000 --> 00:14:20,000
Right, right.

233
00:14:20,000 --> 00:14:21,000
To say, "What is the way I would like to use this system?"

234
00:14:21,000 --> 00:14:25,000
"Hey, I gave you a button that's able to scan things, you want something more than that?"

235
00:14:25,000 --> 00:14:28,000
Well, yeah, I've got a lot of scenarios that might be useful to you.

236
00:14:28,000 --> 00:14:37,000
But as you point out, depending on the organization or the program or the project, you know, there's different levels of interest in trying to express that behavior.

237
00:14:37,000 --> 00:14:38,000
Right.

238
00:14:38,000 --> 00:14:41,000
And you see radically different usable systems because of what you point out.

239
00:14:41,000 --> 00:14:42,000
Well, great.

240
00:14:42,000 --> 00:14:44,000
Well, thanks for taking all this time to talk with us today.

241
00:14:44,000 --> 00:14:47,000
It's always, like I said, it's always fun to delve into system stuff.

242
00:14:47,000 --> 00:14:48,000
It's fun to learn more about it.

243
00:14:48,000 --> 00:14:49,000
Great.

244
00:14:49,000 --> 00:14:49,000
Well, thanks for having me.