Live data from Hacker News

What Writing and Selling Software Was Like in the 80s

thecodist.com

31–40 of 61 posts

Re: What Writing and Selling Software Was Like in the 80s

#31

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…

Maybe the VIC-20 was quirky, but the Pet used PEEKs and POKEs. Oh, the memories (32Kb fully loaded)

Re: What Writing and Selling Software Was Like in the 80s

#32
post #27

Earlier quoted context omitted.

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…

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…

Users value software that works. The driving forces behind featuritis have very little to do with what users want.

Re: What Writing and Selling Software Was Like in the 80s

#33
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 :(

Re: What Writing and Selling Software Was Like in the 80s

#34

Shareware was a great increment from the publisher model. And then of course, AppStore is the real game changer.

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 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.

Re: What Writing and Selling Software Was Like in the 80s

#35
post #27

Earlier quoted context omitted.

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…

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…

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.

Re: What Writing and Selling Software Was Like in the 80s

#36

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…

If you don't mind me asking, what did you do after undergrad?

Re: What Writing and Selling Software Was Like in the 80s

#37
post #32
post #27

Earlier quoted context omitted.

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…

Users value software that works. The driving forces behind featuritis have very little to do with what users want.

Users come up with feature requests all the time. Featuritis is exactly what the users ask for.

Re: What Writing and Selling Software Was Like in the 80s

#38
post #32
post #27

Earlier quoted context omitted.

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…

Users value software that works. The driving forces behind featuritis have very little to do with what users want.

Users come up with feature requests all the time. Featuritis is exactly what the users ask for.

Re: What Writing and Selling Software Was Like in the 80s

#39

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…

That sounds way professional!

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.

Re: What Writing and Selling Software Was Like in the 80s

#40
post #35
post #27

Earlier quoted context omitted.

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…

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 hi…

MTTR?
Post reply on HN