What Writing and Selling Software Was Like in the 80s(thecodist.com) |
What Writing and Selling Software Was Like in the 80s(thecodist.com) |
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).
Business side is important. Good to learn at 15.
Every time I read one I come away energized with the same passion for creating something unique.
Edit for link: http://jordanmechner.com/ebook/
It is freely available at his Web site http://bizzley.imbahost.com/
Also a point that is to be noted is, back then every game developer was a kind of indie.
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 :(
But yes. Good video! Cheers!
http://en.wikipedia.org/wiki/Apple_Computer%2C_Inc._v._Micro....
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.
Not sure what happened to them after that.
We never had an issue (with a shipped version)
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.
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.
John Carmack, et al. Had to be quite creative on the programming side of things.
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.
Some kind of Ruby/Tk/SQLite bundle that produced a universal executable (say, mac, win, lin) would be cool, I think.
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.
So you could be pretty sure that your programs worked afterwards.
Nothing beat the feeling to type a program and then finding out that the game sucked.
But in one of the magazines there was a drum computer for the C64, which was pretty cool (forgot its name).
Page 159 is one of the later reviews. Interesting to see you couldn't search for anything back then either without seeing ads for porn.
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).
In fact, I think the classic Mac OS used this model too.
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.
Users value software that does more and is available now more than software that is perfect, but does less and comes out next year.
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.
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 decided not to charge for updates, as I figured that I was lucky enough to get any money at all.
AppStore is definitely a step up, but it may be too crowded.
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.
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.
The internet drives the need for patches, because suddenly bugs are a security risk rather than a rare inconvenience.
('Twas the night before Christmas variation on this topic: http://www.daclarke.org/Humour/sware-engr.html)
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.
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.