YouTube Transcript:
Architecting LARGE software projects.

Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.

Video Transcript

View:

So per request I'm going to give a talk

about how to structure uh large uh

software projects

and um I'm going to talk about like my

philosophy for how to do design and how

I think about like the structure of

large things. Um I recently gave a talk

where I talked about how every any piece

of software should be able to be written

by one person and a lot of people didn't

understand or had questions. So it's

kind of a followup to that. Um if you

want to go watch that um go to better

software conference their uh channel I

will link to them and you can see the

talk. Um but this is more of a deep dive

how to actually build software. So let's

let's get going.

So I'm going to very very brief sort of

handwavy develop three pieces of

software today. And uh I'm going to make

a video editor. I'm going to make um a

digital health health care system

because that seems to be something that

every government fails at and I'm going

to build a jet fighter. So, um those are

all complicated things and uh just

before you, you know, start typing that

I don't know what I'm talking about, um

I won't go into every detail. Obviously,

these are huge software projects.

There's lots of new ends and I'm also

not really a domain expert in any of

these. So, um I'm not actually teaching

you how to write these specific pieces

of software. I'm trying to tell you how

I approach various pieces of software.

So, um any of these projects, you know,

you would need a lot of people who are

have like domain expertise. you would

need to have like people have a good

idea of the problems that need to be

solved and and so on so forth. I know a

little bit. So I'm going to use this as

a stepping off point to u talk about how

to develop software. But um if you if

you want to know details or about any of

this like I've never developed software

for for a jet fighter. So you know um

don't take all of that with a grain of

salt. That's that's not the point here.

Okay. Um so this is about process not

the specifics. Um, so let's talk about

the structure. Like how do we structure

things? That's the main thing. And when

we plan a big project like this, we want

to optimize for certain things. We want

to optimize for or I want to optimize

for dependability. You want a project

that lasts forever and never breaks. You

want it to be extendable so that you can

add new features and capabilities and,

you know, things that can change. Um,

you want to have team scalability and a

lot of this comes down to that you want

to have very few people or preferably

one person working on each section of

the problem. And therefore, if they are

insulated from everybody else, you don't

have to have like huge team meetings

where everybody's working on the same

thing. You want to create a lot of small

projects instead of having one big

project. And obviously, you want

development velocity. You want to be

able to get done basically and you

don't want, you know, usually with

software, the the longer you work, the

slower things get. And you don't want

that. You want, you know, same velocity

all the time.

Um, and a big portion of this is just

reducing risk. Like things are going to

go wrong. That's is just life. But you

want to reduce it. So what you got to do

is you got to think about what your risk

profile. What what is most likely going

to fail, right? and you want to want to

really avoid those problems. Um, so here

are some of the things that can change,

right? Um, platforms can change either

through API or maybe they change their

hip with the users anymore or things

like that. So you want to insulate

yourself from platforms that change. Um,

you have language implementations. If

you write something in, you know, the

hip cool language today, if you're

building a system that's going to be

around for, you know, 20 years or

longer, like a jet fighter will be along

around for 50 years. A healthc care

system will probably be around for close

to that, right? U a lot of the video

editors are from the 80s and 90s. So

having software that can live for

decades is really important. And

therefore you need to make sure you

write it in a language that there will

be compilers for in the future and

things like that. And then obviously

changing hardware,

changing priorities. You may need

certain things in the future that you

don't need today. And you may lose

people, right? So what happens if you're

a star programmer leaves the the thing?

Um these are things you really want to

worry about, right?

So a lot of small chances of failures

equals a big chance of failure, right?

Um a lot of little things that might be

easy to fix, um if you have enough of

them and they happen frequently enough,

uh things grow really really tiresome,

right? So you even if things you know a

lot of people say, well that's an

trivial fix, you know, a compile error

somewhere that you can just like fix.

That might be true, but if you're

working on something and all of a sudden

your software stopped working because

somebody else added a little problem,

you have to context switch and stop

working on that and fix this other thing

and you know it grinds to halt. You have

to look at code you don't understand and

things like that. So you really really

want to avoid like even the small speed

bumps because as projects grow you get

more and more of those speed bumps and

you get more and more you know problems.

So I'm a C programmer. I use C89. It is

the most dependable language you can

have. Um it will compile everywhere. It

will last forever. It you know works

works works works. Um I am currently

actually trying to document what I call

dependable C which is like the

subsection of C that you can depend on

and it's mostly C89 if you want to be

really safe but there's some parts of

C99 that are pretty safe to use as well.

Um but really these rules

it doesn't matter if what language you

use like you can you can apply all the

other things like if you're um you could

use C++ you could use Python you could

use anything really to to write this.

This is not a language specific thing.

Um however I do think like language is

one of those risks like Python just

broke everything when they went from two

to three. like if you have a you know

millions of code that are in Python 3

and they decide to make Python 4 and

break the backwards compatibility

you have a major problem on your hands.

So So yeah, this is kind of the rule.

It's like it's faster to write five

lines of code today um than to write one

line today and then have to edit it in

the future. You really want to finish

your code. You want to write code so

that it never breaks, right? And if that

means typing a little more, being a

little bit, you know, more explicit

about what you want, that's a good

thing, right? Because you're thinking

about it now when you're writing it. And

going back, you know, five years from

now trying to figure out what it does

and fixing it, even if it's a trivial

fix is really, really hard, right? And

it stops working. You want things that

are really dependable. you you leave

code when it's done when you know you're

not going to have to go fix it in a

couple years and that's that's really

really key. Um so you want to modularize

your software, right? If you're going to

have multiple people working, you want

to modularize. So how do we do that? So

in my opinion modules should be pretty

much black boxes. What they do should be

exposed through APIs or protocols. So

you talk to it and it has an interface

that you can document that is clear and

you understand and then whenever you

want to use it, you talk to that. But

you don't actually have to know what's

behind the scenes, right? Somebody wrote

it. It's rock solid. It just works. You

don't have to know what it does. You

never have to look at the code. You

don't have to integrate with anything

outside of the API. The API is

documented. Um, and this is why I like

header files in Z because you can have

huge amount of code and then hide it

behind one header file says here's all

the functions you're allowed to use.

Here's how you access all the

functionality. How I implemented that

you don't have to care about because I

solved it for you, right? Um, so this

means you can have one module can be one

person, right? And that's really key is

like you can um you can really split

everything into small modules and each

each module can be one person right and

you have multiple modules and that's

what I mean every piece of software

should be able to be written by one

person and by that means it's like you

split it down to modules and the modules

are small enough that one person can

write it and at some point somebody is

going to sort of write the application

and they do that by taking a bunch of

existing modules modules that other

people are written and just merging them

and using all the those things to to do

the thing, right? And that's why you can

have essentially a single person writing

all of these pieces of software that

we're going to discuss today.

Um, so yes, obviously you can have good

programmers that can finish a module and

then make the next module. That's fine,

too. Um, but the rule is that you should

really avoid having multiple people have

to work on a single module. You may have

lots of people working on designing a

module or like deciding how the API

should work, but I really think it's

good to have only one person

implementing it.

Um, so yeah, some modules are going to

be senior and some are going to be

junior. There's going to be modules that

are hard to implement and there's going

to be easy stuff. So you want to really

think about that and give the hard

modules to your senior people and you

know the easy stuff to your junior people.

people.

And this is a really interesting thing.

What if what if that module breaks or is

terrible in some way? Well, if you have

an API for it and that API is good, you

can actually reimplement that API in a

new blackbox that uses, you know,

different algorithms, different

everything and all the software is using

that will still work, right? And that

means that if you have a piece of

software that is owned by a certain

person, you can actually if that person

leaves, you can write rewrite that from

scratch and then gradually move to the

next version. And um and that's really

really powerful.

Um so let's talk about the video editor.

We're going to talk about you know a

basic video editor. So uh it's a native

application with a UI. So let's start

there, right? So, you're going to want a

