Two's Complement - Terrible Business Ideas

Episode Date: April 16, 2022

Matt and Ben both recall their prior adventures founding companies that sold tools for software developers. What's the best approach to this business? Go play a nice video game instead.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. How are 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 going to do. A huge agenda point, lots of bullet points down here that we're going to hit every single one of and not at all we're just going to 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 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 about some of the things that we've talked about before. And in passing, we've mentioned the fact that I briefly ran a small C++ tools company. And one of the examples we have in our document of ideas is writing tools is difficult and or doesn't make money.

And I figured we should talk about that because I certainly have some firsthand experience. And I don't know to what extent you have any. Have you ever built developer tools? Oh, yes. So this is another situation, just like when 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 experience to you in that it didn't go great. How do I not know this? Yeah, so this was...

So do you want me to explain my first? You explain your situation, yeah, because I always talk about me. Not true, but yeah very 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 think i wound up doing like most open source projects it's like you know 99 one person and one percent 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 what infinitest does is it inspects the bytecode of the class files that whatever compiler or editor that you're using generates. 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 it turns out that's actually not that big of a deal. But it would analyze the dependencies between the files that you change to figure out the minimum set of tests to run. And the idea behind this tool is that if you're working in a very large Java code base with 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 multiple threads, which additionally helped speed it up.

And so the idea basically behind this tool is that 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, Kent Beck was building a tool called JUnitMax. And JUnitMax was kind of attempting to solve a similar problem, but in a much different, and I have to give him credit, much simpler way, which is he had based it off of some research.

I'm 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 anyway, Kent basically had seen and had discovered through research that 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, are slower and then there's sort of this power law curve. You've not seen the project that I'm working on right now. 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 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 i was gonna say the 2080 theory but like it's more like the 99 one yeah theory yeah exactly i mean obviously

that means that there is a hole in your testing that maybe you x you are at least for like the interactive case when you're just fiddling around and saying i'm changing this and i'm changing that and you need 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 reese 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.

And so Kent and I were kind of doing the same thing at the same time in the same space. And the way I was doing it was 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 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 because of the financial crisis. So 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. So we got all the authors of the open source tool together and sort of formed this company and tried to sell it. And I think we maybe sold a dozen copies, maybe two dozen copies of this thing. But this was an open source project. That we had closed. You closed, I see,

because you had everybody's buying at that point. I've never really thought about how that is achievable. You know, I know how software open source projects can be re-licensed. And I suppose this is just 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,

now it's not. We don't have to keep that. Yeah, I mean, the open source version was we move on right right now it's not we we don't have to keep that yeah yeah i mean the open source version was still out there but this is like oh we're going to turn these into like proper intellij and eclipse plugins and we're going to put a lot of work into making the ergonomics really nice because you know the thing that was open source was basically like a really thin wrapper around the dependency algorithm yeah right which is the cool bit of tech that it is the cool bit of cool idea yes 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 prototype basically which is yeah or a sort of more of a diy thing like most open source projects tend to be although 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 obvious how to use and i'm certainly i'm trying to learn how to make that more the case for my own open source 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 improving works yeah yeah um and, you know, we had, you know, a little board of about four people. We would basically, like, get developer time from some of the consultants that were at the consultancy at, like, a reduced rate and bill it back to the product company. Got it. And, you know, a lot of my, 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 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 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 those people don't have any money to buy it so you wind up not selling it exactly yeah yeah you realize that 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 because

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, 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 f fiddling uh it's you know hey follow the dependency tree backwards and then find the tests that are dependent on that that's great right you're 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, pretty much anything is achievable. But like, you know, I'm not going to, I'm probably not going to write my own IDE. So I think I can square buying an IDE because it makes me that much more profitable as a as an individual even you know i actually buy

most ideas 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 we'll get back to this a source code formatter you know i could write my own source code formatter 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 a secondary part but then the other yeah as you say the thing you identified is that really the people who control the purse strings are in a different org often or at least a couple of levels above the your your intended customer direct customer and 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 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, I don't know if we've covered naming is hard, but it is the single most difficult thing to do. So the story, and we may have talked about this before, I forget, but the short version is my friend, Nicky Hemmings, and I were working together at Argonaut Games, where we were working on all sorts of Xbox and PlayStation 2 titles we were exposed to giant messes of huge sprawling C++ code bases and while down the pub

we kind of kicked around the idea that maybe we're doing the development of large C++ projects wrong we had just read John Lakos's large-scale C++ design book, and it was a very pragmatic solution to how do you lay your project out physically, how do you decide which things go in header files, which things go in CPP files, how do you decide which subdirectories 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- hand with something like with like c++ and we 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

by rather not Jerry 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 tape in tables so um the ide such as it is understands the fundamental connectedness of a lot of all the things you know you're 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 call printf and it's an invocation of that so 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 all right 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 going to inline and output the text of that function or this is where i'm just going to refer to it and say well the linker will provide this later on or this is where i'm going to put it in a header file on all these tricks that lacoste's book was talking about when you decide to allocate objects versus put them on the stack versus um having a pointer to them and not actually knowing what they are other than they it's a foo pointer uh which means you don't need the definition and deck of foo you only need to know that Foo exists. Something called Foo exists. Okay, fine.

