Hey Ben,
Hey Matt,
How you doing?
I'm doing great.
So it's time for another podcast recording. And as always, we have a clear plan as to exactly what we're gonna do. Huge agenda point, lots of bullet points down here that we're gonna hit every single one of and not at all are we just gonna make it up as we go along.
No, never. That would be irresponsible to our listener.
Our listener would hate that. I know they would, they would expose them to the fact that we just make all these things up as we go along. So you and I were discussing before we hit record, um, about some of the things that we've talked about before and in passing, we've mentioned, uh, the fact that, um, I briefly ran a small C++ tools company. And one of the examples we have in our like document of ideas is writing tools is difficult and, or doesn't make money. And I figured
We should talk about that cuz I certainly have some firsthand experience and I dunno what, what, to what extent you have any dis, have you ever built like developer tools?
Yes! Oh yes. So this is another situation just like when we, we both wanted to go into the games industry, this is another thing that we have both done. I have also started a developer tools company and I think I had a very similar, uh, experience to you in that it didn't go great.
How do I not know this?
Um, yeah. So this was, uh, well, I, so do you want me to explain mine first and then you can explain yours?
You explain your situation Cuz I always talk about me.
Not true, but yeah,
Very true.
Um, yeah, so the, the experience that I had is when I, uh, I was working at a startup in Dallas and me and, uh, a couple of friends, although I, I, I think I wound up doing like most open source projects. That's like, you know, 99%, one person than 1% other people in the early days. Um, but, uh, that's not true. I don't know why I said that. That can be true. But in any case with this thing, we, uh, built a, uh, a test runner for Java, uh, called Infinitest and Infinitest does, is it inspects the bytecode of the class files that whatever, you know, compiler editor that you're using generates, um, and when those class files change, it will work out the minimum dependency based on the static dependencies. Obviously it doesn't really handle things like reflection and stuff like that, but turns out that's actually not that big of a deal.
Um, but it would analyze the dependencies between the files that you change to figure out the minimum set of tests to run. And, and the idea behind this tool is that if you're working in a very large Java code base with like, you know, tens of thousands, hundreds of thousands of tests, even if they're well written fast tests, they still take a long time to run the full suite. And so doing this kind of dynamic dependency analysis helps speed it up. It would also run the tests in parallel across, um, multiple threads, which additionally helped speed it up. And so the idea basically behind this tool is that we, um, it was a tool for working with sort of very large code bases with a lot of tests. And the interesting thing about this is that at the very same time, uh, Kent Beck was building a tool called JUnit max and JUnit max was kind of attempting to solve a similar problem, um, but in a much different, and I have to give him credit much simpler way.
Which is, um, he, he had based it off of some research, um, kind of blanking. There's a guy named David Saff who did a bunch of research into testing and sort of patterns of testing. And I think it was David's research that Kent was using when he did this, but I don't actually know if that's true, so don't quote me on it. But, um, but anyway, Kent basically had, had, uh, seen and, uh, had discovered through research that the, the duration of tests is power law distributed. And so you have like most tests are actually pretty fast. And then you have a few tests that sort of, you know, uh, are, are slower. And then they're sort of this power law curve
You've not seen the project that I'm working on right now.
Um, and so he's like, okay, well, if that's how tests are generally distributed, then you can get the most feedback the fastest by just running the tests in speed order. So you just run the fastest tests first, and then you leave the slower tests to the end. And, you know, his rationale was like, okay, yeah, you could do all this sort of dependency analysis stuff, but...
But really you could start with a much simpler thing and then say, okay, after 30 seconds we've already run.
Right.
The good sort of was gonna say the 20/80, but like it's more like the 99/1 theory. I mean, obviously that means that there is a hole in your testing that maybe you...you at least for like the interactive case when you're just fidling around and saying, I'm changing this and I'm changing that. And you do to get the green tick a bit too early. And obviously presumably you still run the full test suite before you like do a large commit, but this is about interactivity and about...
Right, right, right. Um, and so he had built this tool right around the same time that I was building it. And we were both like really drinking the Kool-Aid of like the lean startup philosophy. Right. Um, which, you know, um, Steven, Gary Blank's book, you know, "Four Steps to the Epiphany" and there's a guy named Eric Ries um, who was talking a lot about like, you know, how to build a startup by, you know, sort of iteratively building technology, looking for product market fit. Um, and so Kent and I were kind of doing the same thing at the same time, um, in the same space. Um, and the way I was doing it was I, I had been working at a startup. We sort of built this open source tool. And then I went to work for a consultancy named Improving Enterprises. And, um, we sort of had the idea when I was at Improving to say like, hey, we could take this open source tool.
All of the people who wrote it are employees of Improving Enterprises now because the startup had folded cuz of the financial crisis. So, um, it was easy enough to get everybody in a room to be like, all right, do you grant your IP to this new company that we're forming? Cool. Awesome. All right, we're done. Um, so we got all the authors of the open source, you know, tool together and sort of formed this company and tried to sell it. And you know, I think we maybe sold a dozen copies, maybe two dozen copies of this thing,
But this was an open source project that
Well that we had closed
I see. Because you had everybody's buy-in at that point. I've never really thought about how that is achievable. You know, I know how software open source projects can be relicensed and I suppose this is a special case of re licensing where you're saying, well, the last version that we had is open source, but if we move on,
right, right.
Now it's not, we are, we don't have to keep that. Interesting.
Yeah. I mean the open source version was still out there, but this is like, oh, we're gonna turn these into like proper IntelliJ and Eclipse plugins. And we're gonna put a lot of work into making the economics really nice because, you know, the thing that was open source was basically like a really thin wrapper around the dependency algorithm. Right.
Yeah, which is the cool bit of tech that...
Yes. It is the cool bit of tech
And, and then obviously there's the other 90% of the program, which makes it like as usable and as intuitive to a user and um,
Yeah, yeah, yeah. So it's like, that's sort of that long tail of like making it, turning it into a real product instead of like a, a, a prototype basically, which is sort of what the open source version was
Yeah, or more of a DIY thing, like most open source projects tend to be, you know, there are notable exceptions to that, you know, we have, we have friends who are very good at generating open source projects that are sort of, uh, immediately usable and obviously how to use.
True
And I'm certainly, I'm trying to learn how to make that more the case for my own open source projects.
Yeah, yeah, yeah. I'm with you there. Um, but yeah, so we formed this little company within, what
Was the name of the company?
Improving Works was the name of the company. So Improving Enterprises was the name of the consultancy Improving Works was the name
Improving Works
Yeah. Yeah. Um, and so, you know, we had, you know, a little board of about four people. We had, we, we would basically like, um, get developer time from some of the consultants that were at the consultancy at like a reduced rate and bill it back to the, um, product company. Got it. Um, and you know, a lot of, a lot of my time was, was spent that way when I was on the bench at, at Improving Enterprises. Um, and you know, we tried to polish this thing up and we, we had a few customers, we had some people that really liked it. Um, but it was just really, really difficult to sort of get the traction because, you know, the, the thing that I saw, and I don't know if this mirrors your experience too, um, is that the people who are your users are not the people who have the budget to buy it.
That is exactly my, yeah. Yeah. My, my experience.
So you wind up in this terrible situation of either having to convince the people with the budget, that it's a good idea to buy the tools and optimizing for that, or optimizing for the actual user experience, which is what you would really want to do, except that those people don't have any money to buy it. So you wind up not selling it. Exactly. Um, yeah.
Yeah. You realize that you, you have to sell to the business, not to the developer, and that's a tough, tough market when you are really targeting the developer cuz that's who you are, you know, how to sell to a developer.
Right.
Right. Although, so in my own experience, one of the things that I maybe erroneously, but now I'm thinking about it, having not thought about it for 20 years, um, thought was, I wonder if there is a little part of a developer for certain tools where if it seems like a simple problem, like as you've described it to me, apart from like a bit of bytecode, um, fidling, uh, it's, you know, Hey, follow the dependency tree backwards and then find a test that are dependent on that. That's great. Right. You like, I could write that myself, right. That doesn't seem too hard. Why would I pay my own money to get that? When, if I had the time I could just write it. And then the question in your mind is like, when will you have the time? And could you actually write it if you put your mind to it?
Obviously you pretty much anything is achievable, but like, you know, I'm, I'm not going to, I'm probably not going to write my own IDE. So I think I can, I can square buying an IDE, um, because it makes me that much more profitable as a, as an individual even, you know, I actually buy most IDEs myself so that I can have them for all my own projects and everything I do without any kind of encumbrance, rather than relying on like the work ones. Yeah. Um, but you know, if someone just gave me for example, and we'll get back to this a source code formatter, you know, I could write my own source code format. How hard can it be? It's just a bunch of regular expressions and a bit of whatever. So why would I pay for one of those that's that becomes difficult.
Right.
Um, so that's the secondary part, but then the other, yeah, as you say, the thing you identified is that really the people who control the purse strings, uh, in a different org often, or at least a couple of levels above the, your, your intended customer direct customer, you need to prove to those people that it's worth the productivity boost that their developers will have. And so you have to convince them and not the developers themselves.
Yeah. Yeah. So the, the name of your company was Profactor. Am I getting that right? That
Is correct. Yeah. Profactor.
So what was Profactor?
Naming is hard. I think we've, we've, we've, I dunno if we've covered naming is hard, but it is the single most difficult thing to do. Uh, so the story and I, I, we may have talked about this before I forget, but the short version is, uh, my, my full and, um, Nicky Hemings. And I were working together at Argonaut games where we were working on all sorts of Xbox and PlayStation2 titles. We were exposed to giant messes of huge sprawling C++ code bases. And while down the pub, uh, we kind of kicked around the idea that maybe we were doing the development of C large C++ projects wrong. We had just right read John Lakos' large scale C++ design book. And it was very, uh, pragmatic solution to how do you lay your project out physically? You know, how do you decide which things go in header files, which things goes in CPP files?
How do you decide which sub directories and libraries and all these kind of things that you should lay your project out to optimize for developer productivity, as well as the design of your software? Because unfortunately those things can go hand in hand with something like with like C++. And we, we are sort of drunk the Kool-aid from that. And we had decided that a lot of this stuff could be automated and a lot of it could be generated, um, by rather not a lot of it could be made easier by approaching development in a different way. And so our big idea was rather than storing a C++ program as a bunch of text files, holding the whole thing as a database where functions and class definitions and all that good stuff are held purely as table entries or rather, you know, rows in the TA in tables.
So, um, the IDE such as it is understands that fundamental connectedness of a lot of all the things, you know, you calling printf and it's not like the text P R I N T F is in the code. It's like, no, this is a reference to the function called printf. And it's an invocation of that. If you need to show it to the user, you obviously look it up and say, printf open paren, and then all the arguments in it. But when you need to give it to the compiler, you probably do need to give it the same information, but you've got an option there. You can choose, oh, well, this is where I'm actually just gonna in line and output the text of that function. Or this is where I'm just gonna refer to it and say, well, the linker will provide this later on, or this is where I'm gonna put it in a header file amd all these tricks that Lakos' book was talking about when you decide to allocate objects versus put them on, uh, the stack versus, um, having a pointer to them and not actually knowing what they are other than they it's a foo pointer.
Which means you don't need the definition and dec of foo you only need to know that foo exists. Something called foo exists. Okay, fine. That I'll, the linker will sort this out. So that was our, our, our idea. It was a lot of fun because I had to write a full C++ like parser for C++ 98, which was rather tricky, but a lot of yeah, fun. Some, some definition of fun. And in fact, um, I think maybe we mentioned this when we had Claire Macrae on, but, um, like some of the biggest tests in there were essentially giant acceptance tests of huge bits of C++ that I'd found off of the internet and then pasted in and run the program on, and then dumped the sort of internal state saying like, this is what we think we parsed.
And does it make sense or not, uh, more of a regression than anything else, but, um, yeah, the idea was you hold it in a database and then you can do all these clever things with it. And the, the, the, that means refactoring is, is trivial for like renaming a function is, well, I just change its name in the table. That's the end of it. There's nothing else happens after that, when I re-render it out. The other thing, and this is another sort of motivating factor, as well as, um, the benefits of being able to like, have a fast compile where you just defer everything, um, to the compiler in different ways, based on Lakos' ideas versus, um, you know, having to make those decisions yourself. Um, the other, um, thing was that you could display to the user, the code in the style that they cared about. Like you formatted it because you essentially always had to format it in order to show it because it was wasn't stored in the way that you're used to thinking about text. So, um, that was another sort of fringe benefit. You know, you, there were no more arguments about what the code style was because the code style was your own code style
Tabs versus spaces and where the curly braces go and...
Exactly. All those holy wars. So it was an interesting idea. Um, we got as far as building the front end, which was parsing the code and bringing it into an internal database, this was like for essentially the import part and then the formatting and rendering part. And we were able to make a product that was just a formatter. And it was a pretty powerful formatter because unlike the other formatters around this is way before clang format and other things became, um, available. Uh, it actually had a parse tree. And so you could make any number of like decisions about no, no, I, my switch statements like this, unless there are four levels deep inside a function, in which case they, they get formatted different. Now, obviously why you'd want to do that? I don't know, but it was at least possible. So we had some, you know, we had a few customers, um, there was a, a large, uh, chip manufacturer bought, um, bought a big site license for it, which was like our biggest sale buy a long way.
And, and they liked it. They loved it. And presumably they used it to enforce a style. We had plugins for IDEs that liked similar to the ones that you described. And, um, and then we kind of ran outta money, uh, you know, had a secondary product, which was more like an analysis product that allowed you to see what the impact of changing a single line of a header file was things like that, where we could like graph it and go, well, if you change this actually bizarrely similar to what you you're talking about with the following, the dependency graph back for the test. And this is just saying like, what is the cost for editing this line of code? If it's in body of a CPP file, it is however long it takes to compile that CPP file, which is the length of that CPP file. Plus the transitive closure of all the things that includes, which is one cost. Whereas if I change error.h, Which has my big list of all the errors used in my entire program, and I add a new error, every single file in my entire code base, will rebuild as result of that. And so the cost of changing that is very, very high. Yes. And these were exactly the metrics that we were targeting, uh, bringing down by using Lakosian style technique.
Interesting.
But yeah, we never really made it that far. I mean, now I look back and, you know, I was obviously very proud of what we did, but you know, it was very naive what we were, we were trying to achieve and the way we're trying to achieve it. And mostly people love files, everything. Everyone understands a file, right.
Yeah. Yeah. That's a really interesting idea though. I, it, it kind of strikes me that it's like you, one of the side effects of that would be like almost blurring the line between like code formatting, refactoring and optimization. Right. All of those are basically like different variations on the same theme, which is I have this representation of the program that is abstract and I can spit it out to, uh, formatted, however you, like, I can spit it out to you refactored, however you like. Right. You know, we can inline functions, we can rename things. I can spit it out to you optimized, however you like, like I can do like certain changes to the code as I generate it, based on the platform that you're targeting. Or maybe even things like memory constraints, things like that. I mean, it sounds like you guys never really got to that point.
Never got that far, but that was the intention
Really interesting idea. Yeah. Yeah.
One of the, just to sort of give you an example of that, because if folks are not familiar with say C++ or C like languages, um, you can decide whether or not you're gonna uh, show the size of your object to everybody. If you, if you're gonna ever instantiate an object, if a piece of code depends on like making some, some objects, um, then the, at the point at which if you're using it by value, you need to know how big that is because the compiler needs to allocate that many bytes on the stack or reserve that much register space to put your object into. If however, you always have a pointer to that object. And some other piece of the code made to that object. The pointers are always eight bytes or four bytes as it was back in the day, right.
They're always the same size. And so now the code doesn't need to know anything other than like, I call a function, I get a pointer back. I own this pointer now. And I'm responsible for like cleaning it up afterwards, which now we have smart pointers to do for us, which is great, but effectively, I don't need to know the definition of that. It's a handle, it's a handle. Now, you know, like when you, in windows, you get an hwind, you don't have the window structure. If windows could change the window anytime, but you have some magic number. That means that's the instance I refer to. And so you can do that all over the shop in, in C++, but there's a trade off because now every time you use a function that needs that handle, the, the calling code has to completely delegate to the call, the called code to say, well, okay, you have to now work out what a window is.
And, and for example, if it was like, um, you know, get me the, the, the title bar of this window, it might be that the, actually that, that information is stored directly at the pointer that handle you got back, just literally points that the string, that corresponds to the window that you're talking about. And if you knew that, then your get me, the, the name of the window would just literally cast it to a char star and you've now got the name, but instead, now I have to make a function call that's then gonna do that and return back to me. And that's more expensive than knowing it. So there's a trade off there. This is a kind of automatic, um, thing that could potentially be done by a, uh, an, a system which knows how to make that trade off on when to make that trade off. Although it does have a lot more, uh, binary level, um, ramifications for like ABI, if you're calling other programs. But anyway, just as an example, and I realize now that's probably three minutes too long of talking about some of the more esoteric, uh, aspects of, of, of physical layout.
I can imagine that the two of you were, your, your brains were spinning on different possibilities that, um, you, you could have done if you, you know, once you, once you sort of have the system in place, um, one of the other, I don't know if you had this experience as well, but one of the other problems that I ran into, um, trying to sell developer tools, and I really empathized with this when I would talk to potential users and they would tell me like, yeah, so how does the licensing work?
Oh, man,
Do do I need to have like a special file in a special place. It wasn't quite as bad for, so that for the IDE plugins, because they were kind of used to that a little bit, but then we started getting like one of the things that we looked at and never wound up doing, and part of the reason was this, um, is integrating it into CI. Like people were like, oh, this is a really cool technology. Could I make my builds faster by just plugging in this and having like a pre-build step that said, well, you changed these files. I'm gonna run these tests. If those fail, there's no point in doing anything else. And we were like, yeah, that sounds great. And, and I had some conversations with, um, uh, Jeff Frederick, who I think worked at, oh gosh, what was the name of the company? Urbancode. They made a CI system. And I remember being at a conference talking to him about this. And he's like, yeah, you gotta be, you gotta think about how you, you want to like, handle the ergonomics around this. Cuz people get really cranky when it's like, you know, oh yeah, I I'm trying to set up a new CI server. And I can't cuz the stupid license file is in the wrong place. Oh my
Gosh. Oh my gosh. Yeah. That's a really, really valid point. Yes. We had a similar deal. Luckily us stuff was not in anything but an IDE.
So it
Was less of a problem. Although, you know, being able to format code as a part of a check-in or, or as part of the CI and say, Hey look, you didn't somehow you forgot to do it before you checked it in obviously would be a boon. But yeah, we had our own hand rolled licensing, uh, um, setup, which, you know, we could, we could wouldn't afford to use some third party license. Did you use a 3rd third party or did you make your own, did you even have one?
Well, we never, even, we never even, uh, got to the point with the CI stuff with the, um, with the, um, IDE stuff. We had a license file and I got some third party thing to do it. I don't even remember what it was.
See that was just too much fun to not have a crack at myself.
Yeah, yeah.
Was, was like doing the, the licensing thing. Uh,
I think, I think whatever we had was actually baked into our, um, our like point of sale, like, so we had like a, you know, a website where you could go and you could buy a license and they had something that they could use to generate a license key
So they could run like a program and, and
Yeah, you get
Your own unique exe that had the whatever thing baked into it. Yeah. Yeah. I don't remember how we did ours, but yeah, we, it was my first real, um, dalliance, with, uh, doing any kind of crypto-y type stuff where, you know, checking hashes and things, and then harking my own mind back to like when I used to crack, um, um, for purely explore educational purposes, uh, software for my, you know, Risc PC and BBC micro stuff. Yeah. Where, you know, you're like, well, you know, there's the, you, you have to put the obvious check in at the beginning, which is no invalid license, which only checks, you know, two thirds of the real license checks. And then somewhere much, much further on a long way away from the error message where anyone with half a brain is gonna search for again, sorry, my dog in the background is gonna winge, but anyone with half a brain who's trying to reverse engineer is gonna look for the error message and go, oh, there's the compare that says, you know, oh, invalid, okay.
Let's take the compare out. Horray I've got licensed copy now. And then of course, when you go to do the actual format or the 15th time that you do the format, you check one of the other pieces and you go, ah, this is still not a correct piece of software. So I'm gonna like prop up some other less obvious error until eventually get to the point where it's just like you just crash. And, and then people are left with the idea of like buggy software. Like no it's crashing on purpose. And, and we're trying to do it in a way that means that it's not obvious.
Yeah.
That it's crashing. And that was fun. And I remember we found on some warez site, we found a hooky copy of, uh, style manager. And I still have it on my hard disk where as like with, so I, I go through and see how they take it out. All of the, um, the copy protection stuff, copy protection laughable, really. But you know, at that point you go, fair enough. If you're prepared to spend all that much time effort, then I'm really, that's fine by me,
All yours, man, all yours
Happy times.
But yeah, that was one of the other things that I was really, um, I never really had a good answer to is sort of like, yeah, all this like DRM copy protection stuff is just, it sucks. I hate it. I hate that we have to do it. Like I don't even really want to do it, but that's just how it is.
Something needs to be, yes. You need to do token effort stuff. I mean, I think we've, we've talked about this before. I mean, there is, um, Intels C compiler. We've spoken about this or I can't remember who I was talking to on,
We talked about this on the train.
We did. Okay. I was just wondering, I was having a moment of like, did I talk to you about it? I mean, we haven't talked about it on the podcast, but we definitely talked about it on the train. Um, but yeah, Intel's own, um, C compiler has a license and, um, through conversations with their engineers, they've told me, uh, that really, they would be happy to give it away for free because it, obviously it showcases their own chips. It works best on their own CPUs. They understand how their CPUs work. And so they're able to schedule instructions and use make use of all sorts of clever bit pieces, much better than either GCC or clang because they have to be a bit more general. So that's all great. Um, and I'm like, well, but if it's proselytizing your own chip, why are you charging for it? He said, well, if we don't charge for it, then people don't see it as being valuable. I'm like, that's not how I think, because what I think is exactly, as you said, um, if I wanna even try out and sorry, Ben has been, is now over my shoulder, my, my dog is, is unfortunately, um, humping his, uh, his bed. Monty.
I wasn't gonna bring it up.
I, can't not because I'm looking at the screen. I can see it reflected. So I don't know.
He's having a fine time.
He's I mean, yeah.
Now he's staring out the window. Yeah.
He's having, do you need a cigarette? Oh, dear.
Very different kind of a podcast suddenly. I'm so sorry. Anyway, Intel, uh, compiles, you, you might want to try a out, but then if you need to install a license file in some magic place on the CI server in order to even check it in and see if have a branch build that works, it's immediately a turnoff. And like, I don't wanna have a, have to have a conversation maybe in the world of Docker these days is where people can run their own Docker images on some CI it's less of a problem cuz you can put the license in the Docker, but yeah, whatever it is, there's an unfortunate tension between developers, uh, sort of, uh, sensibilities around DRM, which at least in my experience, developers are generally against any kind of DRM again, because we think to ourselves, but it's just bytes and numbers and how, why, how could he charge for it despite that's how I pay my mortgage is by just bytes and numbers that I write for somebody else.
Yes. It's like, yes, of course you could do this with enough time. Is that worth your time? Like that's not, that's the thing, you know, here's, here's what I want to do. And I'm, I feel like this doesn't happen and I understand why it doesn't happen, but here's a, what I really want to have happen in the world of like developer tools and stuff like this is you're gonna gimme some money and I'm gonna give you some source code and that's gonna be the end of the deal. Right? Like why does that not happen? Well, I mean, the reason it doesn't happen is cause people don't trust other people's source code, right? It's like, you know, the sort of old thing of like, you know, reading code is a lot more painful than writing it, but you know, maybe that's the way maybe that's because the way that we write things is to not have them readable for general purposes. Like I would tell you it's a waste of time and money to write code that's intended to be sort of, um, digested by someone who doesn't have the context of the project.
Right. I was gonna say what I mean, there's definitely a level at which you are like, well, we know that we read source code more often than we actually write it because we're scrolling up and down it all the time. But then as you say, a huge amount of that is context dependent. You know, I I'm comfortable in all the code bases that I'm in because I know the, what everything should look and smell like, and I'm can see the, really a pattern straight away. But if you handed me the innards of the Intel compiler to me right now, I'd be like, well, this is, if, if it was intended as a something for me to look at, then it needs to be written in a very different way.
Exactly, exactly. And it's like, you know, it's almost like, it's almost like, um, you know, a book versus like your personal notes, right? Like, um, or you know, like a family calendar I think is actually a great metaphor for this. Like, you know, like you got the calendar on the wall and like, you know, 4:00 PM, Saturday "garage stuff", what is garage stuff? Well, if you're in the family, you know what garage stuff is. Yeah. But if I just hand you my calendar and I say, well, what am I, you know, what does this mean? Like, no one's gonna know. And, and that makes sense for a family calendar. And it makes sense for a project, right? If you have a company, if you have a team there's a certain amount of context that you can just kind of assume, and that makes everything much simpler. If you spell it all out, A you wind up writing a bunch of documentation, that's gonna be either costly to maintain or realistically won't be maintained.
Right. And it will just...
Um, or, you know, like, so I, I, I think that's, I think that's generally why people don't do it, but it almost seems like a little bit of a chicken and egg problem to me where it's like, because you don't write software this way, you never get to reuse it this way because who would like, you'd have to do it on per you'd have to do it with intention. You'd have to say like, I'm gonna write a whole bunch of code and then I'm writing it for an audience that doesn't really understand the context around it. But I'm, I'm gonna write it in a way that lets them read it and, and come up to speed.
So there, there are of things like you describe. So the unreal engine is shipped that way.
Oh, yeah. That's a, okay,
So you you've signed up for it
You, you, you know, you, you sign all of the disclaimers and promise that you're not gonna leak it around whatever, at least if you're gonna, like I've done as a sort of open source, uh, contributor, and you get access to their GitHub repo, you git clone it and you, the equivalent of make, or you follow the instructions, you wait two and a half million years for it to actually compile while you convection heat your house with the exhaust of your computer. And then you end up with, you know, a funny little game that you can move around, but you've got the source code to the whole engine and the editor and everything that goes with it. And then you're like off you go, I don't know that's about as far as I got because um, life was too short after that.
It's just a bunch of code, basically? Yeah. Right.
Um, but I always intended to go back and look at more of it, but I, yeah, it was. So I dunno how readable the rest of the code is, but I guess also maybe they've reached this point, um, where the code base is so large, that it is worth for only for internal reasons, them making this sort of like slightly more readable, documented code. Yeah.
It's possible. Yeah.
I also wonder how, um, things like Pixar's RenderMan are distributed. I don't know if that is distributed as source, but like if you get a license to buy, uh, if you're like your some movie studio and all you get is like render.exe, you might be a little bit worried, that that's it. You know, you want some kind of, um, protection, if nothing else, if they, you know, if Pixar goes bust or whatever, then you can still render your movie.
Oh yeah.
So I wonder about that. And I, you know, for example, I know that also Google had a source license for the perforce version tracking system so that they could basically reimplement it for their own needs because they had to scale beyond what it could do. And, and so obviously these things are possible, whether or not they are common. I mean, obviously they're not that common cuz most of us consume shrink wrap software, certainly where we are sitting. Right. And the smallish companies that we work for, it's like, yeah, buy the shrink wrap box. When was the last time you actually bought a shrimp shrink, wrapped box? I can't, I can't remember myself, but a long, long while, but I still call it.
Oh, software?
Yeah. You know, windows 95 or something?
Many. I guess when I was building my most recent gaming PC, I got a copy of Widows from Amazon and they sent me a DVD for some reason.
Oh, so you got a box. I just need the character code or whatever to type in.
Yeah. I mean, I think it was just like a cardboard wrapper around the
Right. You
Know, the sleeve around the
It wasn't the beautiful boxes that we used to get. You know, you take the cell-a-phone off cell-a-phone. Cellophane The cell phone. That's what Italians call mobile phones. Yeah. I'm sorry to, if we have an Italian listener. I'm very sorry. That was. Oh dear.
Oh my God. Yeah, no, I don't remember the last time I actually unwrapped one of those and I know totally the boxes that you're talking about about. Yeah. Um, but I, I remember as a teenager, you know, wandering the, the aisles of Best Buy, right. Looking at different games to, to get, you know, I've got $50 in my pocket and I'm like I should get a new game.
New game and
Ooo this one looks cool. This one looks cool. You know.
Sound blaster compatible. Thank God for that.
Yes, exactly.
Yes. Right. So, alright. Complete non-sequitor I, we need to finish up because we're, we're running low on time, but um, on that, that subject, I just replayed Day of the Tentacle. I dunno if you ever played any of those, um, original Lucas film.
I played some of those. I played some of those games. I didn't play Day of the Tentacle.
It's just so great. Yeah. It's there just so much fun, but yeah, it has, it definitely has that memory. Those were the kind of games I last remembered like picking those big, chunky boxes before everything was just, you know, CDs was uh, yeah. You know, Secret of Monkey Island and uh, Day of the Tentacle. Sam and Max Hit The Road.
That I played. Yes, max.
I think, I think they've been remake of that as well, but I had a very enjoyable weekend playing through Day of the Tentacle again and it did hold up. I was glad to see.
That is cool. That is cool.
So that pretty much covers the uh, software development, uh, selling to developers is hard. The summary, everyone should go and play Day of the Tentacle
Instead of building a software development tools company go play Day of the Tentacle.
Exactly.
You'll have a lot more fun and you'll make the same amount of money.
Well, and on that bombshell, I think, uh, we'll call it a day. Bye mate.
See you later.