stack that looks something like this.

You want a platform layer. You want to

open a window and do things like that.

You want to be able to draw, you know,

lines and things. And then you want to

be able to do text. Um, text could be in

the drawing library. Um, and then you

want some UI things so that you can do a

UI for your application. And the text

can also be in the UI. It happens to be

in in my UI library.

So um you really should wrap your

platform layer and the idea here is that

anything that you don't own which would

be the platform you should not talk to

directly you should make a wrapper

around that and there are a bunch of

rappers out there so for instance SDL is

a wrapper you could use however even if

you use something that is online and and

you know open source and you know

generally really good you still don't

control that, right? You don't know the

direction of their development. You

don't know, you know, if you're going to

need something else, if you um need to

add functionality, you don't know if

they're going to accept your patches.

So, even though you're using, you know,

something really good, um you really

want to wrap it so you don't actually

have a bunch of calls directly to code

you don't have in your code. So, um I

can show you this. This is betray.h, H

which is the header file for my wrapper.

Um and it contains all kinds of things

but it allows you to you know open a

window you know just get input lots of

things. Um and this was actually

implemented over SDL from the beginning

but SDL didn't have this was SDL 1.0 so

it was a long time ago but it didn't

have all the features I wanted. So I

made another backend that was win32 and

then we've got lots of other you know

operating systems. Um but this really

gives you the control over over the platform.

platform. Um

and um then you want to definitely write

uh a demo application uh test

application. So I happen to have mine

here. So this is my little test

application and this um is a minimal

application that just opens a window,

reads mouse pointers, draws something.

There's like some buttons here that do

things. I can click here. I have a

little window here. If I, you know,

scroll my window, I get all the events.

So this is like really really useful

when you try to port this API to another

platform because if you're building a

huge video editor with lots of you know

millions of lines of code you don't want

to have to port all of that code over to

the platform. You want to start with

something very very small and very

simple. So therefore it's super useful

to do this. Usually you write this while

you write the platform later because you

need something just to test that what

you're doing is correct. Um so this is a

great little thing. So I can uh show you

you know uh hold on here is a screenshot

of the same software running on Android

and it's run on lots of other things and

this is like when you pl you move to a

new platform this would be the first

thing you do is it's just um get that

going and here is you know the file so

it's it's not huge but it draws some

stuff it, you know, it basically tries

to exercise all of the API. Now,

normally when you actually implement

this, you tend to um comment out most

things. So, you you start with just like

open a window and then when you get that

working, you're like, okay, now I'm

going to comment out like read the mouse

pointer and you you know, as you work

through, eventually this whole

application will run on the new platform.

platform.

So there are things to consider when you

do a platform layer and what those are

depends on your plat your application

what you want to do but like what kind

of inputs do you want uh you know screen

resolutions um aspect ratios um scale um

do you want cut and paste do you want

file requesters safe spaces is getting

more and more important meaning

basically you know your window may be

this big but maybe you're on a phone and

there's a notch in the way or something

like that or rounded corner. So, you

shouldn't really put text there. So, you

need to be able to detect um which areas

of the screen are actually safe for UI

or for for information. And then you

might want to support things like

multi-user. So, my uh layer um has not

just input from multiple input devices

but also from multiple users. So for

instance, you can have two controllers

and therefore um those are two different

users giving input. Um, and therefore my

proto um my API supports things like

having two mice and two keyboards

connected to a computer. And therefore

you can in my UI toolkit you can click

one user can click with a mouse pointer

in a text field and start typing while

the other user clicks in another text

field and starts typing and the the the

typing will go to the right window. Now

right now there's no platform that

actually supports that. So, Windows

doesn't properly support that and I

don't I I I don't know of a platform

that supports that. But if there is a

platform in the future that will support

that, all my applications will just

work, which is super useful.

Um, so then you also want to consolidate

a lot of functionality, right? You want

to take all the disperate things that

you could have on a platform and make

them one thing, right? So, um, you know,

in my example, all buttons are the same.

It doesn't matter if they're on a

controller, on a keyboard, or a mouse,

doesn't matter. All pointers are the

same. So mouse pointer is the same thing

as a touch. So basically, we have

multi-touch, multi-pointer, they're all

the same. And you just, you know, a

touch is basically a mouse pointer that

doesn't move when you're not clicking

and that um only has one button, right?

And the same goes with axis. So that

would be joysticks or pedals or whatever

input you have. it gets a little bit

more complicated. We'll get into that

later. So now you want to do a drawing

layer. Um you need, you know, basic

things to draw UI. If you want to do

something, want to draw lines, surfaces,

images, maybe shaders, maybe geometry,

it depends on what you're trying to do.

Um this is mine. This is Relinquish.

It's built over OpenGL, but it actually

designed so that you can run it over

Vulcan or any any backend. And I'm

hoping to implement that at some point. Um,

Um,

and then you want to do text. Obviously,

all applications need text. And here's

kind of a an example of how I would

implement that. Like you can implement

the simplest possible text. So, you can

take, you know, a font you find online

like this one that is like just a bit

mapap font. You load it in, you make a

bunch of, you know, squares and you draw

this, right? And if you implement this

um you can make a simple function that

draws text uh

float there it's supposed to be um you

can draw this really really easily right

so since you have this way of thinking

about black boxes now you can actually

make a black box that draws text and it

can be super simple like like a bit map

text doesn't do anything complicated but

once you have that you can you know

people can start writing UIs that text

and then you can go in and you can have,

you know, proper font loading. You can

have, you know, all kinds of good stuff,

right? So, you can do true type fonts

or, you know, anti-aliasing and kerning

and all that stuff that you don't care

about, right? So, this is a really

important thing. It's like you can you

can give somebody an API uh for

something that isn't actually finished.

Like it it draws text, but it doesn't

draw nice text. But that's fine because

other people don't need nice text in

order to be able to start building

interfaces. They just need text, right?

So this API that I'm showing here is

actually not very good because this one

doesn't get you all the things you want

to do. So I'm going to show you this is

my function for drawing text. It's

actually one out of many.

So for instance you want to give it what

font you want to give it you know the

size of the letter the spacing of the

letter you know the text and you want

you don't want the text to be asy you

want it to be UTF8 or something like

that um you want a color and you want a

length specifier so you can limit how

long of the if so you can uh just print

a part of the text now and then you want

it to return how long the text is right

so even if you implemented it using this

uh this stupid font font with no kerning

and nothing. You can still build this

interface for it, right? Maybe the font

is, you know, just null for now. And

that gives you the default font. And

there is no, maybe there's only one

font. Maybe you can't choose fonts, but

you still have a font parameter there.

And that means that people start writing

this can start writing code as if it was

done. And then when it gets done the

text will start looking great but will

actually you know nobody has to

reimplement all the places where they

wrote uh use the text functionality. So

this is really you you want to learn how

to think forward right you want to think

what are we going to need in the future

right and really avoid implementing ah

is good enough for now um because you

want to finish stuff um and if you have

to um you know you know text for

instance you may not want to do Arabic

which is backwards and things like that

or Korean or things like that right

maybe your product team can't wait uh

for for you to implement that because

they need to ship something, right? So

then you can implement something simple,

but you never implement a a good enough

for now API. The API is the same. You

know, you think through I'm going to do

Korean at some point. So let's make an

API that is is good enough for Korean

and then people can use that and even if

you can't draw Korean now, it will in

the future and they won't have to change

their code. So that's really really important.

important.

Uh and then you can you know do the same

thing build a UI toolkit. I have a UI

toolkit. This can be modularized. Mine

is one big UI toolkit but you can

modularize it for button and things like

that. And I would argue that making a UI

toolkit is relatively easy. Like buttons

are easy to implement, sliders are easy

to implement. The only thing that is

kind of tricky to do in UI is is text

input. So, um, not relying on the

operating system, not relying on a

platform is is not a big deal. And

especially if you're making a portable

