I thought I would write some notes on some old “networking” tech that I worked on in the early 80s. I have “networking” in quotes because it isn’t really like what you would call a modern network, this was more about sharing particular devices but in some sense the things we’re going to talk about are “switches”. This is the Microshare line of products. I’m doing this all from memory so there’s some chance I have some of the details wrong but I’m confident this is substantially correct.

The general need here was to be able to share Commodore peripherals, especially disk drives, but also printers. These are things like the CBM 2040 floppy disk drive and later the 4040, 8050, and 8250. These devices were not cheap and so when setting up a classroom it was highly desirable to have a single device shared between a bank of computers. Unlike modern computers, the Commodore PET did not use its disk constantly for things like virtual memory and so for the most part the drives were idle; sharing was very reasonable. You could even leave important floppies (or copies anyway) in the drive so they were handy for students. …

This is obviously an opinion piece and a bit of nostalgia but, despite that, Win95 being the most important OS ever is not a claim that I make lightly. I’m a student of this space and there are many great contenders but, in my opinion, none had as dramatic an effect on the entire industry, and certainly none as quickly as Win95.

So, what am I talking about? Let’s set some context:

1. In 1995, PCs outnumbered all other computers at roughly 80M units, growing to roughly 90M by 1998. I think a case can be made that this out numbers all other general purpose computing devices combined (but I have no reference for that). For instance, by comparison, Mac sales in 2002 (the oldest number I could readily find), were only 3.1M. …

So the usual caveats apply: In the interest of brevity, what I’m going to write is only approximately correct, so do take this all with a grain of salt.

So here I’m talking about Fail-fast in the context of coding, not experimentation. This is the idea that there are many cases where your program should just abort rather than trying to recover. Classic examples of this sort of thing include “exit() or abort() on out of memory” or “out of disk space”. That sort of thing.

People are often surprised by this approach, having been trained to (e.g.) guard every malloc() but you can actually get a fairly robust system on the fail-fast plan with maybe less work overall. …

I wrote this because my friend Laura did some tweets on “SCM” [Source Control Manager, “scum”] and it turned into a little bit of history of the late 80s and early/mid 90s.

Near as I can tell SCM went nowhere. I learned what I did about it from a series of demos that we were given back when I worked in languages at MS. It was totally unlike SLM (“Slime”, or for SLM 1.5, “Slime and a half”). Let me say a few things about SLM first.

• SLM works with just files, so you can stand up a repo in a few seconds flat. …

I’ve heard people say things like they want to create a “performance first” organization but frankly I think starting from those words is already wrong. There are many success factors in software systems, performance is one of them, but you can’t win by prioritizing just performance — you need all the other factors to be there as well. One of my favorite quips is “It’s easy to make it fast if it doesn’t have to work” which is my goofy way of saying “Dude, clearly just perf isn’t enough” or “You don’t get points for speed if it sucks” or whatever. So yeah, you need all the things. And so, while what follows is centered around performance, actually it could be about (e.g.) …

[This is a dusted off article from 8/31/2007 which I didn’t want to lose so I’m moving it to Medium where it will hopefully stay alive. The original was on my MSDN blog. It’s the same article with some light corrections]

Introduction and Disclaimer

Regular readers of my blog are already familiar with my goal to provide brief and useful information that is approximately correct and that illustrates some key truths. Most of the time my articles are not authoritative and that is especially true in this case. I am certainly not an Official Microsoft Authority on databases and data systems, I just have a good bit of experience in that area, and I wanted to convey some things I learned that I thought were important, and that I’ve never seen assembled as a whole before, so I’ve written this article. This article uses “Linq to SQL” for its examples but I think it is actually more broadly applicable, with due caution. …

Getting the very best results is rarely as economical as we might wish. Productivity is an important concern, and there are often trade-offs to be had. With regard to engineering effort, there’s pretty good thinking on this generally and when I taught classes in this I used a system like this one:

For every “feature” you’re building think about what letter grade it needs to get with rough definitions like these…

• A+ — the best the hardware is capable of, no compromises, “maximum effort” (you can almost never afford this)
• Fuzzy stuff in between
• D — if it was any worse you simply couldn’t use it; this is only for stuff that’s not very important and happens not very often. …

Sometimes people ask why it’s so important for programs to be small. With programs made for your phone of course a couple of important aspects are how long it will take to download the code and how much space it will take on disk to be present. Those are both important, but actually binary size is a good yardstick for many other kinds of efficiencies, or inefficiencies that can linger in your code.

Let’s first start by talking about loading your program, or “cold start” as it’s usually called. And as always I’m going to give some approximately correct numbers to help motivate the discussion without getting too buried in all the ways your mileage may vary. …