The linker will sort this out. So that was our idea. It was a lot of fun because I had to write a full C++ parser for C++98, which was rather tricky. A lot of fun. Some definition of fun. Yes.

And in fact, i think maybe we mentioned this when we had claire mccray on but um like some of the biggest tests in there were essentially giant acceptance tests of huge bits of c++ code that i'd found off of the internet and then paste it in and run the program on and then dump the sort of internal state saying like this is what we think we parsed and does it make sense or not? More of a regression than anything else. But yeah, the idea was you hold it in a database and then you can do all these clever things with it.

And that means refactoring is trivial for like renaming a function is while 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 lakehouse's 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 to you because it wasn't stored in the way that you're used to thinking about text. So that was another sort of fringe benefit. You know, 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. Exactly.

All those holy wars. So it was an interesting idea. 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 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 get formatted different 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 large chip manufacturer bought um bought a big site license for it which was like our biggest sale by a long way and and they liked it they loved it presumably they infused it to enforce a style we had plugins for ids that like similar to the ones that you described. And then we kind of ran out of money. You know, we 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 actually bizarrely similar to what you're you're talking about with the following the dependency graph back for the test in this instance the same like what is the cost for editing this line of code right if it's in the 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 things it 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 a result of that. And so the cost of changing that is very, very high. And these are exactly the metrics that we were targeting, bringing down by using Lycosian-style techniques. 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 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. It kind of strikes me that it's like you,

one of the side effects of that would be almost blurring the line between code formatting, refactoring, and optimization. All of those are basically 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 you formatted however you like. I can spit it out to you refactored however you like. 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 or things like that. Right, right. I mean, it sounds like you guys never really got to that point. Never got that far, no. But that was the intention. Really interesting idea, yeah.

Just to sort of give you an example of that, because if folks are not familiar with, say, C++ or C-like languages, you can decide whether or not you're going to show the size of your object to everybody. If you're going to ever instantiate an object, if a piece of code depends on making some object, then 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 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 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, in Windows, you get an HWIND.

You don't have the window structure. If Windows could change the window at any time, 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 C++. But there's a tradeoff because now every time you use a function that needs that handle, the calling code has to completely delegate to the called code to say, well, okay, you have to now work out what a window is. And, for example, if it was like, you know, give me the title bar of this window, it might be that actually that information is stored directly at the pointer. That handle you got back just literally points at the string that corresponds to the window that you're talking about.

And if you knew that, then your get me 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 going to 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 a system which knows how to make that trade-off and when to make that trade-off although it does have a lot more binary level um ramifications for 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 aspects of physical layout. I can imagine that the two of you, your brains were spinning on different possibilities that you could have done once you sort of have the system in place. One of the other, I don't know if you had this experience as well 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 and a special place It wasn't quite as bad for the IDE plugins because they were kind of used to that a little bit. But then we started getting one of the things that we looked at and never wound up doing, and part of the reason was this, is integrating it into CI. People were like, oh, this is a really cool technology. Could I make my builds faster by just plugging in this

and having a pre-build step that said, well, you change these files, I'm going to run these tests. If those fail, there's no point in doing anything else. And we were like, yeah, that sounds great. And I had some conversations with Jeff Frederick, who I think worked at, oh gosh, what was the name of the company? Urban Code? They made a CI system and i remember being

at a conference talking to him about this and he's like yeah you got to be you got to think about how you you want to like handle the ergonomics around this because 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 because a 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, our stuff was not in anything but an IDE. So it was less of a problem, although being able to format code as a part of a check-in

or as part of the CI and say, hey, look, 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 couldn't afford to use some third-party license did you use a 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 got it it. I don't even remember what it was. That was just too much fun

to not have a crack at myself. Yeah. Was like doing the licensing thing. I think whatever we had was actually baked into our point of sale. So we had a website where you could go and you could buy a license and they had something that they could use to generate a license. So they could run like a program and,

and yeah. Yeah. Unique XC that had the, whatever thing right into it. Yeah. Yeah. I don't remember how we did ours, but yeah,

we, I, it was my first real dalliance with, with doing any kind of crypto 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 wrist pc and bbc micro stuff yeah where you know you're like well you know there's the 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 yeah dog in the background is gonna winch but anyone with half a brain who's trying to reverse engineer is gonna look for the error messaging oh there's the compare that says you know Oh invalid hey let's take a compare out hooray I've got a license copy now and then of course when you go to do the actual format or the 50 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 you get to the point where it's just like you just crash and then people are left with the idea of like it's buggy software like no it's crashing on purpose and we're like, no, it's crashing on purpose. And we're trying to do it in a way that means that it's not obvious. Yeah. And that was fun. And I remember we found on some WES site,