thing, a portable application. And if

you have to figure out how like three

different platforms do a slider, you're

going to need more time to do that than

to implement your own slider. So, just

make a slider.

Um, so, okay. So, now we have this,

which is like our our base layer. Now,

one of the things you might notice is

that like um you can actually none of

this has to do with the the video

editor, right? This is just like stuff

you can build anything with like any

desktop or or mobile app. You can just

write it, right? So, once you've done

this, this is actually a superpower for

for yourself, for your company. And to

me, it's like amazing that like large

billion dollar software companies don't

own this. like they should just have

this so that they quickly can make

whatever product they want to make in

the future. Like you should not have to

rely on the operating system to to draw

text. You know, if you're, you know,

even if you're a small company, you

should be able to do this. If you're a

huge company or a big company, you

should definitely have this as as part

of your tool toolkit.

Um, so yeah, these are all sort of

helper libraries, right? And um you

really want to put as much as you can in

helper libraries because helper

libraries can be reused for any project,

right? So fell parsing, physics engines,

uh scripting, data storage, networking,

all kinds of stuff like that, right? So

for instance, for networking, you know,

I have Testify, which is a library that

does all of the the things you need to

do and it can figure out what kind of

network you're on. It can do, you know,

all kinds of stuff. It opens up ports

with port forwarding protocols. It it

can find peers. It can do all kinds of

stuff. And um it's really really

powerful. And um it basically means that

I never have to care about like the

socket API ever again, right? And I can

improve this under the hood. So there's

capabilities of of like how to connect

and how to you know u do certain things

that I can improve under the hood

without changing any of the applications

that use it.

Okay. So now we're getting to the core

which is when you're actually starting

to build the application you're building

and this is kind of the majority of this

talk and how to how to build a core.

Um so what are the things we are

editing? What what is the thing that

this application does? How can we

generalize what it does, right? So, um,

in my opinion, a video editor is not

something that edits video. It edits a

timeline, right? It's a timeline, a

bunch of clips that overlay each other

and they're in time and you can from

that you can generate a video. You have

a bunch of clips, you have an input data

and then you have a rearrangement of

that input data and then you get an

output. Right? So, we can think about

this as as you know, clips on a timeline

with animated parameters, right? Because

we're going to need parameters. We want

to zoom in. We want to color correct. We

want to do titling. We want to do all

kinds of things. So, those are going to

be parameters that these clips have.

So, everything is a clip, right? Now,

we've made it really generalized, right?

And this is really key. It's like if you

can generalize things, you can make

really nice software. So Unix everything

is a file right and that means that you

know lots of stuff in Unix are

compatible because it's like this takes

a file this outputs a file you can

connect those together and things work

right um software like uh Houdini uh I

think I have a screenshot here is

basically a node graph the whole

software it's a big visual effects

package is basically one big node graphs

where each node has parameters on it

that that's what Houdini is right and uh

notch I I just want to bring up because

they're awesome is the same thing. It's

it's a node graph to do visual effects.

Right? So these are you know basic

structures that you can put your whole

application into. Right? If you take

something like Unreal, it gets more

complicated. Right? Unreal is C++. It's

a bunch of C++ but there's also

blueprints and there's also scene graph

with assets. That means that you can't

generalize everything quite as easy and

you end up with situation where like oh

we've done this in Bluetooth uh in sort

of blueprints sorry uh but we wanted it

to be in in C++ or we did this in C++

but now we can't access it the way we

want it in blueprints or is this is an

asset is it blueprints what is data what

is it gets a little bit more complicated

and this is not directly to critique

Unreal Unreal does very very complicated

things. So sometimes you can't simplify

things like this, right? Um the world

isn't as simple as you want it to be, right?

right?

Um so what you want to think about and

what I think a lot about is something I

call primitives. And primitives is sort

of a word I borrow from computer

graphics. Um I have a computer graphics

background. So I think I think in

polygons or or or things like that and

we want to talk about polygons, right?

So if you want to make geometry, you can

define them by polygons, right? So

typical, here's a Utah teapot. It's a

bunch of polygons like little triangles

or quads. And that's a very simple way

to express 3D data. But you can also

think about other ways of doing it. You

can do nerves. They are mathematical

curves. Um they can actually do, you

know, curves. Uh polygons can't do

curves. So if you want to do a car

modeler, you nerves are way better. Uh

but nerbs are really really complicated

mathematically and they're not easy to

deal with and and you need a lot of code

to manage them. Um you can also do

something like this like this is tear

down. So tear down everything is built

out of voxels little cubes if you will

even though they're not. Um and that

means that it's super easy to do

collision detection. It's easy to do

destruction. It's easy to do a whole

bunch of things that are super hard to

do with triangles. Um, on the other

hand, there things like making a smooth

surface with a bunch of little cubes is

pretty much impossible, right? So, you

win some and you lose some basically.

And then, you know, we can go further.

This is, you know, sign distance fields

which are, you know, a new hot way of of

doing mathematical shapes. um that gives

you a bunch of other advantages um and

disadvantages or you know my favorite is

subduction surfaces. This is from my

subdution surface modeler which gives

you a poly mesh that gets rounded into a

a smooth surface or a smoothish surface.

But which one of these you choose really

makes you choose what kind of software

you're building. And some of the more

advanced softwares like you know Maya

and and others they allow you to have

multiple different representations of

geometry. But that also means you get a

lot of complexity in your software

because now there's functionality you

can do on nerbs you can't do on polygons

or things you can do on on your voxels

but you can't do on your polygons. So

you have to convert back and forth and

you get lost and it be getcomes really

complicated. So if you can find a

primitive to store your data um that is

consistent and that works for everything

that's really really neat, right?

So um Unix uh let's talk about Unix some

more. Like Unix is a good example

actually of this. So Unix everything is

files, right? Pretty much text files.

They're not any file. And that means you

can grap it for a piece of text and you

can find it and that's great. But it

doesn't work for like you can't GP for a

quote from you know a MP4

file that contains Casablanca. You can't

find all the good quotes because GP

works on text not on video right. So by

limiting yourself and saying everything

is a text file, you can do a lot of

things with text files, but when you

want to do video editing or image

editing or something that isn't text,

you know, Unix and the command line is

not really a good interface.

And there here's I want to talk about um

primitives versus structure, right? So

in Unix you could say that the structure

how we use um this is we use command

lines with pipes to pipe things between

applications right but the thing that

moves between the application the format

of the data that goes from A to B that

is files and that's the primitive right

and if we change the primitive we could

make a command line system that where

you can pipe video from A to B and then

the primitive would be video but we'd

still have the same structure right or

we can also have a structure where we

have you know a UI as a node graph but

where through the cables we push text

right so we use the same primitive so

these are two different things you have

to think about like when you choose how

to design this right and here's an

example so Photoshop has the structure

of a bunch of layers which isn't really

true in modern um Photoshop because

Photoshop is complicated but we can

think of it as a bunch of layers of bit

maps right whereas Nuke which is a

compositing software. Uh I have a

screenshot here. This is a node graph um

from Nuke that allows you to composite,

you know, video essentially. Um the

primitive is still bit maps. There's

still bit maps moving through this

thing. Um but it's a tree structure now.

So again, you know, both of these, you

know, they're not really always bit

maps. They're, you know, they can do

curves and things like that, but sort of

generally you can think about these as

two different things. Um so in our case

when we want to do a a video editor we

say that all tools that we want to make

operate on clips right when you move in

your timeline you're basically editing a

clip or you're changing parameters of

that clip that's all you do all the UI

everything does that that's what the

application actually is so we want to

build a black box that stores this

information right stores a timeline and

have an API so we can access it Right.

So, uh, an example of something that

actually exists that does that is open

timeline io, which is an open, um, API,

Python API to create a timeline.

Um, you would probably build your own. Um,

Um,

so when you build this core that keeps

all your data from your application, you

can enforce these kind of guarantees.

