Open-Closed Principle

Jason, Huiqi and I discuss the open-closed principle while relating it to the law of leaky abstractions. We use Uncle Bob Martin's paper as a reference. We introduce the concept as well as talk about where its applicable as well as its limitations. If you are following along, I strongly encourage you to read the paper yourself: https://drive.google.com/file/d/0BwhCYaYDn8EgN2M5MTkwM2EtNWFkZC00ZTI3LWFjZTUtNTFhZGZiYmUzODc1/view?resourcekey=0-FsS837CGML599A_o5D-nAw Part 2 of this conversation can be found here: https://youtu.be/VIdJ-XcQcKY.

Transcript

The following transcript was automatically generated by an algorithm.

00:00 : hi there uh in this video i'm going to
00:03 : chat with
00:04 : jason bonninger and huiji joe my friends
00:08 : and colleagues
00:09 : about the open close principle in
00:11 : particular
00:12 : we're going to be discussing a paper by
00:14 : robert martin called the open close
00:17 : principle and was published in the c
00:19 : plus plus report if you want to follow
00:21 : along
00:22 : and read this paper yourself i i
00:24 : recommend you
00:25 : go to the wikipedia article for the open
00:29 : close principle and then
00:31 : jump to the second reference in this
00:33 : list and click into here
00:37 : and there you can read this paper for
00:40 : yourself and decide
00:42 : for yourself uh what your opinions are
00:45 : uh without further ado enjoy our
00:47 : conversation
00:48 : huichi and i we had a couple of
00:51 : conversations about this topic and um
00:55 : and the last time we kind of left off
00:58 : with
00:59 : um hey what can we do about leaky
01:03 : abstractions
01:04 : if it is a problem and then we
01:09 : we went in the direction of
01:13 : hey there's this thing called the open
01:15 : close principle
01:16 : and i think that would be a good thing
01:18 : to talk about because it is
01:19 : an approach that is trying to address
01:22 : some of the issues of leaky
01:23 : abstractions but before we start i kind
01:25 : of want to get
01:27 : get jason's thoughts about
01:30 : this concept of leaky abstractions what
01:33 : are your thoughts about it what do you
01:35 : think
01:35 : it means for us as developers i really
01:38 : like the article i think it's like a
01:40 : great problem statement
01:42 : um because it's very real like the http
01:45 : issue
01:47 : definitely strikes home where you
01:50 : you know we don't understand a lot of
01:52 : what's happening and it's
01:53 : pretty crazy but most of the time it
01:55 : just kind of magically works
01:56 : and that's really great to be able to
01:58 : trust that yeah i really liked it i
02:00 : think
02:01 : it is one of the fundamental challenges
02:03 : of writing software that you just don't
02:05 : really get away from like you don't
02:06 : learn out of it
02:08 : it's just something that we always have
02:09 : to deal with and decide
02:11 : how best to compromise on and that
02:14 : i think is like kind of what makes us a
02:17 : good or not good
02:18 : developer because you're always having
02:20 : to do it
02:21 : so let's let's dig into the
02:25 : this paper by uh
02:28 : bob martin um called the
02:31 : open closed principle so at software
02:33 : entities
02:35 : uh classes modules functions etc should
02:38 : be open for
02:39 : extension but closed for modification
02:42 : i first read this um i don't know if i
02:46 : ever got
02:46 : bob's book i i read about
02:50 : his solid principles and this is
02:53 : one of his five solid principles
02:56 : is the o of the solid the open close
03:00 : principles and there's four
03:01 : others but this one kind of stood
03:05 : in my mind the most i i like the way
03:09 : that
03:09 : this statement reads it's like open for
03:13 : extension but close for
03:15 : modification why do you think this is a
03:17 : good idea first of all
03:19 : for me it makes me think of like a
03:22 : probably an even higher level concept of
03:25 : you know when you
03:26 : create any kind of public api you
03:30 : really ultimately then can't change what
03:32 : you've released publicly
03:34 : because if you change the way that
03:35 : behavior works
03:37 : then or remove it then you just you
03:39 : break dependencies
03:41 : you kind of have to design that way and
03:42 : i think this is like really expanding
03:44 : that
03:44 : so it makes sense to me so like yeah
03:48 : you publish an api or you publish a
03:51 : library that other people are gonna
03:54 : download
03:54 : and if you republish it and break stuff
03:58 : it could be a problem from a point of
04:00 : view of your own
04:01 : code base what would it give you to
04:04 : adopt this
04:05 : within your own private code base are
04:08 : there any benefits
04:09 : to using this by yourself when i see a
04:12 : git diff
04:13 : where it's like all green that usually
04:15 : feels like pretty good
04:17 : in general because you've
04:21 : added some feature functionality to your
04:23 : code
04:24 : but you haven't changed any lines
04:27 : i mean in general um
04:31 : and i think again that's kind of what
04:32 : this is touting is if you can
04:35 : if you can make your code base you can
04:37 : build it in such a way where you only
04:39 : add to it but you don't actually change
04:41 : what's there in theory
04:42 : you would have a very reliable code base
04:45 : because
04:46 : you're only adding more and more
04:47 : functionality but the existing stuff
04:50 : you're not tweaking or changing so you
04:52 : don't risk introducing bugs
04:54 : so what you're pointing to is that when
04:56 : you change existing code you can break
04:58 : stuff
04:59 : yeah sweat so yeah
05:02 : that's a like if you see a lot of red
05:04 : well you're modifying
05:06 : a lot of code so that risks break stuff
05:10 : and
05:10 : would you just say it's fair that like
05:12 : the the mo the motivation for not
05:14 : modifying anything is you just don't
05:18 : want to
05:18 : introduce any breakage and i think to be
05:20 : even maybe
05:21 : a little bit more specific about it like
05:23 : breakage is obviously bad but also
05:26 : even just a change of behavior like
05:28 : maybe it's not throwing an error
05:29 : or maybe it's even acting relatively
05:31 : correctly but
05:33 : previously it was doing it this way and
05:35 : now it's doing it just a little bit
05:36 : different and if any of your
05:37 : dependencies
05:38 : you know have made that assumption then
05:40 : you can obviously mess with them
05:43 : unintentional or not yeah to me
05:46 : to me i i guess i kind of questioning
05:49 : like what does
05:50 : modification mean because the
05:53 : modification can mean modification of an
05:56 : interface which as from what jason said
05:59 : it's like oh once you publish the
06:00 : interface
06:01 : of course you can change it otherwise
06:03 : you would break the
06:05 : uh compatibility but what if if i don't
06:08 : change the
06:09 : interface but i just modif modify
06:11 : internally for whatever reason
06:13 : does that count as this it counts as
06:15 : modification
06:17 : uh by the by what this article is saying
06:20 : i'll just read this part that says when
06:22 : a single change
06:24 : to a program results in a cascade of
06:27 : changes to dependent modules
06:30 : that program exhibits the undesirable
06:33 : attributes that we have
06:35 : come to associate with bad design
06:39 : but if you change the internal of the
06:41 : layer you wouldn't
06:43 : cascade the change because your
06:45 : interface
06:46 : doesn't change that's a good point he
06:48 : doesn't explicitly say
06:50 : he's avoiding modification because he
06:53 : wants to
06:54 : avoid bugs actually and if you
06:57 : saw him say that please let me know but
07:00 : i don't think he actually says that
07:02 : but but i i still get the feeling that
07:06 : implicitly that's a big part of it
07:09 : so i'm i'm reading between the lines but
07:12 : what he points to more specifically is
07:15 : like
07:16 : well you change this one thing then you
07:17 : have to go change that other thing and
07:19 : then you have to go change that other
07:20 : thing
07:21 : and yeah your point about the interface
07:24 : is
07:24 : that's sort of what he's proposing he's
07:26 : saying we can come up with a design
07:28 : where you can extend it but you
07:31 : you don't have to change the internals
07:33 : basically
07:35 : um and then one way of doing that is by
07:37 : using
07:38 : interfaces as the protocols where the
07:42 : different components are going to talk
07:43 : to each other but there are different
07:45 : ways as well
07:46 : i want to say two things uh the first is
07:48 : this uh statement
07:50 : uh made me feel like uh
07:53 : software developer development that's
07:55 : different from like other things like
07:57 : say
07:57 : engineering and car is software changes
07:59 : so fast
08:01 : so i think this statement is there is
08:03 : because we change things so fast so we
08:05 : need to come up with a way to
08:08 : we can easily adjust to like a change
08:12 : request uh that's why we have that but i
08:15 : feel like
08:15 : the limitation is also always there is
08:18 : like how do you know how do you
08:20 : see what is the change request because
08:22 : of course you can
08:24 : try your best to predict what the change
08:26 : is and then you can leave that
08:27 : open but i feel like you can never
08:30 : predict
08:31 : everything so there will always be the
08:34 : case that you possibly you have to make
08:35 : the modification
08:37 : yeah yeah that's one dot and then the
08:40 : second dot is not related to the first
08:42 : stop the second dot is
08:43 : there is like a popular uh concern of
08:46 : using libraries versus
08:48 : using like a server which uh which is
08:51 : like say if you use certain code as a
08:54 : library
08:55 : you have to think more about how the
08:58 : code connect to each other
09:00 : because say if the library
09:06 : like the library got changed and your
09:08 : code might have to change because so
09:10 : if you use a piece of code as libraries
09:12 : that then
09:13 : the uh the connection point is much
09:16 : larger than say if you just use
09:18 : something as
09:19 : pure service because the service only
09:21 : have
09:22 : a abstract api say if you make an api
09:26 : call to
09:27 : do something then this interface is
09:30 : relatively small
09:31 : but sometimes the library because you're
09:34 : using the code itself
09:36 : so the interface is uh i shouldn't say
09:38 : that in
09:39 : because this interface it doesn't mean
09:41 : that like interface in terms of coding
09:45 : point is much more complicated so you
09:47 : have to think more about
09:49 : backward compatibility and things like
09:50 : that but if it's just calling service i
09:52 : don't care
09:53 : how the other end works yeah
09:56 : okay uh you're basically saying when you
10:00 : bring in a library
10:03 : you tend to depend on the library
10:06 : more yeah there also tells me like um
10:09 : the library tends to have a larger
10:11 : surface area in the like
10:14 : the amount that you're touching the
10:16 : library yeah i have
10:18 : examples yeah in my current work
10:21 : situation
10:21 : so we have an automation testing like
10:24 : team
10:25 : those people are using java
10:29 : and then each team will also use
10:32 : java to write your own automation
10:34 : testing for
10:35 : your app and then this automation
10:38 : testing team
10:39 : will use their java code to bring
10:42 : our say my team's java code as a sub
10:45 : module
10:46 : which means their code is going to
10:47 : directly call
10:49 : my code well then one day
10:53 : we decided saying hey i want to upgrade
10:55 : my java version to
10:58 : a higher java version and they break and
11:00 : their code can never call
11:02 : our java code anymore unless they modify
11:05 : their code
11:06 : so that is the problem but if they call
11:08 : us as a service
11:10 : they just and then we will run our code
11:13 : on
11:14 : our own and then they don't they
11:15 : wouldn't care
11:17 : which java version we're in and things
11:19 : like that
11:21 : okay yeah so that's the example
11:24 : this is more dependencies yeah um
11:27 : there's more point to failure that
11:30 : you're more
11:30 : intimately dependent on that library
11:34 : uh and and that tends to happen more
11:37 : with code libraries than api
11:41 : calls yeah although you there are code
11:43 : libraries that have
11:44 : a small surface area as well i would i
11:47 : would say
11:48 : like like if you if you just bring in a
11:50 : library
11:52 : that generates uuids for you that
11:55 : that's a very small service area for a
11:58 : library so
11:59 : it's dependent on what the library is
12:02 : trying to do
12:02 : or how many features the library is
12:05 : trying to provide for you
12:06 : coming back to your first point we're
12:08 : always gonna have new
12:10 : change requests that cause
12:13 : you to have to change something you can
12:16 : never predict
12:17 : everything that's going to happen but at
12:19 : the same time you want to have
12:21 : relative stability because if everything
12:24 : is unstable that means
12:27 : you're gonna have to change a lot of
12:29 : code all the time
12:31 : to to implement any new feature
12:34 : and that that's gonna be very costly
12:38 : so the relative stability is i think
12:40 : what
12:41 : this open close principle is going for
12:43 : right you want
12:44 : stability despite the fast-paced
12:48 : changes in requirement so basically what
12:50 : we're saying is we're going to give you
12:53 : these extension points with which you
12:56 : can
12:56 : sort of plug in these these placeholders
12:59 : right um for functionality and and this
13:03 : example is like
13:05 : i have a square or a circle how to draw
13:08 : a square
13:09 : or how to draw a circle that
13:12 : that depends on what shape it is how to
13:14 : draw the thing depends on what shape it
13:16 : is
13:16 : and that's going to be a different piece
13:18 : of code
13:20 : to draw a square which is draw a circle
13:22 : so what you could do
13:24 : is do a switch statement and see which
13:26 : one
13:27 : it is and then call the appropriate
13:29 : function
13:30 : or you can make the drawing part
13:34 : an extension point that that is like a
13:36 : placeholder
13:38 : and the implementation of the shape
13:40 : whoever is going to come in and
13:42 : implement the shape
13:44 : will provide the draw function
13:47 : which i believe is what the next one is
13:50 : yeah so
13:51 : if you're gonna implement the square
13:52 : you're gonna have to provide
13:54 : how to draw the square if you're gonna
13:56 : implement the circle you're gonna have
13:58 : to provide how to
13:59 : draw the circle and if later on somebody
14:01 : provides a triangle
14:03 : they would have to provide how to draw
14:05 : the triangle that's the solution
14:07 : that this article is all about
14:10 : what do you think does that solve our
14:12 : problems actually
14:14 : uh circle back to what jason said about
14:16 : earlier
14:18 : we just we have this function called
14:21 : draw all
14:21 : shapes and that function is going to be
14:24 : stable
14:26 : for any new instances of shapes that you
14:30 : add to the code that you add a triangle
14:33 : this function doesn't have to change at
14:35 : all
14:36 : because because the triangle is going to
14:38 : provide its own draw
14:40 : method and that just kind of plugs
14:43 : right into here to to jason's point like
14:46 : you're just gonna see green right you're
14:49 : just gonna see
14:50 : a file that's all addition uh
14:53 : relative to the logic that's needed for
14:56 : the triangle but the existing stuff
14:57 : didn't change
14:59 : uh so my question is does that solve our
15:01 : problem i
15:02 : i have a thought yeah
15:06 : i think it's the main thing that is like
15:09 : to me the
15:10 : uh the opposite of this issue i guess
15:12 : that's probably going bad to leaky
15:14 : abstractions which is why that's the
15:16 : other subject we're talking about
15:18 : is that this open close principle says
15:21 : well if you just if you abstract it
15:23 : then we never have to change because
15:26 : everybody just implements their draw
15:27 : method
15:28 : and that's great and and then we just
15:29 : call the draw method you can implement
15:31 : whatever you want
15:32 : on the flip side i think that is
15:33 : actually a huge negative that you can
15:35 : implement
15:36 : whatever you want um because
15:39 : even though it would be wonderful if our
15:41 : code was just incredibly modular
15:44 : only did exactly one thing all the time
15:46 : and we're always striving for that
15:48 : oftentimes in reality the fact is that
15:50 : draw method is going to have to be a lot
15:52 : more complex
15:54 : than just this perfect little unit of
15:57 : i'm going to draw something
15:58 : and you know you always have the risk of
16:01 : other developers
16:02 : perhaps less experienced developers but
16:04 : perhaps more experienced developers who
16:05 : have a need
16:06 : you know doing something around that
16:09 : abstraction
16:10 : that you know it works for every shape
16:12 : but it doesn't work for this one
16:14 : and that can be a very like difficult to
16:17 : track down bug and also very difficult
16:19 : to manage because all you've said
16:21 : is you get to execute some code at this
16:24 : time
16:25 : i just want to add to jason's point
16:27 : which is
16:28 : how do you draw the line of what
16:32 : kind of code you want to put in the draw
16:34 : all shapes and what
16:36 : code you want to put in each for each
16:40 : module to take out for example if draw
16:42 : has
16:42 : a validation of some sort you can't draw
16:45 : more than
16:47 : 60 square feet where do you put that
16:50 : okay all the shapes need to have same
16:55 : validation now what
16:56 : do you put in draw all shapes or do you
16:58 : put it as another interface or like what
17:00 : do you do yeah
17:02 : camera yeah
17:06 : in my ui framework i actually had to
17:09 : come up with something to solve that
17:11 : problem
17:11 : and what i came up with is a concept
17:15 : called
17:15 : the region and basically the region has
17:18 : the job of
17:18 : checking the bounds checking if you're
17:22 : correctly drawing within the bounds that
17:24 : you're allowed to draw in
17:26 : and you're going to have to use a method
17:28 : on the region object to draw
17:31 : so that so that the checking is
17:33 : completely enforced
17:35 : by the region so so the draw method
17:38 : would take a region
17:39 : and the shape that needs to draw needs
17:41 : to ask the region to draw
17:43 : the thing but i think the point is
17:45 : though
17:46 : when jason was saying hey there might be
17:50 : some special case
17:52 : where this way of
17:55 : specifying the boundaries of what is
17:58 : your responsibility versus what is the
18:00 : engine's responsibility
18:02 : that scheme may not work out for
18:05 : whatever reason
18:06 : developer has to get it working somehow
18:08 : so they're going to cheat
18:10 : like in the draw case it may be there
18:12 : there's they have
18:14 : in addition to drawing they also do
18:17 : something that's a side effect
18:19 : inside the draw method or something
18:21 : weird like that and then
18:23 : maybe it works for them the first time
18:25 : but later they found out that causes a
18:27 : bug somewhere i don't know
18:28 : cheating yeah can lead to problems
18:32 : if you ask bob martin about this he
18:35 : would probably say
18:37 : well you should introduce another
18:39 : extension point
18:40 : right like your your set of extension
18:43 : points
18:44 : is not enough to satisfy the new
18:48 : requirement and therefore you should
18:50 : probably add a new
18:51 : extension point to satisfy your scenario
18:55 : so that you don't have to cheat does
18:57 : that sound right to you jason
18:58 : so yes full agreement yeah maybe every
19:01 : shape has a
19:02 : can draw method that returns a boolean
19:04 : and so the loop first calls
19:07 : cash can i draw the shape and then if
19:08 : they can then it draws
19:11 : for for the example but like your
19:13 : solution of
19:14 : well instead i should actually pass a
19:16 : dependency that helps the shape draw
19:18 : itself into the draw method
19:20 : um is much more elegant and not just
19:23 : spit out in two seconds off the cuff and
19:25 : like i think that kind of represents the
19:27 : challenges
19:28 : like you said that developer who maybe
19:31 : is less experienced maybe isn't as
19:33 : familiar with the architecture
19:35 : like then that challenge is to
19:38 : like how do you do you even know to
19:41 : extend it and if you are extending it
19:44 : like if you just throw in a can draw
19:46 : method now we have this kandra method
19:48 : that everything has to deal with
19:49 : whereas it would have been far better to
19:51 : implement in a different way
19:52 : and now you are talking about making a
19:54 : change to everything possibly later
19:57 : because you have to because this kandra
19:59 : method just isn't doing it
20:00 : what you really need to do is like pass
20:02 : in a dependency like you're saying
20:04 : i mean i i wouldn't necessarily say like
20:07 : my method is more correct or anything it
20:10 : depends on situation to situation and
20:14 : everything is a trade-off but you're
20:16 : saying if you
20:17 : add a sort of extension point then all
20:20 : the existing classes
20:21 : have to also add that extension point
20:24 : and that's
20:25 : that's a cost it becomes a very like
20:28 : it's
20:28 : very meaningful changing this interface
20:32 : which i i think is hard to avoid it's
20:35 : not
20:35 : just meaningful it's it's a cost in that
20:39 : all the existing things have to uh
20:42 : adhere to the new standard and all the
20:45 : future things
20:46 : also have to adhere to the standard and
20:49 : also
20:49 : in this case you introduce a change to
20:52 : the engine as well you have to
20:53 : put if can draw in the draw all shapes
20:58 : in this case but if you introduce
21:02 : is toby's solution can can toby solution
21:06 : avoid a change of draw all shapes
21:08 : no no because okay i'm proposing add
21:12 : a parameter to the draw method
21:15 : okay so you in this case yours but you
21:17 : don't have to change
21:19 : the inner uh implementation
21:23 : of draw all shapes do you oh yeah yeah
21:26 : you do
21:27 : because you have to take the region and
21:30 : supply it to
21:31 : all of the calls gotcha
21:34 : toby i like what you said about you it's
21:37 : a cost because it's a cost you're paying
21:38 : now
21:39 : and in the future and i think we're all
21:42 : pretty good at looking at that now cost
21:44 : but that future cost is what's scary
21:47 : because yeah it's not that your method
21:49 : is right or that can draw a method is
21:51 : right or some other method of doing it
21:52 : is
21:52 : right it's just that whatever you decide
21:56 : you're gonna yeah so you're gonna have
21:58 : an experience
21:59 : yeah and because of that cause you're
22:01 : kind of worried like what if i make the
22:03 : wrong call
22:05 : what if i what if i yeah well i make
22:08 : this decision
22:09 : i have to make the decision today
22:11 : because the software is going out on
22:13 : friday
22:14 : so i have to make a call right now but
22:17 : if i
22:18 : make a sub optimal call later on i'm
22:20 : going to regret it
22:22 : and then i want to change it i want to
22:23 : remove this one and add a different one
22:25 : maybe
22:26 : and that's another cost that we're gonna
22:28 : have to incur
22:30 : so it gives you pause to do something
22:33 : like this
22:34 : is a developer that's not as experienced
22:37 : that they probably wouldn't even think
22:40 : of
22:41 : extending the protocol they're not
22:44 : experienced with
22:45 : doing that kind of thing this higher
22:48 : level design
22:49 : um that they're just more used to you
22:51 : know adhering to whatever the current
22:53 : standard is
22:56 : so they're not gonna want to do that and
22:58 : they're just gonna try to
23:01 : cheat and uh and somehow implement it
23:04 : with the current standard oh one thing i
23:07 : wanted to mention
23:09 : that bob did it should be clear that
23:13 : no significant program can be 100
23:17 : closed and what he means by closed
23:21 : is protected from modification
23:25 : like he would use the word close in the
23:28 : context of
23:30 : hey by by adding this extension point
23:34 : uh letting you sort of freely extend
23:38 : how to draw any shape you want i have
23:41 : closed off my draw or shapes method
23:45 : because my draw or shapes will never
23:47 : have to change
23:49 : as long as this current uh protocol
23:53 : works out so we've closed the draw all
23:56 : shapes
23:57 : but but then right after that he says it
24:00 : should be clear that no
24:01 : significant program can be 100 closed
24:05 : so he's saying you always have possible
24:09 : feature requests that causes
24:12 : changes that you did not foresee so that
24:16 : you still have to change this code
24:18 : because of some of the things we said
24:20 : earlier
24:21 : toby would you say it's fair in general
24:24 : to say that
24:25 : open close principle the the closed
24:27 : piece is focusing
24:29 : like on implementation but if you're
24:32 : actually talking about
24:33 : architecturally redesigning or adding
24:35 : architectural features
24:36 : to a program you know you're you are
24:39 : that's what he's kind of talking about
24:40 : you have to step out of it you can't
24:42 : just have code that magically doesn't
24:43 : change
24:44 : forever i would say this is like if code
24:47 : can be closed can be protected from
24:50 : modification as long as the
24:54 : extension points you came up with all
24:57 : happen to match the future requirement
25:00 : yeah that's true if you are really good
25:03 : at predicting
25:04 : what variations are going to come
25:07 : to the code in the future then you can
25:10 : you can be really good at closing off
25:13 : your program
25:15 : but all that depends on the correctness
25:19 : of your prediction it depends on whether
25:22 : the change requirement is
25:24 : to add the functionality of draw stuff
25:26 : in order
25:27 : versus like oh if i want to change the
25:30 : exact order uh which one orders
25:33 : uh goes first so that maybe is what
25:35 : jason said about implementation
25:37 : but this whole functionality is that
25:40 : like
25:41 : that that is the source of changing the
25:44 : engine
25:45 : because you still have to put the order
25:47 : stuff in the engine
25:49 : when this new requirement comes in since
25:51 : closure cannot be
25:53 : complete it must be strategic so the
25:55 : designer must choose
25:57 : the kinds of changes against which
26:00 : to close his design so yeah
26:04 : you have to try to predict well this
26:07 : takes a certain
26:08 : amount of pre
26:11 : what is this word that's precedence
26:14 : prescience
26:15 : what what is that it's kind of just
26:17 : another word for like awareness
26:20 : awareness but but more of like a future
26:23 : facing awareness okay
26:27 : yeah future vision yeah exactly exactly
26:29 : what i was saying like
26:30 : you need to be good at predicting the
26:32 : future
26:33 : uh derived from experience yeah that's
26:36 : that's fair yeah yeah
26:37 : i do agree that with more experience
26:40 : you're
26:40 : more able to predict the future