Hacker News Reader

Comment by eps | Hacker News Reader

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

  We never had an issue (with a shipped version)

Damn, this is really impressive.

View on HN

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

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.

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.

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.

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.

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.

What users ask for is not necessarily what they want. A good designer listens to what users say, but doesn't follow them to the letter.

('Twas the night before Christmas variation on this topic: http://www.daclarke.org/Humour/sware-engr.html)

They do, but they also want things simpler. Reconciling these conflicting demands is the trick.

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.

MTTR?

Mean Time To Repair.

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.

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

Reply on news.ycombinator.com