So, in our case, we kind of want to do

certain things. For instance, we want,

you know, clips not to have negative

time or, you know, maybe we want clips

to never be longer than the asset they

are using. Maybe we want, you know,

consistency in time. Maybe we want

whatever we think is important and that

we want to guarantee. And that means

that when APIs call this, they don't

have to care about that, right? They

know that the data they are going to is

going to have, you know, certain

requirements and and be clean, if you

will. Another thing you might want to do

is undo, right? Other application can

just say change the clip like this and

automatically this you know storage

container of will actually manage

figuring out what the changes are from

the last version and be able to undo

those. Um so therefore you want to build

that into your core structure.

Okay. So what kind of clips do we want

to support? Like we want to load all

kinds of video, right? So, how do we do

that? Well, if the core has a definition

of every clip you could ever want, every

video format, every effect, everything,

then the core is huge and it's not

possible for one person to write it. So,

we really, really don't want to do that.

So, we want to build a plug-in

architecture. We want to build an API

where, you know, a piece of code can go

in and say, I can do this. I can show

you video of MP4 and I will give you

this information about the length and

resolution and things like that and I

will need you know the speed you want it

to be played back at and the default of

that is you know 1x and you know you

want to describe this plugin basically

um and this plugin so you basically get

something like this this is my structure

for this so you have a core with a bunch

of plugins and And then we have our UI

toolkit. The core here um doesn't

actually have a UI, doesn't do anything.

It's it's just a core, right? That you

can, you know, read in plugins and then

you can access the plugins. So let's

have a look at what you want to write

next. Well, you want to write a

launcher, right? You want to write

something that you know starts up the

platform, starts up the core, loads in

all the plugins, and actually does

something. So, uh, in my case, uh, let's

see. I think I'm missing something here.

Um, I'm going to show you some demos of

this in a second. Um,

in my case, you, this might be enough,

right? You might just have all the UI

and all the APIs here. You just write a

UI for, right? If that's a simple application.

application.

Um, and I'm going to show you a simple

application. So uh let me show you an

application I have written that works

kind of like this. So this is stellar.

Um it's actually stellar 2.0 which is an

application to control u lights and

and

you can I I'll show you a little bit

about how this works. So here is a 3D

world and here u we have a light

fixture. So now I looked on the network

and has to be a light fixture there. I

can create a collection of light

fixtures which gives me inputs and then

I have a bunch of these which are things

that do things and these are plugins. So

all the effects in this application are

plugins. So I can for instance create a

sphere and I can connect this to this.

So now you can see I have a sphere here

and um I can actually move this sphere.

I can change parameters. I can make it a

little fade. I can change the color um

or whatever I want. And then this

application happens to be a node graph

as you can see. Um I can bring in other

things like I can create some motion

here. connect this to motion and then uh

run it on a loop.

So now it

it moves very fast, right? So now I've

created a a simple effect, right? And I

can bring in some other things like I

can bring in

color ramp.

So I'm going to take this ramp. Sorry.

Sorry.

And I'm just going to make it slightly smaller.

smaller.

So I'm going to connect this to the ramp

instead. So now it gets a single color.

And then we're going to drive this ramp

with this thing. And now I can say a

color here and another color here. And

let's let's make it black here. Right?

So now I can remap and do all kinds of

stuff. So um this is kind of what this

application does. Um but if we if we

look under the hood, you can see that

actually all of these are plugins. Even

this is a plugin. It's a built-in plugin

um that just sort of magic plugin that

talks to like fixtures. And then these

are all just describing what they do. So

if we look at the internals of this um

this API is what you build your UI from.

You basically say here's to create an

effect and you know you can create

nodes. You say which node you want. Um

you can get all of the you get the

descriptor that tells you what

parameters it has and then you can set

those and you can build basically a UI.

So this this little thing is all you

need to really build the whole UI,

right? So the core can be kind of small

and then you on top of that build a UI

and that means I can rebuild the UI

without ever rebuilding the core. And

one of the things about this application

which you might want to do with a video

editor is you can actually take your

core and make a separate application. So

let's say you have you know your video

editor and then you save a video editing

file. Maybe you want to have a, you

know, a command line tool that can just

take that and process the video for it

because you want to run that on a server

or something like that. Well, then you

can have the core and then you skip all

the UI, all opening window and just make

a little command line thing and all of

the core of the application that does

all the processing is completely

separated from the UI.

Um, and we can actually I will show you

a plugin. So here is um a file that is a

bunch of plugins and what you do to

create a plug-in is you these live in a

separate DL and that means that um the

application stays kind of small and you

can have people writing DLLs and you can

add those one by one and those people

can basically work completely isolated.

They don't have to know the people who

write the co core. They can just follow

an API and and make any plug-in they

want. And most of the interface, most of

the the functionality in the application

sits inside of those plugins. So here's

kind of a simple way you say, "Hey, I

want to do a sphere," which was the

effect we saw. It's it will output

color. It's part of a shape. You know,

some text you can put in UI that

describe what it does. And then you list

all of the inputs of it, what what

they're called, what the default values

are, you know, a little bit of UI hints

of how you might want to draw this. And

then you also give it a function. And if

we go to that function, this is the

function that actually does the the

computation, right? So this allows you

to implement new features really really quickly.

quickly.

So, um, and actually just to be really

nerdy about it, um, this API, this kind

of plug-in API, I also have that for for

for Betray, which is my platform

library. So, if we look here, this is

the platform. This is a plug-in for for

doing uh controllers on on Xbox

controller, basically Windows

controllers. So that means that when I

build my system, I don't have to link in

special code for for Windows. That's a

separate plugin that can be built

separately. And therefore, you know, I

don't have a dependency on that. Um I

only have a small DL that has a

dependency and the system will work just

fine without it. It's just sort of an

optional thing. And that means that it's

you can have a lot of little

dependencies, but you don't ever need

all of them to build it. you need no

almost no dependencies to build the the

the project but then you can add the the

the stuff you want. Okay, let's move on.

Um so um

you want to present um information and

capabilities and this is kind of a

pattern that comes up almost always to

me. And when you build structures for

things, you want to be able to have

things say what they can do and what

they um what they can tell you, right?

So here's like a very simple washing

machine, right? If you look at these two

strcts, what am I doing? You can think

of type defaf. It's like I am a washing

machine. I'm currently running, you

know, and you have an enum for what kind

of mode you're in. What's my current

temperature? What's my current load? And

how many seconds do I have left? Right?

If you if you get this information with

the information of the structure like if

a if a washing machine can say these are

the parameters I can tell you about

myself that's all you need to build a UI

right you could build an app that works

with this right and then the same thing

is like you need a struct to say

basically here's the parameters you need

to send me in order to tell me what to

do like you know you need to tell me if

I should run or not in which mode and in

which temperature, right? And I can't

for the life of me why believe why the

um the people who do IoT stuff um can't

get this right. But really, you want to

you don't have to know that it's a

washing machine to build this system,

right? All you need to know is this is

the stuff that it wants to tell you.

This is the stuff it needs to know,

right? And whether that's a washing

machine or a toaster or a whatever

doesn't matter, right? And I'm actually

working on a project called Marshall,

which I hope to make a new video about

that will solve a lot of these issues.

Okay, so here's our new updated design.

We might have a core, bunch of plugins,

but we may also have a launcher UI and

then plugins to that, right? So if we

have a complicated UI, um we may have a

launcher that starts it and then says,

"Okay, there's a bunch of panels here.

the panels that show information, they

are themselves plugins and they talk to

the other plugins and do the graphics

and therefore we can split up the UI. So

we have one engineer doing just a

timeline and one doing you know the

video view or color correction or like

all the different sections we we may

split those up and not have one code

base, right?

Okay. So let's build a health care

system and you're going to see that it's

very very similar. Um so first obviously

you want to figure out your

requirements. uh you want to figure out

what's the primitive what is the data

that flows through you know health care

