I had a game company in '82 for Commodore VIC-20 and C-64 home computers. We sold our games on cassette tape, had to contract printers for the cassette labels and the package sleeves, and then myself and my partner heat sealed each one by hand. One of our games had a memory issue, as the memory was re-organized between two manufacturing runs of the VIC-20, so we printed the series of PEEKS and POOKS necessary to get the game to run after loading in our magazine ads - and it did not appear to impact sales. Made some money, but being "dumb kids" (17 years old) we went bankrupt. That experience gave me focus during my undergrad.
ZX81 game programmer here. A game shop said they'd stock it, but I was too exhausted from finishing the game to deal with the "business side" of arranging duplicating tapes, professional labels etc. (I didn't realize you could just do them one-by-one, by hand. Start small.) But it did get me a programming job at a games company (the interviewer later told me he didn't think a game that good was even possible on a ZX81).
I think it was easier at that time to get a good, pretty complete picture of underlying hardware and software. A kid could do that. Many of us did :-P. It was an incomplete picture, because it was not including, say, algorithms used in BIOS/OS. Or, say physics of the underlying semiconductor technology. But from the engineering standpoint, yes. It was a full picture. Think this way, a complete IBM PC manual was a very readable, pretty thin book which included a complete description of 8086 processor, hardware and APIs (BIOS). And K&R was another pretty thin book, which gave enough to start hacking away and get you pretty close to the point when you could develop code that is genuinely useful to someone! And with that comes an opportunity to start actually selling that genuinely useful software (and hardware).
I think now, it is maybe easier to get started writing something, but it is incredibly difficult, if not impossible to get the complete picture. Many components are designed using technologies that require PhD level understanding - basically being current with modern research in computer science. And that comes with a very heavy baggage of scientific notation and ability to work with research papers. Definitely not approachable by 8-year-olds :-/ And I'm not sure if one just can be a good engineer without having that kind of understanding of underlying technologies. Sorry kids :(
Similarly, the ebook by Bob Pape about how he developed the ZX Spectrum version of R-Type is a very interesting document on how computer games were developed at the time and how game companies worked.
When you mentioned Jordan Mechner, memories of me and my father playing Prince of Persia came into my mind :) It is arguably one of the best games ever!
Also a point that is to be noted is, back then every game developer was a kind of indie.
Possibly more interesting... start the video from the beginning and they're talking about software patents. The same points were being brought up then as now.
I think they're actually talking about copyright. Apple famously lost a big copyright infringement "look and feel" case against Microsoft, partially on the grounds that software can't be copyrighted. This was one of the catalysts for the switch to patents as a means of defending software novelty.
Another interesting case during roughly the same period was Lotus vs. Borland in which, in this case, the court basically found that it was OK to imitate another program's menu layout and contents. http://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_Int....
My uncle was friends with some guys who set up a small game shop in Michigan in... 1982? They had some text adventure games, and were branching out in to video games for C64 at that time. They were called Aardvark Software in... White Lake Township, I think. My dad and uncle took me out to meet them at their 'office' - a small house/shack with a whole mess of computers. I don't remember much of the visit, but the idea that people could just sit around and work on games was inspiring, as run down as the house was ;)
IIRC there was a cassette tape duplication machine, but that may just be a foggy memory. I seem to remember a lot of cassettes in plastic baggies, and there were some 5.25" floppy disks in baggies as well.
Right around that time they put out 'Pacacuda', a PacMan variation with a barracuda/fish angle. My uncle was angling to have them call it 'Fish Lips', but they stuck with Pacacuda.
> Now in those days when you almost never sent out patch disks; generally you had to wait 6-8 months to ship a new version and you had to charge the customer for the update. Trapeze only needed one floppy but Deltagraph shipped on something like 10 disks. Paying for hundreds of thousands of disks is expensive; add to that printing of manual updates and boxes and shipping and you never did this casually. So the version we sent to the duplicators had to be perfect and live for months. I was always the final arbiter of what shipped. Thankfully we never had an issue with either 4 versions of Trapeze or the 5 of Deltagraph.
Shipping ROMs was the same deal. You wrote an OS, or a game, and tested the crap out of it. Then you sent out for mask ROMs and waited like six weeks for them to come back, and you hoped that they worked.
My office mate was told to make three versions of the game she worked on, each ORG'd at a different address so that manufacturing could pick whichever configuration was cheaper to make. Q/A was able to test two of those, but didn't have the special test cartridge needed to test the third, and guess which one had a fatal error and didn't boot? $250K of ROMs wound up in the dump (next to E.T., for all I know).
We wrote a boot ROM for a consumer computer. We were pretty sure it worked, but again we lacked some hardware and had to ship the final version out for mask ROMs without testing. They came back and worked. I told the hardware test manager what we'd done, and it was the first time I'd ever seen someone turn white.
Newton was the same deal (except that we had a way to patch the ROMs through a snazzy jump table system).
Now imagine if this was not "really impressive", but the norm today. Things would be so much better if we'd no longer need constant patches-upon-patches to fix what should've been fixed before release (while sometimes introducing new bugs), and users would spend more time doing useful work with the software instead of fighting it.
As the article notes, this is all possible with a minimal of tools and resources, so I think it's all a matter of mentality. Today we have access to so much information and tools, machines that are several orders of magnitude more powerful, huge bureaucracies of development practices for assuring quality, "safer" programming languages, and yet... it feels to me like software quality today hasn't really improved much if at all.
No. Errors in production have become more common because they have become much more tolerable (cheaper and faster to fix), and (apart from the massively increased feature scope and complexity of the environment) tolerating errors (that are soon fixed) gets you more features and shorter time-to-market.
Users value software that does more and is available now more than software that is perfect, but does less and comes out next year.
Yes. Basically we've shifted from emphasizing high MBTF to low MTTR. Especially with techniques like continuous deployment and gradual rollout, it's relatively painless for all involved.
And I think it's necessary. The explosion in software complexity, platform complexity, and platform variation means that trying for absolute perfection is much more expensive than it was. And that's before we even look at the much higher requirements volatility.
Mean Time To Repair. In other words, parent poster is saying that we tolerate more failures because we can fix them quickly.
I basically agree although it's obviously a vast oversimplification. I'd probably argue that we tend to have architectures that are often more resilient as well.
Except back then, you had your app running on the machine all by itself. And there was no need for security -- if putting in a magic input string caused some weird behavior, well, "don't do that". Whereas today that would be considered a security bug (even if your app isn't directly used by non-trusted sources, it could be in a deep toolchain used by some other app).
Not to mention, that when you shipped for an Atari 800, or Vic 20, you only had to test against that -- not an Atari 800 with a Nvidia Graphics chip, vs. a Matrix chip, etc.
What is sad is that the Morris worm dates back to late 1988 when MS was starting the development of OS/2 2.0 and NT OS/2. Yea, I am talking about the decision to use a flat address space (instead of segmented) with default image base addresses which was what made buffer overflow etc exploits really popular.
Modern software is a lot more complex than it used to be, with vastly more functionality. In terms of games, as just one example, the difference between the '80s and today is extreme. There's more coding and graphics work in just a tiny little throwaway piece of a world in modern games than there were in many '80s games.
Also, the level of bugs that are tolerable if you have no method for patching are different than if you do. Super Mario World, for example, has a number of bugs that are now quite well known, but those bugs are in general small enough to not warrant recalling the product so we still tend to think of the game as "perfect".
I feel like I missed out on the personal computer marketplace of the 80s/90s -- I had a Mac in 1990, but I got VMS and UNIX shells slightly before, so the Mac was really just a terminal (and at one point, I actually replaced it with a dumb terminal to do dialup since the screen was bigger, and then a 386 running 386BSD.
MUDs, stuff like XTrek, and the general requirement that things be non-commercial (to fit within NSFnet guidelines) was really different from the small-computer marketplace happening at the same time. There were definitely commercial packages, but my only real contact with that kind of stuff was commercial OS and vendor support contracts for big machines I had shared accounts on (e.g. Sun support contracts, and some packages being harder to get than others).
There was a period in the mid to late 1990s when it was an NT vs. Linux (well, UNIX in general, but mostly Linux by then) question -- NT 3.51 and 4.0 became viable. But, before that, the high-end timeshare world and the small-computer world were totally separate.
Similar to my experience. After having Uni shell access, I never understood the fuss of PCs. Tried out NT early on, was profoundly disappointed with its CLI tools, found Linux, never looked back.
The whole dial-up BBS era sort of passed me by -- I'd already had a taste of the Internet by then. In particular I missed the gopher / archie / veronica days. FTP -> HTTP for me.
As far as selling the biggest difference between now and then was back then software could only be shipped on floppy disks, so it was more like manufacturing, warehousing, and shipping physical merchandise.
Right. Although it wouldn't have been practical for software that filled multiple floppies, by around the late eighties it was pretty normal to have drivers and the like available through BBSs. I don't recall most companies operating their own systems but this type of software was widely available through private BBSs--whether totally legally or otherwise. (It did seem to take a while for many companies to realize that they probably shouldn't make it hard for their customers to obtain the software needed to use the product they sold.)
Shareware was also widely available on BBSs by around that time although it was also distributed on floppies at Computer shows and the like. When I had a small shareware company starting in the mid-eighties the process of taking orders was still very manual--most orders came by mail with a check and I sent back a floppy (which I reproduced myself) in a mailer with or without hardcopy docs depending upon if those had been ordered or not.
When we talk about making programming accessible to kids (or anyone new to it), I think of how selling and distributing software is different now than it used to be. Webapps and app stores make it easy to reach thousands or millions of customers, but what's the modern equivalent of a kid writing something in BASIC (or VB) and selling a few copies to friends, parents, local businesses, etc.?
Some kind of Ruby/Tk/SQLite bundle that produced a universal executable (say, mac, win, lin) would be cool, I think.
I cut my teeth writing websites using PHP and MySQL, mostly around a computer game I used to play. I got a few thousand hits in the first year and plenty of nice email so I kept going with it and eventually studied software development at uni and have spent the last 15 years working as a developer.
I actually knew a heap of kids around my age (I started at around 15) who I met through my website who did the same thing and many of them also became developers or designers too.
I don't know if the web is still as accessible as it was back then when you could get free hosting somewhere like Geocities if you were just starting out, but I think HTML and javascript are a really nice starting point because it's fairly easy to cobble together something that works and you can get a fairly long way just by trying to make whatever you built just that little bit better. The web is also a good place to learn about the web, particularly since in those days it was easy to view source on anything I saw that I didn't know how to do myself.
Yeah, I spent hours copying these programs to the computer. I remember one huge machine program listing (I think it was for a graphics program) that had a line with a wrong checksum printed. Without a correct checksum, you couldn't go on typing. So I changed one of the hex values until the line passed... The final program was kinda buggy but I never knew whether my change was responsible for one of the bugs or not.
I'd argue that the AppStore model is several steps backward from shareware, websites, etc. Yes, you get cheap updates, but you're once again beholden to the retailer in order to get your product noticed, it's harder to create apps that deal with social commentary, you've once again got to calculate in retailer overhead in determining a product price, etc. Hell, the bad old days let you include a catalog in with your product so customers could purchase stuff directly from you without the retailers demanding their pound of flesh. So no, the AppStore is not a game changer by any means.
The game has changed fundamentally for both producer and consumer, and the AppStore (powered by mobile device success) is the biggest winner in exploiting the change. The level of its success puts it in a position of influencing/controlling the underlying economics and has forced big changes to the business models of anyone seeking access to the market it provides. I can't really agree that it is worse than other market channels, since the market landscape is fundamentally different from a few years ago, but having been a producer and consumer of software products over a long period, I feel like it is a net loss for competitive (and quality) software development, and a soft win for consumers in some ways, but as you point out, the control and opportunity trade-offs on the production side relative to the bad old days are a pain, and may result in compromises for the consumer.
I sold a shareware title in the mid 90's. My distribution model was pretty darn simple: There was a place somewhere in Indiana with a printed catalog of shareware titles. I sent them a disk, and they added me to their catalog.
I decided not to charge for updates, as I figured that I was lucky enough to get any money at all.
I think internet was the real game changer. Once bandwidth got good enough for downloading software, it got easier to sell and patch anything. I can't imagine living 7-8 months without patches.
AppStore is definitely a step up, but it may be too crowded.
I agree. Before any "AppStore", there were countless avenues to getting software. Plus, software finally got online "profiles" so to speak that allowed people to learn more about it before purchasing/downloading.
Just prior to doing my first internet project for BT back in 94 I spent a year working on a Oracle forms project to manage the UK's SMDS network.
When it came to delivery you had to install in the correct order 15-16 separate 3.5 inch floppy disks - before you could install our forms application :-) took me and the other developer 3 day to install the 6 or so pilot users -
We also had to take up a spare server at the last minute as they had neglected to order the hardware - luckily they did have a network so the network hardware we also brought as insurance wasn't needed.
Back in the 80's I also ran the production side of our apple and pet software biz - I recall having to stay late to ring up Microsoft (in new mexico) about a very strange bug in USD pascal on apple hardware.
> I can't imagine living 7-8 months without patches.
For actually important systems (I'm thinking of things like Banyan VINES), patches would be shipped as soon as possible - but this was reasonable, we were _paying_ for that level of support.