we found a hooky copy of Style Manager. And I still have it on my hard disk of where it's like. So I'll go through and see how they take it out, all of the copy protection stuff. Copy protection is laughable, really. But at that point, you go, fair enough. If you're prepared to spend all that much time and 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, I never really had a good answer to. It's sort of like, yeah, all this DRM copy protection stuff is just, it sucks. I hate it.

I hate that we have to do it. I don't even really want to do it, but that's 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 intel's c compiler have we 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. But yeah, Intel's own C compiler has a license. And through conversations with their engineers, they've told me that really they would be happy to give it away for free because 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 make use of all sorts of clever bits and 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 but but if it's proselytizing your own chip why are you charging for it well if we don't charge for it then people don't see it as being valuable all right that's not how i think because what i think is exactly as you said um if i want to even try out and sorry ben has been is now over my shoulder my my dog is is unfortunately um humping his uh bed monty i wasn't gonna bring it up i can't not because I'm looking at the screen and I can see it reflected I don't know he's having a fine time

I mean yeah now he's staring out the window do you need a cigarette oh dear very different kind of a podcast suddenly I'm so sorry anyway Intel you might want to try it out but then if you need to install a license file in some magic place on a ci server in order to even

check it in and see if have a branch build that works it's immediately a turn off and like i don't want to have a have to have a conversation maybe in the world of docker these days where people can run their own docker images on some ci it's less of a problem because 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 can you charge for it despite that's how i pay my but it's just bytes and numbers. And how could you 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 the thing. You know, here's what I want to do.

And I feel like this doesn't happen and I understand why it doesn't happen. But here's what I really want to have happen in the world of like developer tools and stuff like this is you're going to give me some money and i'm going to give you some source code and that's going to be the end of the deal right like why does that not happen well i mean the reason it doesn't happen is because 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 digested by someone who doesn't have the context of the project, right? Right. I was going to say, there's definitely a level at which you're 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'm comfortable in all the code bases that I'm in because I know what everything should look and smell like and I can see the familiar 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 it was intended as 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, a book versus like your personal notes, right? Like, or, you know, like a family calendar,

I think is actually a great metaphor for this. Oh, right. Like, you know, like you got the calendar on the wall and like, you know, 4 p.m. Saturday, garage stuff. What is garage stuff? Well, if you're in the family, you know what garage stuff is, right? But if I just hand you my calendar and I say, well, what does this mean? Like no one's going to know.

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 going to be either costly to maintain or realistically won't be maintained and it'll just be wrong right um or you know like so 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 you'd have to do it

with intention. You'd have to say I'm going to 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 going to write it in a way that lets them read it and come up to speed on it easier. There are examples of things

like you described. So the Unreal Engine is shipped that way that's okay so you you've signed up for it basically you you you know you you sign all the disclaimers and promise that you're not going to leak it around whatever at least if you're going to like i've done as a sort of open source uh contributor and you get access to their github repo you get clone it and you type 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 so i don't know i that's about as far as i got because um life was too short after that um but yeah right um but I always intended to go back and look at more of it but I yeah it was so I don't know 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.

Yeah. I also wonder how things like Pixar's render man are distributed. I don't know if that is distributed as source, but like if you get a license to buy, if you're like, you're, you're some movie studio and all you get is render.exe you might be a little bit worried

that that's it you want some kind of protection if nothing else if Pixar goes bust or whatever then you can still render your movie oh yeah so I wonder about that 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 so obviously these things are possible whether or not they are that common. I mean, obviously they're not that common because 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 software certainly where we are sitting right and the smallish companies that we work for it's like yeah buy 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 it's been a long long while but i still call it 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 Windows from Amazon, and they sent me a DVD for some reason. I'm like, I don't need any of this. I just need the... 22-character code or whatever to type in. Yeah. I mean, I think it was just like a cardboard wrapper around the sleeve around the DVD. The boxes that we used to get.

They'd take the cellophane off yeah cellophane i don't want to sell a cellophane that's what italians call mobile phones yeah i'm sorry to our 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. But I remember as a teenager, you know, wandering the aisles of Best Buy, looking at different games to get. You know, I've got $50 in my pocket, and I'm like, I should get a new game. A new game. This one looks cool.

This one looks cool, you know. Soundblaster compatible. Thank God for that. Yes, exactly. So right so all right complete non-secret and we need to finish up because we're running low on time but um on that subject i just replayed day of the tentacle i don't know if you ever played any of those um original lucas films 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 just so much fun. But yeah, it definitely has that memory.

Those were the kind of games I last remembered, like picking those big chunky boxes before everything was just CDs. It was Secret of Monkey Island and Day of the Temple. Salmon Max hit the road. That I played. Salmon Max, yeah.

I think they've done a read and make of that as well. But no, 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 software development. Selling to developers is hard.

The summary is everyone should go and play Day of the Tentacle. Instead of building a software development tools company, go 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 we'll call it a day bye mate see you later you've been listening to Two's Compliment a programming podcast

by Ben Rady and Matt Godbolt find the show transcript and notes at twoscompliment.org contact us on twitter at twoscp

that's at twoscp Contact us on Twitter at 2CP. That's at T-W-O-S-C-P. Theme music by Inverse Phase.