system and uh maybe medical journals

right that's what people think well

probably not the greatest things I think

we should probably have healthc care

events right because if you think about

it your health care journal is a bunch

of events like starting with you being

born and a bunch of things happen every

time you go to a doctor that's an event

right and what's neat about that is you

can then also have future events like

your appointments and you can also

access the data in a different way. So

you may for instance want to say I want

to get all of the health care events at

this clinic today, right? And that means

I want to access everybody who is going

to be here and when they're going to be

here today, but I don't want their full

journal, right? I might be a clerk

somewhere. I'm not allowed to read all

the information, but I need to know

who's going to be here. I need to know

when there is a, you know, gap in the

schedule, and I need to know that,

right? So let's go with that. Let's say

we're doing a bunch of events, right?

And then we do exactly the same thing as

we've done before. We build a blackbox

and you know, here's what people start

out with. They say, "Well, you know,

what kind of storage would you choose?

Would you do SQL or blah blah blah or

Amazon or whatever?" And that to me is

completely the wrong way to go about it.

What you want to do is what are we

storing and how are we accessing, right?

And that is a blackbox how it's actually

stored, right? So I would probably store

it at some kind of open-source

thing that I would find good. You can

write your own or whatever, but to all

the users of the system, none of that

matters, right? And that means you can

actually change your storage anytime you

want. You can rewrite it and go

somewhere else, right? You don't want to

lock yourself to, you know, Amazon or a

certain vendor. You don't want to even

lock yourself to, you know, MySQL or

something that is stable and open

source. Who knows what you're going to

want to use in the future, right? So,

you really, you know, for the users of

the system, they shouldn't have to know,

they shouldn't have to like do SQL calls

because there might not be SQL behind

it, right? You need to make your own

interface for how to access this thing.

And that means you're way more flexible.

Okay. So the second thing you can do

once you built this is once you have an

a API between your black box you can

take whatever old system because guess

what your health care system probably

has something anient that you want to

get rid of but you don't want to switch

over right that's what a lot of projects

like this they fail because they switch

over right and the switch is really

really painful so why do that so what

you do is you write a little piece of

glue code that uses your access API with

the old access API Okay. And just moves

all the data between it. So when you get

a new event or new data into your

system, you move it into the old system,

when the old system gets something new,

you read that out, put in the new

system, right? So now nothing will

break. Now you can gradually move over,

right? And this is super useful that you

don't want to have this breaking change

where you say we go from system A to

system B. No, no, you want to have both

system at the same time, right?

And then you can start doing other glue

codes on top of this, right? So let's

say you have this black box. Maybe you

want to have multiple APIs to use it,

right? Maybe you want a C API, but hey,

nobody's going to write C, right? Maybe

the hardcore people want to write a high

performance C thing, but you know, most

developers not going to use C. So you

can make a C++ API on top of it. You can

make a Python binding. You can make all

kinds of bindings on top of S. and they

just use the same API. And then you can

get, you know, your hardcore C++ nerd to

write the perfect C++ thing. Actually,

there is no perfect C++, but whatever,

right? You can have different people

writing these glue codes that that gives

people multiple ways of accessing the

system u without needing, you know, to

basically use the the core APIs. And

then of course when there's new

languages, new capabilities or new ways

people want to access, you can write new

GL glue codes, right? And then you can

write stuff on top of that. So on top of

your glue, you can say, well, now we

take data out of the blackbox and you

know, we send it over the internet and

now we can write a app that does

something very specific, right? So we

can have hundreds of different apps for

different kinds of health care people

for machines that you know do things

with healthcare and they can all report

back through the internet and they can

use their own way of of talking just as

long as it ends up in in one of these

sockets right and now we can build a

website right so we you know let's say

we use Python so we can take you know a

Python API and we can generate a website

and you can use a browser to access the

information Right? So you can sort of

fan this out and grow a tree of stuff,

but everything goes through this central

black box of thing, right? Um now in

reality that blackbox might run on one

machine or a thousand machines or you

know but to the users to these

applications it's just an API you talk

to and you don't have to know what

happens in the background if there's a

big server infrastructure to store all

this data. you know, how it's sliced and

dice. None of none of that you have to

care about because this is an API to you.

you.

Um, so let's build a jet fighter. Okay.

And that you're going to see that it's

pretty much the same thing. Okay. So,

um, we have lots of things here. We have

lots of sensors, weapon systems, like

capabilities forever, right? And a lot

of these capabilities, we don't even

know what they are because if you build

a jet fighter today, it's going to be

around for 50 years. So who knows what

kind of missile or drone or sensor or

whatever you want to put on this thing

you know 25 30 years from now. So even

if you can probably survey this and you

can probably have some really smart

people who can tell you all these things

even they are not going to be able to

know. So you can't really architect a

system knowing what it's going to be

right. Okay. So what is a primitive we

might be able to use? So we might say

well the primitive here is the state of

the world like a whereas a health care

system cares about history um a jet

fighter mostly cares about what's going

on right now right it wants to know

where are all the contacts where are the

enemies how much fuel do I have how many

bullets do I have left you know which

radar can detect which object you know

what's the wind temperature all kinds of

things right that all these sensors and

things are are giving you, right? And

you want to care about some things that

are specific to, you know, aircraft. So,

you know, you want to have confidence,

right? How how, you know, how much do I

trust this thing, right? Um, and you may

not trust everything in a war, turns

out, right? You want accuracy, right? If

you have two different things that

measure the same thing, you want to know

the accuracy of those things, right? Um,

you want to know what the source is,

right? So if you get temperature from

something, you want to know what the

source of that temperature is. Um you

want to know what the format is, right?

So you might have multiple formats of

things like maybe I want to know where

position of this enemy. Do I want it,

you know, in relation to the the jet

fighter or do I want to know where it is

in the world? Like those are two

different things, two different ways of

asking where a thing is, right? And then

I want a bunch of capabilities. Like I

want to know if you put on a missile on

the plane, you want to know what can

this missile do, right? And when you

fire it, you want that capability to be

gone, right? And you want people to be

able to add new capabilities, new

missiles, new things. And then the

system should be able to understand that

now you have a new capability. And then

um you probably want to have things like

damage like things you know accuracy may

go to zero if somebody has blown off a

sensor or something like that.

Okay. So you want to build again a core

right uh blackbox to store this. So what

you do is you make an authorative core.

You make a core that has like here's the

world according to all the sensor and

all the stuff. This is the current

state, right? But then you're going to

have lots of little computers around,

you know, lots of systems, every every

little radar, every, you know, the

displays. There's going to be computers

everywhere, right? So all of those need

to know the state. So then you need a

protocol so that they can subscribe to

information, right? You probably want to

have a subscriber model where you know

um a certain you know the engine wants

to know you know the humidity and it

wants to know how much fuel or or you

know the altitude and things like that

but it doesn't need to know like um you

know how many radar contacts you have.

That's not interesting to the engine,

right? Doesn't care, right? So you want

to basically and you're going to have

some parts of the the the plane that are

going to have really powerful computers

and some parts going to have like microcontrollers.

microcontrollers.

So you want to be able to subscribe to

the information you want. You want that

to be push notificied to you. You may

have different rates how often you want

information and things like that.

And once you have that subscriber, you

can then on your local chip in your

local memory have you know a partial

state of the world right and you can

then use that to um make decisions right

and then you can even you know when you

when you build this system you can say

well we might want to have different

ways of encoding this information

between the subscriber and the

authorative core because we may have

different types of cables different

types of you know hardware

connectors basically, right? We might

want to support multiple of those with

different bandwidth, different

requirements, what have you, right?

But this still means that if you're

building a piece of equipment for this,

you now have a stable API, an API you

can call to know what's going on and to

send information. So if you're building

a radar, you can, you know, get the

humidity or whatever you need from the

system and then you can send all the

contacts you find to the authorative

core and the authorative core can send

that on to, you know, the pilot or the

visualization system or the screens or

the head-up display or whatever system

is interested in that information.

Okay, so it's not really a storage

system here. Like here's a pass through

system, right? you're passing data from

one end of the plane to the other. Um,

and you can obviously store as well if

you if if that's a requirement. Um, and

here is a really important thing um that

goes for all of these project and that's

if you build something like this, you

want to do a lot of tooling, right? So,

let's say we're building a new jet

fighter. Um, we haven't figured out what

it's going to look like, but we build

this core, right? and we're going to

have all these different contractors and

people building missiles and things and

they all have to somehow connect to this

thing. How do we do that? Right? They

can't like how do you how do you test a

missile when the button in the uh that

the pilot is going to press isn't done

yet, right? So therefore, you want to

have lots of toolings, right? So you

want to be able to take all the input

from various things and record it,

right? So now you have a blackbox

recorder, right? Because all the

information goes through this thing. So

you can have a little recorder that

subscribes to all the information and

stores that, right? Great. And then you

can have a playback. So now if you have,

you know, your first flight, you can

record information and then you can put

that to a missile and say behave. Here's

a real flight that we recorded. Here's

all the data from it. Now we can

simulate that, right? You may want a

Python API because maybe you want to,

you know, when you test a certain thing,

you want to simulate that, you know, um,

something happens like what happens if

this goes away or the radar stops

working or whatever. Now, you can

simulate things like you want a logger

so you can see what's going on. Maybe

I'm just implementing my radar and I

need to be able to see when the radar

outputs that it outputs correctly, that

the the data coming into the system is

correctly. Just having something that

can print it on screen is like super

useful. Um, you can have visualizer to

see what's going on. You can have full

simulators, right? And all this code

that I'm showing on on the slide are

stuff that never actually going to go

into the jet fighter, but they're going

to be really, really helpful because it

allows all these separate people who are

trying to write to this code to be able

to get the code to do what they want so

they can test their code, right? And

that's going to help them once you

actually start putting the plane

together and all these pieces talk to

each other. You know, if you can have a

missile and you can simulate what the

cockpit does and then you can record

what the missile does, you can send that

recording to the people who make the um

the cockpit and they can say, "Okay,

this is what we're expecting to get from

the the missile when when the missile is

firing or when the missile is finding a

lock or whatever the missile does, right?

right?

And and this would go for almost all the

projects I've talked about, like almost

like always write a bunch of tools that

that you can get your data out of your

black boxes and and or your core boxes

and and make them do things. Um at this

point, um this black box doesn't

actually know anything about aircraft,

right? It does it can't actually do

anything. It doesn't do, you know,

avionics. It doesn't do target tracking.

It doesn't do it doesn't visualize

anything. It it doesn't it doesn't do

anything. It just passes data through

it, right? And we're not actually giving

away anything secret here, right? So,

this could actually be open source,

right? You could give this away to

anybody, right? You could put it on a

website and says this, you know, we're

not going to tell you how far our

missile goes, but here's how our missile

tells the system how far it can go,

right? And that means you can have all

these contractors that can have these

manuals and go out and try to build

parts and you can have an open uh

bidding for making stuff that fits into

this plane, right? And and that makes it

a lot easier to to do things. Um because

you you've removed all the secret stuff.

You're just saying this is how we

collaborate. Um but you know um um the actual secrets and how it actually works

actual secrets and how it actually works that's up up to the end points and yes

that's up up to the end points and yes yes I know that no real military would

yes I know that no real military would ever make anything you know um open

ever make anything you know um open source because they don't understand

source because they don't understand this kind of things. Um, so yeah, now

this kind of things. Um, so yeah, now people can add all these bits. Now

people can add all these bits. Now people can add sensors and weapons and

people can add sensors and weapons and UIs and connectors and all kinds of

UIs and connectors and all kinds of stuff, right? But then you say, well,

stuff, right? But then you say, well, this is a crappy system because now we

this is a crappy system because now we have everything centralized. It's bad,

have everything centralized. It's bad, bad, bad. Like what if, you know,

bad, bad. Like what if, you know, somebody blows off this computer that is

somebody blows off this computer that is running the core thing now everything is

running the core thing now everything is terrible. You know, the plane crashes,

terrible. You know, the plane crashes, nothing works. That's true, right? So

nothing works. That's true, right? So that's a requirement for a jet. Like

that's a requirement for a jet. Like jets have redundant systems. So you

jets have redundant systems. So you can't have like one central core where

can't have like one central core where everything goes through, right? That

everything goes through, right? That wouldn't work. Well, you could easily

wouldn't work. Well, you could easily build multiple cores. The the thing here

build multiple cores. The the thing here is that you can have any number of cores

is that you can have any number of cores that sits on lots of different

that sits on lots of different computers. You can have lots of

computers. You can have lots of interconnects between all these systems

interconnects between all these systems that are redundant and over redundant,

that are redundant and over redundant, but the subscribers get their

but the subscribers get their information through the same API. Right?

information through the same API. Right? So that means you can make a single core

So that means you can make a single core that's very simple to implement. You can

that's very simple to implement. You can implement that, give that to everybody.

implement that, give that to everybody. They can get started on their missiles

They can get started on their missiles and equipment and all this stuff and

and equipment and all this stuff and then you can spend three years making

then you can spend three years making this advanced system that has multiple

this advanced system that has multiple cores that vote on which is one that can

cores that vote on which is one that can detect which one has been blown up and

detect which one has been blown up and doesn't work. And you can build all that

doesn't work. And you can build all that and then you present to the same people

and then you present to the same people here's the same API the same way you get

here's the same API the same way you get the same information. It's a drop in

the same information. It's a drop in replacement, right? But instead of

replacement, right? But instead of waiting three years to get that,

waiting three years to get that, everybody could get it, you know, in six

everybody could get it, you know, in six months, right? And that's really, really

months, right? And that's really, really core to this blackbox thinking. You can

core to this blackbox thinking. You can redesign the inner core to be more

redesign the inner core to be more complicated. And sometimes you do that,

complicated. And sometimes you do that, you know, because you figure things out

you know, because you figure things out and sometimes you do it because you need

and sometimes you do it because you need to get product out. So this is this is

to get product out. So this is this is exactly the same thing as we did with

exactly the same thing as we did with the text rendering. We started with

the text rendering. We started with simple text rendering but with the same

simple text rendering but with the same API and then we made nice text rendering

API and then we made nice text rendering afterwards but the users of that API

afterwards but the users of that API didn't need to change anything because

didn't need to change anything because it just works right

it just works right okay so here's a cool thing you could

okay so here's a cool thing you could put this in a tank now right it doesn't

put this in a tank now right it doesn't have to be in a plane it could be on

have to be in a plane it could be on anything right if you now that you have

anything right if you now that you have connection between things you can

connection between things you can connect multiple planes together they

connect multiple planes together they can share this information right so now

can share this information right so now instead of saying you know I got a radar

instead of saying you know I got a radar lock because my radar found this enemy.

lock because my radar found this enemy. You can have my neighbor, the other

You can have my neighbor, the other ship, you know, fighter found it or the

ship, you know, fighter found it or the ground radar found it or anything found

ground radar found it or anything found it. It doesn't matter, right? Because

it. It doesn't matter, right? Because now you have a way to communicate about

now you have a way to communicate about the state of the world, right? And

the state of the world, right? And you're obviously going to have lots of

you're obviously going to have lots of encryption and lots of things to control

encryption and lots of things to control what you want to get in and out. But

what you want to get in and out. But really, once you have a system like

really, once you have a system like this, you can, you know, make it very

this, you can, you know, make it very generalized. It doesn't have to be in a

generalized. It doesn't have to be in a fighter jet. It could be on transport

fighter jet. It could be on transport jet. It could be, you know, on a tank.

jet. It could be, you know, on a tank. It could be on anything. And that means

It could be on anything. And that means that now the people who make missiles,

that now the people who make missiles, they may want to make a missile that can

they may want to make a missile that can be launched from a tank and be launched

be launched from a tank and be launched from a plane and they have the same

from a plane and they have the same interconnect, right? they don't have to

interconnect, right? they don't have to write two software stacks to control

write two software stacks to control these two different things in two

these two different things in two different um things and things become a

different um things and things become a lot more interconnected and even if

lot more interconnected and even if there's going to be lots of differences

there's going to be lots of differences you can actually have the same knowhow

you can actually have the same knowhow and people will know people can move

and people will know people can move from different you know different

from different you know different projects and they know oh when I talk to

projects and they know oh when I talk to the system this is the API this is how

the system this is the API this is how you talk even though the thing I'm doing

you talk even though the thing I'm doing now is completely different

now is completely different hardware-wise or capability wise from

hardware-wise or capability wise from the last thing I was

Okay, so let's wrap up. Um I've talked for a long time. Um so um

for a long time. Um so um this is really uh

this is really uh can I make this smaller? There we go. Um

can I make this smaller? There we go. Um core to all software design in my

core to all software design in my opinion is format design. And format

opinion is format design. And format design is something that isn't really

design is something that isn't really taught and I wish people would teach it.

taught and I wish people would teach it. Uh, I'm trying to write a really long

Uh, I'm trying to write a really long article in a book about this because

article in a book about this because it's it's really is what we do as

it's it's really is what we do as software developers and a lot of things

software developers and a lot of things are formats if you think about it. An

are formats if you think about it. An API is a format. It's a format for

API is a format. It's a format for sending calls to some code. Files are a

sending calls to some code. Files are a format. It's a format of how you store

format. It's a format of how you store things in a file. Protocols like network

things in a file. Protocols like network is how do I store information in in a

is how do I store information in in a way that's a format. Programming

way that's a format. Programming languages are formats. It's a way you

languages are formats. It's a way you store how you know instructions for a

store how you know instructions for a computer and um it's also you know you

computer and um it's also you know you write in that instruction language. It's

write in that instruction language. It's a format of of what you can and what you

a format of of what you can and what you cannot do in this way to describe in

cannot do in this way to describe in instructions.

instructions. So formats are really important. There

So formats are really important. There are some things you should think about.

are some things you should think about. One is the difference between uh

One is the difference between uh semantics and structure. Right? So

semantics and structure. Right? So sometimes um you store semantics only.

sometimes um you store semantics only. So for instance uh the metric system is

So for instance uh the metric system is only semantics. If I tell you 3 m

only semantics. If I tell you 3 m everybody can figure out what 3 meters

everybody can figure out what 3 meters is. But I'm not giving you you know how

is. But I'm not giving you you know how do I structure that? I gave you that

do I structure that? I gave you that through words that came in sound. That's

through words that came in sound. That's not defined. You can write it down on a

not defined. You can write it down on a piece of paper. You can you know type it

piece of paper. You can you know type it into a computer. Doesn't matter. A meter

into a computer. Doesn't matter. A meter is a meter. Right? We we describe what

is a meter. Right? We we describe what semantically it means but not

semantically it means but not structurally how we send it right and

structurally how we send it right and reversely you can think of something

reversely you can think of something like JSON JSON is a format gives you a

like JSON JSON is a format gives you a structure for storing data but doesn't

structure for storing data but doesn't tell you anything what that data means

tell you anything what that data means there has no semantic meaning it's an

there has no semantic meaning it's an array of things but it doesn't say what

array of things but it doesn't say what those things are right so you need to

those things are right so you need to think about these things and what you

think about these things and what you make semantic and what you make

make semantic and what you make structure a lot of times you want to

structure a lot of times you want to have a simple structure

have a simple structure and then you can have more complicated

and then you can have more complicated semantics because then you can reuse

semantics because then you can reuse code that reads uh the semantics right

code that reads uh the semantics right so JSON again a JSON loader can load any

so JSON again a JSON loader can load any JSON it can store healthcare data or you

JSON it can store healthcare data or you know weapons data or um or video editing

know weapons data or um or video editing data doesn't matter right semantics

data doesn't matter right semantics doesn't matter you can use the same

doesn't matter you can use the same loader for all these kinds of things and

loader for all these kinds of things and that's kind of useful right but it also

that's kind of useful right but it also has its limits because yeah you can load

has its limits because yeah you can load it but you can't really do anything with

it but you can't really do anything with it because you don't understand it right

it because you don't understand it right you don't know what it means

you don't know what it means and formats need to be implementable and

and formats need to be implementable and this is really really key right it's

this is really really key right it's like if you want all these people to

like if you want all these people to come together and work if the API or the

come together and work if the API or the format is too complex it becomes really

format is too complex it becomes really really hard right if I'm going to make a

really hard right if I'm going to make a a UI and the data that I'm trying to

a UI and the data that I'm trying to make a UI for is super super complex

make a UI for is super super complex text then I'm going to halfass it and I

text then I'm going to halfass it and I make a UI that can only display like

make a UI that can only display like simple stuff right and then you start

simple stuff right and then you start getting incompatibilities right people

getting incompatibilities right people start saying you know oh I I don't

start saying you know oh I I don't support those things and languages are a

support those things and languages are a great example right the larger a

great example right the larger a language you have the the fewer

language you have the the fewer implementations you get or the more bugs

implementations you get or the more bugs you get in your implementations or you

you get in your implementations or you know there's more things that you know

know there's more things that you know more people can't read it it gets more

more people can't read it it gets more and more complicated right smaller

and more complicated right smaller formats are easier to implement and

formats are easier to implement and therefore the quality of implementation

therefore the quality of implementation are generally better, right? So you want

are generally better, right? So you want to pack as much power as mo possible

to pack as much power as mo possible into a simple interface, right? A simple

into a simple interface, right? A simple format.

format. And that's the thing is is formats are

And that's the thing is is formats are are two-ended, right? It's like if you

are two-ended, right? It's like if you save a file, you have to load a file. If

save a file, you have to load a file. If you send a network pack, you have to

you send a network pack, you have to load a network package. And if you make

load a network package. And if you make a complicated API, u somebody has gonna

a complicated API, u somebody has gonna have to use that complicated API, right?

have to use that complicated API, right? So it's like a language, right? So the

So it's like a language, right? So the more you make it complicated for your,

more you make it complicated for your, you know, other people, you make it more

you know, other people, you make it more complicated for yourself. And it it sort

complicated for yourself. And it it sort of squares a lot of times, right? If you

of squares a lot of times, right? If you have 10 different people and they each

have 10 different people and they each want a feature, you're going to get, you

want a feature, you're going to get, you know, 10 features and now everybody has

know, 10 features and now everybody has to implement this. And a very common

to implement this. And a very common thing is to say people say you know I

thing is to say people say you know I wish this file format um you know let's

wish this file format um you know let's say we have polygons and nerves and some

say we have polygons and nerves and some people think polygons are good and some

people think polygons are good and some people think nerbs are good and they say

people think nerbs are good and they say I wish this was nerbs and not you know

I wish this was nerbs and not you know but the problem is if you support both

but the problem is if you support both polygons and nerbs even if you want

polygons and nerbs even if you want nerbs you're going to have to implement

nerbs you're going to have to implement nerbs and polygons and the other end is

nerbs and polygons and the other end is going to have to implement polygons and

going to have to implement polygons and nerbs. So now both have to implement the

nerbs. So now both have to implement the the system they don't like and the

the system they don't like and the system they do like, right? So everybody

system they do like, right? So everybody has to do more work and it's actually

has to do more work and it's actually better to just pick one of them and then

better to just pick one of them and then some people are going to be less happy.

some people are going to be less happy. But even if they're less happy, they

But even if they're less happy, they only have to implement one thing. They

only have to implement one thing. They don't have to implement two things. Even

don't have to implement two things. Even though, you know, it's better to

though, you know, it's better to implement one bad thing than implement

implement one bad thing than implement one bad thing and a good thing. That's

one bad thing and a good thing. That's more work, right? So you really want to

more work, right? So you really want to make it as small as possible.

make it as small as possible. Um, so make choices. That's really

Um, so make choices. That's really important, right? Like a lot of people

important, right? Like a lot of people when it comes to formats, it's like,

when it comes to formats, it's like, look, my format can do a million things.

look, my format can do a million things. And whenever I see that, that's like

And whenever I see that, that's like your format's going to fail because

your format's going to fail because nobody's going to implement all those

nobody's going to implement all those things, right? Um, so um, and also

things, right? Um, so um, and also manage constraints like what can I

manage constraints like what can I require, what's the requirements of this

require, what's the requirements of this format? If I know certain things, then

format? If I know certain things, then that helps, right? If I know that all

that helps, right? If I know that all the data coming from the the core of the

the data coming from the the core of the fighter jet is in metric, that's great.

fighter jet is in metric, that's great. I can, you know, do that. Or even if I

I can, you know, do that. Or even if I don't like metric, maybe the core lets

don't like metric, maybe the core lets me choose and I know that I can be

me choose and I know that I can be guaranteed that it gives me feet if I

guaranteed that it gives me feet if I want feet and and meters if I want

want feet and and meters if I want meters and the core is going to handle

meters and the core is going to handle that for me. That's great. I can rely on

that for me. That's great. I can rely on that. it's, you know, I don't have to

that. it's, you know, I don't have to think about it. Um,

think about it. Um, think about interactions. That's that's

think about interactions. That's that's a very core thing. You know, if we're

a very core thing. You know, if we're making a video editor, we have a

making a video editor, we have a timeline or do we have multiple

timeline or do we have multiple timelines? Do we have a video stream or

timelines? Do we have a video stream or maybe want to support multiple video

maybe want to support multiple video streams? Are are we supporting

streams? Are are we supporting stereoscopic video or we maybe we want

stereoscopic video or we maybe we want to have like video all around us like 50

to have like video all around us like 50 displays at the same time. Can we edit

displays at the same time. Can we edit that? Can we you know and and this is

that? Can we you know and and this is really important like how many

really important like how many interactions do you have right and it

interactions do you have right and it goes for almost everything like can you

goes for almost everything like can you can can this fighter jet have one radar

can can this fighter jet have one radar or many radars or can it have a world

or many radars or can it have a world view or can it have multiple world

view or can it have multiple world views? Can I you know should the pilot

views? Can I you know should the pilot be able to pull up a world view from

be able to pull up a world view from another plane? Is that a useful thing?

another plane? Is that a useful thing? Or do they live in the same world? Like

Or do they live in the same world? Like who knows, right? These are things you

who knows, right? These are things you have to decide and it's really easy to

have to decide and it's really easy to forget to to split them up and get too

forget to to split them up and get too little interaction but it's also really

little interaction but it's also really easy to have too many levels of

easy to have too many levels of interaction so it's like gets really

interaction so it's like gets really really complicated to traverse and find

really complicated to traverse and find the thing you want right

the thing you want right um and then you want implementation

um and then you want implementation freedom and I talked a little bit about

freedom and I talked a little bit about that about the health care system you

that about the health care system you want to basically say this is how you

want to basically say this is how you talk to me about health care but how I

talk to me about health care but how I implement healthare is none of your

implement healthare is none of your business Right? I there's many many

business Right? I there's many many different ways to build build a server

different ways to build build a server farm that holds healthcare data and I

farm that holds healthcare data and I want to be able to change that and I

want to be able to change that and I don't want to in my API say you know oh

don't want to in my API say you know oh you can you know if my API has a a

you can you know if my API has a a function that says oh you can send in

function that says oh you can send in your own SQL query right and I allow you

your own SQL query right and I allow you to do that well then all sudden now I'm

to do that well then all sudden now I'm required to have an SQL query language

required to have an SQL query language and if they start sending queries for

and if they start sending queries for certain properties. Those properties

certain properties. Those properties have to be in that SQL query and work.

have to be in that SQL query and work. And now I've locked myself into SQL on

And now I've locked myself into SQL on the back end. Right now I I'm screwed.

the back end. Right now I I'm screwed. Right? And if I want to move to a

Right? And if I want to move to a backend that doesn't use SQL, game over,

backend that doesn't use SQL, game over, right? So you really really want to make

right? So you really really want to make sure that that you you put locks between

sure that that you you put locks between these things. And basically it's same

these things. And basically it's same thing with text rendering, right? You

thing with text rendering, right? You can do it as a bit map. You can do it as

can do it as a bit map. You can do it as curves or polygons or whatever. The user

curves or polygons or whatever. The user just draws text. They don't have to know

just draws text. They don't have to know how it's implemented. So if you want to

how it's implemented. So if you want to change our implementation approach in

change our implementation approach in the future, we can do that.

the future, we can do that. Okay. Uh another big question is plug-in

Okay. Uh another big question is plug-in systems. So do you want a plug-in system

systems. So do you want a plug-in system where you plug yourself in or you get

where you plug yourself in or you get plugged in? Right. So um I tend to think

plugged in? Right. So um I tend to think if you can make things that can get

if you can make things that can get plugged in that's good because um you

plugged in that's good because um you don't want other system to dictate how

don't want other system to dictate how your code works. And I I I said this for

your code works. And I I I said this for it's like you don't want to live in

it's like you don't want to live in somebody else's world. You want to live

somebody else's world. You want to live in your world and accept other people

in your world and accept other people into your world. You don't want to go in

into your world. You don't want to go in somebody else's world and live in their

somebody else's world and live in their world. So when you make a plugin that

world. So when you make a plugin that plugin lives in your world. it lives in

plugin lives in your world. it lives in the world of the the thing it plugs

the world of the the thing it plugs into, right? So, if you can make things

into, right? So, if you can make things that are not plugins, um, then that's a

that are not plugins, um, then that's a good thing. If you can make them as

good thing. If you can make them as modules that are standalone that do not

modules that are standalone that do not require to be plugged into something,

require to be plugged into something, that's a great thing. But a lot of times

that's a great thing. But a lot of times that's not possible. So, therefore,

that's not possible. So, therefore, plug-in interfaces are often the right

plug-in interfaces are often the right right way to go. But uh if you can try

right way to go. But uh if you can try to make things um that can be plugged in

to make things um that can be plugged in can be reused and plugged into other

can be reused and plugged into other things.

things. Um that's it. Um that's my talk. So I

Um that's it. Um that's my talk. So I would definitely like to thank everybody

would definitely like to thank everybody for watching and um you can always find

for watching and um you can always find me on stream on Twitch uh or keels.com

me on stream on Twitch uh or keels.com or on my Twitter or all the other

or on my Twitter or all the other socials at Kelsar. Thank you for

socials at Kelsar. Thank you for watching. Bye everybody.

Click on any text or timestamp to jump to that moment in the video

Most transcripts ready in under 5 seconds

One-Click Copy125+ LanguagesSearch ContentJump to Timestamps

Paste YouTube URL

Enter any YouTube video link to get the full transcript

Most transcripts ready in under 5 seconds

Get Our Chrome Extension

Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.

Add to Chrome — Free

Works with YouTube, Coursera, Udemy and more educational platforms

Get Instant Transcripts: Just Edit the Domain in Your Address Bar!

YouTube

←

→

↻

https://www.youtube.com/watch?v=UF8uR6Z6KLc

YoutubeToText

←

→

↻

https://youtubetotext.net/watch?v=UF8uR6Z6KLc

YouTube Transcript:Architecting LARGE software projects.

Video Transcript

Paste YouTube URL

Transcript Extraction Form

Get Our Chrome Extension

Get Instant Transcripts: Just Edit the Domain in Your Address Bar!

YouTube Transcript:
Architecting LARGE software projects.