It was another cold and lonely day in the unforgiving city. Lucky for me though, I wasn’t in the city. I was in my office. Jumping and dodging the barrels that only life’s Donkey Kongs can throw at you. A Dame walked into the joint. I recognized her instantly, because she was my wife. She said I left the twist-tie off the bread again. And it was stale, baby. Stale as the case I had been kicking around in my head for the past two weeks.

Octal was missing. He hadn’t been seen in years, and everyone was sure he was dead. Who had killed him? There was no corpse, no family looking for him, and no one was interested in taking a pointless case like that. Except me. Pointless was my thing.

I apologized to the lady and went and made myself a stale sandwich. I wanted to find my coffee to wash it down, but there wasn’t time. There were eight things running through my head. And all of them were Octal.

Case 1: Dial “O” for Octal

The trail had gone cold on this one. Octal had been gone for decades. So I did some digging. Way back, back to early-1900s times. I found out that before Octal was around and things got all electronic-like, this other guy Decimal was working all the computer clubs. Nice guy, and people naturally got along with him. He had all the numbers working for him, and his work was high quality. Ten out of ten.

Trouble started when these new electronic joints started opening up. They were all run by the big boss, Binary. And Binary was one tough cookie. You either fit in with him, or you didn’t. It was all black and white with Binary, and Decimal didn’t get along with him from the start. Decimal would ask Binary for four bits to do his whole BCD routine, but then not end up not using ‘em all. Binary would say you gotta use less, but then Decimal would complain about his upper digits getting squeezed.

It wasn’t working out, and so Decimal got zeroed. I’d like to know more, but that’s a case even too cold for me to track down.

Colder than the coffee I forgot on the piano while making my stale sandwich.

So then Octal shows up on the scene. Binary likes him better, because he only has 8 Digits. And log-base-two of 8 is a whole number of bits, baby.

Octal gets the nod to start doing shows at the computer clubs, but people had to get used to his act. It was kinda strange. Seven plus One is Ten, and cockamamie things like that. He had to do a lot of explaining about what happened to the likes of 8 and 9.

Octal was a quirky guy. But boy, could he pack in those bits.

Story goes that Binary and Octal had a falling-out, because every one of Octal’s digits used three bits, and three was not a characteristic Binary liked to see in one of his employees. The boys in the backroom may have complained that Octal’s three-bit ways were causing a few math headaches for Binary’s operations.

Some people say it’s why Octal went missing. But the three-bit theory didn’t square with me. Because that would be nine. And who needs nine bits?

So I went looking for the last place anyone saw Octal. All of the joints he used to play had closed down decades ago. PDP-8, UNIVAC-1100, ICT-1900 — all long gone. Then it hit me. I needed to talk to the dame who replaced him.

Hexadecimal was a busy lady, but easy to find. Every cheap four-bit field in town had seen Hex come through. She was flamboyant. Larger than life. Regular numbers weren’t good enough for old Hexy, so she invented a few of her own. She didn’t play by the rules, and she seemed like someone who knew things about what happened to Octal.

I found her hanging around a popular place called The Debugger Arms. Seemed like a RISCy place, but I went in anyway.

Hexadecimal was something to see, with a nice set of digits that started at 0 and went all the way up to F. When I asked her about Octal, she told me she hadn’t seen him. She said her first gig was working for a guy named Big Blue, at a popular club he ran called The 360. It seemed like just the kind of place Octal would have liked to play. But according to Hex, Octal never got that gig.

We shared a byte, and I asked her why not. She told me Octal’s act had played out, and Big Blue wanted him gone. Sure, Octal had the numbers thing down, but people wanted more. They wanted letters too, and not just those six sexy ones Hexy was packing. They wanted them all. People were looking for strings. She said that Octal got retired because he didn’t know that tune. But Hex sure seemed like she did.

Octal could do letters, I said. I’d seen it, back when I worked the bar at the PDP-8. Coupla Octal digits got you six bits, plenty enough for a few letters and numbers. She gave me that big 4C4F4C laugh of hers. It gets me every time.

Octal’s two digits got you only 64 characters, she said. Now I’d seen plenty of characters in my day, and 64 seemed like enough to me. But she said people were asking for more. They wanted upper and lower case letters. Numbers. Symbols.

For that, you needed more bits I realized. Seven or Eight, and those were not numbers of bits Octal got along with. She reminded me that back at the PDP-8, it was always a 12-bit show, and when Octal wanted to do a 7 or 8-bit character routine, there were always a bunch of bits lying around that didn’t get used. It wasn’t working out well. Too messy.

The manager at the PDP-8 was a nice guy named Ken, and he tried to help old Octal out by coming up with some crazy routines. Like packing three characters into two 12-bit words and stuff like that. That got the job done, but it wasn’t a hit. And besides, people just weren’t showing up at that club like they used to.

They were all going to the new joints, a syndicate operation called The PC, run by the big crime bosses in town. Hex worked all these clubs, and she said the star performer was a guy named ASCII, who really didn’t get along at all with Octal. She said maybe I should talk to him.

I knew ASCII from when he was a kid, back in the mainframe days. Everyone was speaking a different language back then and the big bosses decided to put that punky ASCII kid in charge as the enforcer to get everyone in line. Right around when Octal went missing.

I called up ASCII on my modem, got a carrier tone right away. At first he was only talking 9600 baud but we negotiated a while, and I got him up to a cool 56K. ASCII was an older guy now, but still had sway everywhere in the city. Just not as popular as he once was, so he was easy to reach.

When I asked about Octal going missing, he said he didn’t know a thing about it. He said he didn’t kill him, but Octal had plenty of enemies in town and probably got what was coming to him. Besides, he said, he might not even be dead.

Then he told me a crazy rumor about some guy hiring Octal for a quick nine-bit job a few weeks back. Sounded like madness to me. But who was I to say.

Case 2: Murder Above 6th Street

I washed down the stale crusts of my sandwich with my cold coffee. Then I closed the Octal file, even though it still seemed like ASCII had some hand in his death. I just couldn’t prove it. That ASCII guy was a shifty character. And I was pretty sure Octal wasn’t his only victim.

I got out my Selectric typewriter to type up my case notes, both upper and lower. But then I remembered people don’t use typewriters anymore. As I was putting it away one key struck me though. It was the Six. Who was the guy in the picture above that key? Why it was old Cents!

I hadn’t seen Cents for years, we used to hang out together at the grocery store back when we were kids. He was a good character, even if he was a bit of a cheapskate. But Cents too had gone missing, right around the time ASCII came on the scene. A guy named Caret was now renting the spot above the Six.

I went down to see Caret. He said he was living in a tent, but then ASCII came and told him he wanted him for an opening at his new table. He got the place above the Six just after that, and by then Cents was nowhere to be seen.

I thanked Caret, because his help to the case was exponential. It was time to call up ASCII again because I had a lot of new questions for him.

ASCII said he wasn’t going to talk any more about Octal. I told him forget it, I had questions for him now about Cents going missing. I told him the trail led right to his table, and how Caret took Cent’s spot right after the disappearance.

ASCII said it wasn’t him that did Cents in. He said it was inflation. No one wanted Cents around, he couldn’t pay the bills and his credit wasn’t good no more. And ASCII didn’t want the likes of a guy like that at his table. So he told Cents to pack up and 23 skidoo. He said he had no idea what happened to him after that.

Everything did cost a buck or more these days, it was true. But ASCII had let a lot of other shady characters sit at his table. Backtick. Pipe. And that Pound guy who later changed his name to “Hash”. None of those guys had honest jobs back in the typewriter days. Until ASCII rounded them up as his programming goons that is.

Nothing was making any cents, so I decided to pay a little visit to ASCII’s famous table myself. Plenty of familiar characters were there when I arrived. N, U. Crazy old 9. Dash, Slash, Backslash. Colon and his half-brother Semicolon. And all the bracket and brace twins.

I asked a lot of questions but everyone was tight-lipped about old Cents. I was about to give up and go home, but thought maybe I’d just snoop around a little in ASCII’s ALT-code cellar before I left.

It was like a freak show down there. Dagger and Double-Dagger, Latin Ligature, Form-Feed. There were dozens of outcasts in that basement. All of ‘em locked up in little ALT-table cells. Far from the light of any keyboard.

Then I heard a weak voice saying ‘¢…’, coming from entry 155. It was Cents! He was still alive, after all! ASCII had cooped him up down here, all these years. I tried to get him out but then I remembered, you can’t really open a standard that easy. So I had to leave him down there, with the likes of Masculine Ordinal and Vulgar Fraction.

I thought of calling the papers and telling them my two cents on this story, but I didn’t think they would run it. Just like Octal, no one really cared about Cents. It seems the problems of an obsolete radix and a washed-up currency sign didn’t amount to a hill of bits in this crazy town.

So I went home, and closed the files on Octal and Cents. I felt bad though that I didn’t get the goods on ASCII. I’m a detective, and expecting me to run criminals down and then let them go free is like asking a dog to catch a rabbit and let it go. It can be done all right, and sometimes it is done, but it’s not a natural thing.1

I put my coffee cup and sandwich plate in the dishwasher, like I’m supposed to. There was a cold rain washing things down. Coulda used it for that sandwich. I was tired, and ready to turn in for the night. But then I remembered I still had to go into the city. Even though it was a dark and unforgiving one, that knew how to keep its secrets.

I had a date with a Grocer. To buy a loaf of bread.

Explore Further

• Five Great Dashiell Hammett Books

• The Naked City (Trailer)

• Police Squad! Episode 1

Next Time: Got projects you never finished that are bumming you out? Me too. But I’ve got some encouraging words for you. Assuming I get around to finishing the article, that is. Let’s all talk about The Value of Unfinished Projects next time on the Memo!

Still looking for the answers to life’s persistent computer questions? Why not sign up for the Mad Ned Memo? You’ll get the latest scoop delivered electronically to your inbox, no paperboy, signup fees, or spam included. It’s a free publication, and you can unsubscribe at any time.

Subscribe now

PSA: iPhone Users, check out the Mad Ned Memo on the new SubStack App!

Read The Mad Ned Memo in the Substack app

Available for iOS and Android

Get the app

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

Time to take a little break from the world of Nonads and Nine-Bit Computers. We’ll get back to that at some point, but (program note) if you want more info on this project, and/or you want to stay up to date until the next inevitable Nonad article, check out my Hackaday.io project page I started.

Now we move on to a completely different topic, and maybe not the most pleasant one: about when engineers get fired. I spend my time these days in a purely technical role, but I’ve been working for long enough to have put in some extended time in a managerial role also. And I have had the unpleasant duty on more than one occasion of having to tell someone they were no longer employed at our company.

This is an extremely bad thing for the people who have to leave, who in most cases do not even get much warning that it will happen. It can also be very tough on whoever has to break the news. I have had people crying in my office after they found out, and I have seen people get angry. I have had to let go of someone who has kids and a family and who was the primary income provider for the family. It never really feels good to be involved in this process, even in the best cases.

There are different reasons why someone may be kicked out of their jobs — Yes, kicked out. That may be a harsh way to say it, but ‘asked to leave’ is just one of many euphemisms that do not accurately convey the reality of the situation.

Here are three different scenarios that I have run into, over the many years I’ve spent in the engineering world. None of them are really great to be involved with, as either a manager or ‘affected employee’. But sometimes, there are silver linings, even at times like these.

Scenario 1: Misery Loves Company

Employees who are relatively junior may not have seen this situation come to pass yet, especially those who work at large companies. Given enough time on the job though, you will eventually witness or even be part of a large-scale layoff of some sort.

For startups and small companies, this is a known risk of taking the job — the company you work at may run out of money, or meet some other fate causing it to be no more. This is the tradeoff you made when you agreed to work there, usually trading job security for equity in the company, and a chance to grow your career quickly. If you did not take this into account when you joined and you were unprepared for this possibility when you lost your job, that is pretty much your bad. But it is not any fun, even so.

For larger companies, a large-scale layoff could be related to a product that is canceled or a division that is eliminated or cut back. These events often track the general economy, so for instance if there is a big recession, even relatively healthy companies will make severe cutbacks in their expenses.

I remember in December of 2000 during the dot-com bubble/recession, our company had several huge 20%+ layoffs, and even cut big divisions like a design consulting business that six months previously was about to IPO.

Our little group that day was busy pranking a well-liked manager who had returned from vacation, and we had filled her office from floor to ceiling with balloons, which was no mean feat because she had wisely locked the door to it before she left, fearing some mischief. We managed to get the ballons in anyway, through the ceiling tiles in the hallway. She was stunned by the effect and delighted by the attention, even if it meant digging her way through mountains of balloons to get to her desk.

Balloons drifted out into the hallway and surrounding office area to a depth of 1-2 feet, through standard stochastic processes. But as people were laughing and kicking them around, someone came over to tell us the consulting division had been cut, and something like 80+ people on the other side of the building were packing up boxes. We all stopped laughing, and quietly cleaned up the balloons. Not that easy, considering they were balloons — (pro tip: scotch tape on the balloon first, then poke a hole, for quiet deflating)

The cognitive and emotional dissonance of that day stuck with me. Maybe it was a form of survivor guilt, but I felt really bad for all those people who were let go. A big downside for them was, they were all suddenly looking for jobs in a very bad economy.

But in many ways, this is the least difficult of the three scenarios I am talking about here. If you find yourself let go as part of a big company cut or a failed startup situation, you can collect your things knowing that it is a random curve ball thrown your way, and is not somehow related to your work performance or ability to do your job.

Other people know that too. Future employers, or fellow employees who make their way to other companies that eventually need people. I wrote previously about the idea of developing your personal brand, and how it is really the only true form of long-term job security in a world where there are no sure bets of continued employment.

If you focus on being someone people like to work with, you can recover from a big layoff situation and find your next opportunity all that much faster.

Scenario 2: Peanut Butter and Lifeboats

Coming a step down from the big layoff disaster event is the smaller, sometimes even ‘routine’ layoffs companies engage in to control costs. In the strong Bull market we have had in the past few years in tech, these have become less common. But just like my previous prediction, if you have not seen one yet, stay tuned. It will happen.

We took to calling these types of layoffs “peanut butter layoffs” because they are often implemented as reductions in force that are spread evenly around. Upper management will ask all groups to reduce costs by say five percent, but the only real way to implement such a cost reduction is by reducing payroll — ie layoffs.

I find this strategy to be somewhat lazy on the part of the management in charge. Instead of making targeted business decisions, they just tweak some numbers in a spreadsheet. It is very common however, and the result is often that managers of teams both high and low performing being forced to pick some of their people to be voted off the island.

I have been on both the manager end and on the receiving end of this process in the past, which plays out in most cases as a Lifeboat Excercise. Low-level managers are given the unhappy task of picking a small number of people, one or two maybe, to be cut from their teams. And the standard process usually is, to figure out who you can most live without. Or perhaps, whose departure will cause the least impact.

Having to engage in this type of planning never felt completely right to me. It seems cold and calculating to have to assess people’s worth to the company and rank them versus each other, and you don’t want to lose sight of the fact people’s lives are in play in this game.

What helps me here (when I participate in the manager role of this process) is to think of the people who are not leaving, and how to best serve them. It’s bad enough that a group is being downsized but has to continue doing their work. It would be even worse if the wrong people were retained, and this led to problems that triggered further reductions down the line.

For the people leaving, there may also be some consolation prizes. Being at the bottom of the lifeboat list just means that the company has found a way to go on without your particular position, with you in it. This doesn’t have to be because you were a bad employee. Many times, it is the position itself that has become expendable, thereby making you expendable also.

This has happened to me in the past. I took a job as a full-time manager that turned out to be a bad move for me. The work was unfulfilling, but in spite of that, I remained on the job. Because it was easy to just stay at it rather than have to go through a big job change event.

The job change event found me, when they moved most of my group to another country and eliminated several other positions as a way to cut our division’s costs in a peanut-butter layoff going on company-wide. Luck was with me, and I landed a technical position in another part of the company, two days before I had to box everything up. It turned out to be the right medicine for what was ailing me, even if it was kind of force-fed.

Even if you were asked to leave because you ended up on the lifeboat list because you were considered to be underperforming, it is not a personal assessment of your worth, but the situation you are in. I would say in my case, I was definitely not giving the company my all, even if my performance reviews were fine. It was just the wrong place for me to be, and when I started working again in the new job, my work output, and hopefully value to the company, increased.

It’s very easy to think “once a bad employee, always one”. But the truth is people change drastically in response to their environment. You really can go from problem employee to star performer, if the change in conditions is right. So if you were let go at some point because you had bad reviews, take this to heart. There are jobs that are bad fits, but not bad employees.

Scenario 3: Summarily Dismissed

OK, that’s not entirely true. There are sometimes bad employees. I’ve been working for forty years, and if you work for long enough, you will see some shit. I had a junior engineer who I was supervising call me one day at DEC to tell me he was not coming in because he was in jail. It seems he drove his car through his ex-wife’s above-ground swimming pool. Fired.

Another guy basically quit, but we had to fire him instead because he just decided not to come to work one day, and go to South America instead. Nobody could reach him, he just ghosted the company, his family, and the country. They had to terminate him because he never filled out any resignation paperwork.

And I won’t, for a variety of reasons, go into the guy down the hall who killed his wife. Suffice to say it is pretty nerve-wracking during the period between someone getting out on bail and the company getting a restraining order against them showing up at your office.

Dramatic. But I would say the most catastrophic cases of people being “summarily dismissed” — meaning let go outside of any layoff cycle — are those who are mild-mannered and reliably showing up to work. These people get fired for not doing their job, but also for going the extra mile and are negatively impacting others. And also the codebase.

I have only been involved with a few cases where people are straight-out fired for poor performance. The one that sticks in my mind was this guy, let’s call him Bob, who was a really friendly and I believe well-meaning engineer. Bob did well on our interviews and was hired as a software developer in charge of infrastructure components. But it soon became apparent that his development habits were very heavily biased towards the hacking end of the spectrum.

Bob would get whatever you asked him to develop working, but in the fastest, easiest way possible. Which is rarely the best way. It was not my job at the time to supervise Bob, but the issue was, nobody else was doing it either. So he continued for some time developing a lot of code, which soon ran into big quality and maintenance issues.

Our management definitely gets a big chunk of blame for letting things get out of hand here; we were very lax about code reviews at the time. Bob meanwhile was busy importing huge dependency libraries into the code so he could modify the source, and creating Rube-Goldberg-esque chains of undecipherable control logic all through our (pretty large) codebase.

At some point, another senior engineer and I were tasked with reviewing his work, and we were shocked at the mess we found. Some companies might decide at this point to fire someone, but ours at least is very cautious on this front, and instead transitioned him to a “performance plan”, where he would continue to write code but had to make improvements in order to keep his job.

This is where things went south. Bob got very defensive about any feedback from us, and began to do things like check in code without sending any notice, claiming he ran regression tests when he had not, and agreeing to make changes to his code but then checking it in anyway, unchanged. Any attempts to get him to change his ways resulted in protests that the requestors were being “corporate suits”, intent on being bureaucratic.

My fellow engineer and I at this point begged our manager to remove him from responsibility for the code he had. We were not asking for him to be fired. Except we were. It took another four months though, during which Bob was assigned to work directly with our manager, because there had been claims he had been treated unfairly by me and other senior engineers in the group.

After a few more disasters my boss had to personally clean up, he finally had the sad duty of telling Bob it was his last day. In spite of everything, I really felt bad for Bob, because he was a nice guy. Just a bad coder. Maybe not even that, actually — I would say he too was in the wrong place versus his skill set and desires. I could easily see Bob doing something else, maybe teaching kids to code, or working on a research project or small code base that didn’t need a high level of software engineering to be done.

In the end, I would say the fault here for Bob being fired lies very much on the company, for putting him in a position he could not succeed at. And then, not correcting it until a lot of damage was done. We had problems in our code related to Bob’s work for years after. Years.

I don’t know what Bob is doing now, but in at least one other case like this that I have seen, the person shifted not only jobs but careers, and found something they could really succeed at. I’m hoping this was the case for Bob, too.

My boss for his part also was a really nice guy, and he felt bad about having to let Bob go. The afternoon after Bob left, I went into his office and thanked him for going through that difficult task. I have been a manager and it is largely a thankless job, so having someone show that there is a positive aspect to something like a firing is really appreciated. The truth is, in spite of Bob being a nice guy, he was putting the product, and our group, in jeopardy.

So if you find yourself having to do this unhappy task at some point, think about the people who are still working, and counting on you to keep them safe and productive. But also think about what went wrong, and how you ended up being a firer, in the first place.

The sunniest side of managing people after all is not having to say goodbye to them.

Explore Further

• Easy Peanut Butter Cookie Recipe

• Tips on Blowing Up Balloons

• 8 Steps For Bouncing Back After Being Fired

Next Time: Two victims. One killer. How icons of the past met their fate at the hands of an unassuming assailant: The American Standard Code for Information Interchange. What the hell am I talking about? Tune in next time for the answers to this crime story in: ASCII Double-Murder!

The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

Hello and welcome to part three of my “Holy Nonads” article series, which chronicles my attempt to build a nine-bit computer. So far I have talked about why I wanted to build this odd machine, and a little about the design of the hardware architecture.

I have not figured out yet how many parts there should actually be in this series, but I will confess that thematically, nine does appeal to me. Before you go running for the unsubscribe button though, I do plan to relent after this article and move on to other, non-Nondadic topics for a while. I was thinking maybe it should follow the three-of-threes theme: a trilogy of trilogies, with some resting time in-between. You know, like Star Wars, except in linear order, and without Jar-Jar Binks.

So if you tire of the whole nine-bit saga, hang in there. But for whatever number of people out there who are actually into building weird CPUs, I do have some advice to offer, next.

Timing Is Of The Essence

I spend a fair amount of my work life dealing with hardware description languages like Verilog, which I suppose gives me a little bit of a leg up with trying to create FPGA designs. But not as much as you might think. In reality, I do not write much Verilog code, and I certainly have never attempted to do anything as complex as a CPU.

So I found out early about all the things I had under-appreciated about building a CPU.

Like timing.

I was of course aware that things do take time to happen in silicon; inevitable delays to propagate signals through wires and to process them through active components like the transistors that make up logic gates and so on. Also, I understood the idea that running a CPU instruction is broken down into steps, like fetching the instruction, decoding it, executing it, and saving any result somewhere.

I naively thought that I should be able to do the above steps in four clock cycles, for all of my instructions. It seemed like plenty, given modern processors could probably due it in less, thanks to a lot of sophisticated design enhancements to pipeline all the operations to happen in parallel, as much as possible.

The more clock cycles it takes to run an instruction, the slower your machine is. Since I was not particularly worried about speed though, I didn’t mind having some clock phases — to make my timing life simpler, and not have to think about implementing pipelines and branch prediction and what have you. Four seemed like enough, but I kind of forgot about this little thing called memory latency.

Kind of embarrassing actually, because I spent the first five years of my career designing memory systems for mainframe computers at Digital Equipment Corp, and there were lots of latency issues to contend with.

Give Me a Second to Recall

This was the mid-1980 peak years for the minicomputer companies, and DEC was a giant whale, sucking in new college hires like krill. We were all given responsibilities far above what we probably should have been doing as junior employees. In my case, I was asked to design a chip that handled interleaving, refresh, and self-test of main memory. My chip talked to other chips in the cache system, which talked in turn to instruction and data units in the CPU.

I and the other new hires did what I would say is a pretty good job getting working designs together, given none of us had ever designed a chip before. But our inexperience soon became apparent when the architects of this project began to calculate machine performance, and realized there was something like a 24 cycle latency for data access from the CPU to main memory. With predictable performance consequences.

Each of us in the path from memory to CPU had made decisions about clocking and control in our chips that made things simple, but caused there to be way too many stages of logic. When our management found out about it, they freaked out and put our system architect Bob Stewart in charge of reducing memory access time, and I think we eventually got it down to something like 8 cycles. This is where we learned all sorts of neat tricks about they didn’t cover in Digital Logic 101, like one-hot state machines, and flow-through latch design.

I was thinking about this as I worked on getting my CPU to actually fetch stuff from memory. I thought about how DEC really should have had their management act together a little better and supervised the junior people earlier on what they were actually doing. But I also thought about how I had basically forgotten about memory latency in general, in spite of my many trials with it.

These mainframe CPU designs (I then remembered) were full of control signals to do things like gate clocks and stall execution until data was ready, which was a design idea I had not planned for in the least. I considered modifying my CPU to implement a stall condition (and may still at some point.) But in the end, I opted instead to expand my clock phase system to 8, so I could keep things simple and have a guaranteed overall instruction period without stalls and gating, and so on.

Even that turned out to be a challenge. The Artix-7 FPGA chip I was using had built-in BRAM structures, that could deliver memory data in two clock cycles. That’s incredibly fast main memory access, by any CPU clock standard. I had the luxury of not needing a lot of memory in general for QIXOTE-1, so the on-chip memory could be my main memory (which also avoids the need to build a cache of any sort).

But even two cycles of delay can add up, when you have to do things like fetch an instruction from memory, possibly operands as well, do operations on them that may also involve memory access, then store them possibly back to memory again. Again, the right thing to do would be to build a system that waited for memory access to complete, and have a variable number of clock cycles per instruction.

But I didn’t go there. Instead, I reverted to inferred memory structures comprised of registers, which are the fastest form of memory you can get, delivering read data in just one cycle. But it is an expensive form of memory, and more than a few K of it would exhaust the resources of the Artix-7 chip. For now, that is fine, because the 512 Nonads that are addressable in the system fit fine in registers.

But as my software ambitions grow, the whole memory addressing/dealing with latency thing will eventually have to be dealt with.

Why all the reluctance to fix it? A big reason is that I am a one-man show, and I want to have some episodes of this show be about things other than the CPU hardware: like creating assemblers and languages, working with video, and so on. If I am spending all my time figuring out the CPU timing, I never get to do those. So I am more than willing to trade CPU speed for a simpler design.

The other reason though is probably trauma. The whole area of memory latency and signal feedback like clock gates and stalls touches on an area known as Control Theory. This is a dark chapter of my college education that involves the worst professor there ever was (anyone claiming they had a worse one can fight me).

Fourier, Frogs, and an F on the Final

Control Theory is the study of complex systems that have feedback and latency in them, using mathematical principles (Fourier series, in many cases). Feedback systems are a notoriously difficult thing to model, but a lack of understanding of the principles involved can lead to disastrous results, like bridge collapses or rocket explosions. So as an Engineer, you ignore them at your own (and maybe other people’s) peril. As such, I harbor no beef against the Control Theory area of study itself, as long as it is not me doing it.

My experiences with it in college were disasters in their own right though. ECE students at my school were required to take a course called Signals and Systems, a hybrid Control Theory and Digital Signal Processing course that was taught by someone from the Biomedical Engineering department. This Professor X’s publish-or-perish project was all about modeling the renal output of frogs using Control Theory, and he had tailored his hapless grad students’ research projects around this material.

And it wasn’t just the grad students that got to be part of the frog-piss fun. With just two weeks left in the course, our professor had become increasingly irritated that the majority of the (mostly ECE, not Biomed) people in his class had scored 40 points or less on his exam. Out of 200 possible. So he declared that the course was now a lab course, and we all needed to complete a lab experiment in his bio/frog lab for 30% of our grade, something involving electrically probing Petri dishes full of different solutions.

Since there were only two weeks left in the semester, there were virtually no slots available for all his students to use the lab and equipment, and the grad students of course had priority. So I found myself in his lab on a Saturday morning at 8 AM, grumpily probing dishes of god-knows-what, while Biomed grad students nearby took frogs out of buckets and chopped their heads off with a little mini-guillotine.

I flunked this course, in spite of finishing the lab. The frog-piss thing should have tipped me off; this professor was a well-known bad egg and my friends all wisely changed their status to “Audit” on this course one week in, but I stuck it out like an idiot. We all had to retake it, again, in the summer, with a different professor. So I had then and continue now to have a fairly negative impression of the whole Signals and Systems area.

But, you know, it is relevant even so. Lack of proper system modeling of things like latency and feedback loops can doom more than bridges and rockets. It caused problems on the big mainframe project I worked on all those years ago, and continues to cause problems on the little CPU project of mine today. I think I was prematurely dismissive of this course because of the mainly linear/analog applications of the math, and of course the horrible teaching of it in general.

I guess if I were to give a curriculum suggestion it would be for ECE students to take some variant of this course that makes the general principles more accessible to the designers of general electronics and digital systems. But being a self-described math-hater, you probably shouldn’t take academic advice from me.

The pragmatic advice I feel more qualified to give is, if you plan to design your own weird CPU, be sure to think up-front not only about what things are connected to what, but also about how long it takes for information to get from place to place, and what happens at the system level as a result.

The System Eats Itself

I had some other less-consequential timing problems after resolving the memory latency issue, but eventually the CPU began to run test programs. This is where things got interesting, because I started encountering situations where I was dealing with two things of unknown quality: my hardware, and my software. And it was sometimes tough to tell where the problem was. On more that one ocassion I cast unwarranted aspersions on the quality of my CPU hardware, only to discover a programming error on my part in the assembler test program.

The shift from hardware testing via simulation to testing via software actually running on the hardware has been fascinating for me to observe. It has problems of its own, but the software aspect opens up a whole new world to explore on this project. The next trilogy of this series (after the previously-mentioned breather) will move out of the hardware-centric focus of the series so far, and delve into some of the design issues and challenges of creating software for a brand new machine.

I’ll wrap up for today though by mentioning one problem where simulation debug was really an essential to figuring out what the software was doing. Early QIXOTE programs seemed to do just fine with reading memory, and sometimes writing. But sometimes not. I couldn’t figure out what was going wrong. But then when I ran a simple program and inspected memory contents in the simulator, I found out why: QIXOTE-1 was modifying its own program!

It turns out the write signal to memory was level-sensitive and not edge-sensitive — for the non-hardware people here, it just means that instead of paying attention where to write memory contents at a precise moment of time, it was doing it over a span of time, while things were in flux. So random areas of memory were getting overwritten, including the executing program code itself.

Leading to predictably unpredictable results. This is not actually that unique a scenario, I think many have encountered similar situations with corrupted or self-modifying programs in their coding lives.

It was a simple fix, and memory reading and writing seems to be working fine now. But I will say I felt a little proud of QIXOTE-1, trying to break free from the confines of its programming and spread Nonadic glory through the universe!

Explore Further

• Technical Paper on Reducing Memory Latency (PDF)

• Top 17 Bet Pet Frogs for Beginners

• Core War - (A 1984 game of battling memory-modifying programs)

Next Time: Something for the technical managers out there. For those who have the unfortunate duty of having to let someone go, it can be a stressful situation for everyone. It is an outcome that in most cases should be avoided, but it does of course happen. And there are even benefits, for all involved. Sympathies and silver linings for the Fire-ee and Fire-er coming up in: The Sunny Side of Firing Someone

Want something to actually look forward to in your email? Not everything there has to be shipping delay notices and billing statements, you know. Subscribe to the Mad Ned Memo to get your regular dose of nerdy computer engineering tales, discussion, and perspectives, delivered to your electronic door. It’s ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

This is a follow-up to last week’s article, where I talked a lot about why I wanted to design a Nine-Bit CPU, but not a lot about what happened when I did. So here I will go into some details of building my QIXOTE-1 processor, but it will not be a class in how to build a computer. I am far from being an expert hardware designer, and my CPU design is far from being optimal or even practical. So I am not the guy to look to if you want to try it yourself. (But if you are really interested in the theory and architecture of CPU design, see the links below.)

Instead, I would like to talk about what it’s like to design a CPU, so far. The challenges, the ideas good and bad that have come up, and the connections I felt to past engineers attempting to do this same kind of thing.

Even at this early stage, I have received a lot of practical and well-meaning suggestions for this project, about everything from a better name than “Nonad” for the data unit, to architectural advice about word and address lengths that are multiples of nine.

I’ve pretty much ignored most of this advice so far, with respect to the design of QIXOTE-1. Not because they weren’t good ideas. But because this project is more of a thought experiment gone too far than it is an attempt to create anything actually useful.

Practical just doesn’t come onto the radar, here in Nonad land. But far from discouraging people from sending me their ideas, please send me more! I really enjoy reading them and plan to do a roundup of some of the really interesting and sometimes funny things people have pointed me to in our next Memo Rewind for subscribers this spring!

Leave a comment

Building a Nine-Bit Toaster

A guy name Thomas Thwaites did a fascinating TED Talk a few years back, where he outlined his quest to build a toaster, from scratch. His attempt to create a seemingly simple device like a toaster without the aid of even basic building blocks like plastic, wire, or steel was a brilliant commentary on how reliant we all are on things like the global supply chain, and civilization in general.

Building a new CPU myself felt a bit like that, although I admit that I did not take my DIY quest down to as low a level of abstraction as Thwaites. Others have built CPUs out of lower-level and less obvious building blocks than an FPGA, such as this Tinkertoy computer from 1975, or Minecraft blocks.

That kind of low-level hackery does in fact also appeal to me, of course. But I really wanted to work on the software side of things as well in this project, and the thought of building a working, program-running CPU without the benefit of even having logic gates at my disposal seemed pretty daunting.

If I ever went there though, I would likely follow the suggestion of a reader of the previous article, who suggested I build a system using trinary logic. In addition to being a strange choice that avoids even the basic standard of binary data, a three-state system would fit well thematically into the world of a nine-bit computer.

Fail Your Way To Success

Maybe QIXOTE-2. The killer reason to stick with my FPGA plan for the hardware though turned out to be simulation.

I began to cobble together things I was sure I needed, like an instruction decoder, an arithmetic/logic unit (ALU), registers, memory, and I/O. But getting them to actually work together required hundreds of trial-and-error modifications on my part, and that could be done relatively quickly via behavioral simulation.

It would have also been possible to try to run each circuit attempt on the actual FPGA hardware, but the cycle of synthesizing, routing, creating a bitstream and downloading to the FPGA board took about five minutes each — which is considerably longer than the modify/run/debug cycle when simulating a circuit. And of course, simulation gives you a full view as to what is actually going on, versus the mysteries of not having any LEDs light up due to a bad hardware implementation.

Our computer-designing predecessors would have killed for a five-minute turnaround time between hardware modification and the testing of it. I thought about what must have transpired during the building of early computers, back in the middle part of the 20th Century. New hardware then did in fact require a lot of (time-consuming) soldering by hand, and so they built generic pieces ahead of time, like single-bit registers, logic modules for various functions, decoders, and so on. And then patched these all together, endlessly moving wires around as they debugged.

So there actually could have been situations where these old relay and tube computers could be reconfigured in five minutes or less. But not if you wanted to make some fundamental change, like the size of a data bus or the overall timing of the system.

If I had coded it to be configurable (which I did not), the QIXOTE-1 could morph from a 9-bit computer to say a 16-bit one with just a change to a few lines of Verilog parameter code. Then you could recompile, and run the new, bigger machine just a few minutes later.

But I wasn't really interested in enabling that kind of configurability with my project. Improvements in design productivity like this though did let me side-step most of the costs associated with making dumb design mistakes and poor architectural choices that my predecessors would have incurred. Including, what I would assume were mistakes ending in smoke, and fire.

There was nothing really to stop me from just trying many things, even dumb things, one by one. So I just kept building bad CPUs until I built a good one.

Cheap, programmable hardware and ability to simulate systems before building them opens a whole new world of possibilities for someone interested in experimenting, as the cost of failure is low.

Early computer designers meticulously planned out their designs mathematically, pretty much out of necessity. They built number-crunching machines, meant for high-priority wartime tasks like code-breaking and artillery calculations. They really could not afford to make mistakes before building things by experimenting, and the idea of creating a computer for entertainment, or even artistic purposes was far off.

Obviously, we did get to the point where computers were more than just mathematical solving machines, but many of the original design decisions that were made for the earliest computers still survive to this day. Things like Von-Neumann and Harvard Architectures, SISD program execution, and organization of things into specialized hardware like instruction decoding and ALU.

There are very good reasons why these things have remained part of mainstream computer design for so long. But it is also a very good idea for people to revisit these decisions once in a while, and see if something else can also be created given the new technology and associated freedoms we now enjoy. My advice to anyone interested in experimenting with hardware is to take advantage of all the progress that has been made in hardware development methods, and go build something different!

A Simple But (Surprisingly) Normal Machine

I do like to think about weird, non-mainstream computer designs, like say a less-synchronous kind of system that operates on dataflow principles. Or non-deterministic hardware that operates on probabilities. Machines with multi-dimensional, or maybe even fractal program counters that can be at multiple locations, or maybe stack levels, all at the same time. Fuzzy logic. Trinary or analog systems. Self-modifying code machines. Neural processors.

Many have dabbled and even built computers with strange architectures like these. (Neural nets and machine learning systems being a notable growth area today) A big issue with weird computer architectures though is that it can be hard to create a straightforward way to program and debug them.

Which is a big reason that in the end, I decided not to make any radical departures from Von Neumann / SISD architecture for QIXOTE-1. At least immediately.

But also, because I felt a need to actually understand the rules of creating a processor before I decided to break any of them, maybe.

So once you get past the nine-bit design, the implementation of QIXOTE-1 turned out to be rather conventional. It’s partly inspired by the PDP-8, a 12-bit octal machine that is famously considered a very early RISC machine. The first 3 bits of the instruction word on the PDP-8 are the instruction opcode, so it is often said the machine only has 8 instructions. (It is not quite true though, because instruction 7 breaks out into a myriad of microinstructions)

QIXOTE-1 also decodes the first 3 instruction bits as opcode. It currently has just four instructions: Get data, Put data, Move data, and Jump. This is also a bit of a lie, because each of these can perform their operation either with an inlined ALU operation (in the case of GET and MOV), or some condition (in the case of PUT or JMP).

Also, the location that things are GET-from or PUT-to is quite flexible and can be memory, a register, an immediate operand, the accumulator, or a mapped I/O device. So really a lot of instruction combinations are possible. (I’d say, about 192 or so today)

Every instruction except Move is also followed by a nine-bit operand that can be a literal/immediate value or memory, I/O, or register address. If you wanted to get picky, instructions are either 9 or 18 bits, actually.

But it is nonetheless a tiny, bounded machine. Quite simple, with no cache system, pipelining, prefetching, and so on. I have also not implemented extended memory addressing, so the address bus is only 9 bits. I did get an excellent suggestion to make it a three-Nonad/27 bit bus, fitting nicely into a general “three of three” theme I have going on. But that is another QIXOTE-2 candidate idea I think.

This constrains things quite a bit. I intend to explore what I can do in the 512 Nonads of memory afforded to me with the limited 9-bit address space I have before hatching any more ambitious schemes though. (The source/dest field of the instruction however allows for slightly more memory to be addressed, in the form of non-contiguous memory pages. I intend to implement a simple video memory space this way)

A One-Machine Program

There were a lot of bumps on the road from thinking about building a processor, to actually getting one to run on real hardware. I hope to go into a few of the interesting and sometimes amusing ones in the next part of this series. But there did eventually come a day when I had something that was both functional and synthesizeable (these were mutually-exclusive it seemed, for a good while).

I loaded a version of QIXOTE-1 along with the test program above onto my BASYS 3 FPGA board. It is a simple program that goes out to a memory location, gets a Nonad (octal 456), increments it, writes the result to the LED display (mapped to I/O address 001), then loops in place forever. (maybe I need a HALT instruction?)

When I loaded it and hit reset to start the CPU back at address 000, I was treated to a bright-red (and importantly, correct!) octal “457”, as shown in the earlier picture.

I really can’t describe how something this meager could feel so satisfying. It is very much the “Hello World” phenomenon I discussed in an article earlier this year. Just the joy of bringing something new into the world I guess.

What particularly struck me was the thought that while I had written many programs in the past that only I had run, this was likely the first time I had written a program that no one else could run.

That would be impossible, because (at the moment at least) there is exactly one machine on Earth capable of running it. I’ve told old-man stories before about how in the 70’s I was the only one I knew with a computer in his house. It felt special, and I’d be lying if I said there wasn’t at least some of that special feeling coming back to me, working with this one-of-a-kind machine.

But I am not really interested in the having of an Only-Thing, just in the making of one. When the code for this project is in less embarrassingly-bad shape, I’ll put it on GitHub or somewhere central, in case someone gets really bored and wants to build their own Nonadic machine based on mine.

So who knows, maybe even QIXOTE-1 will not be unique forever. In the end, nothing is guaranteed to be one-of-kind, but you.

Explore Further

• Computer Organization and Architecture Tutorial

• Build Your Own CPU (hackaday.com)

• Instruction Set Design Lecture

Next Time: So you want to design a simple CPU. What could go wrong? Plenty. I run down some of the weird and sometimes wonderful ways things can go off the rails on a journey from processor concept to processor reality. More hardware design adventures, good and bad in part three of my Nine-Bit CPU saga, Holy Nonads!

Stay in touch with nerdy computer adventures, Nonadic or otherwise, by subscribing to the Mad Ned Memo! Each issue features tales and discussions from the world of computer engineering and technology — past, present, and future. Follow the link to see more, and if it’s your kind of thing, consider subscribing! It is cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

I like to spend at least some time every year indulging my inner hardware engineer, working on something that involves actual physical things you can touch, and preferably even solder. It’s usually not something practical, but it seems always to be a satisfying change of pace from my day-to-day software duties. Call it getting in my required flight hours for maintaining my Nerd/Hacker status maybe, or perhaps it’s for keeping the “Mad” certification, I don’t know.

This year has been no exception. I mentioned in my first post this year that I had picked up a BASYS 3 FPGA board, and was planning on experimenting with it. A Field-Programmable Gate Array (FPGA) is kind of a grey area between hardware and software since it is software-programmable hardware that does not in fact require any soldering. I still count it against my hardware nerd flight hours though — even though in truth I’ve spent most of my time simulating circuits and not even downloading them onto the board.

FPGA for Hire, Problems Wanted

So the question then became, what to do with this thing? In the past I had spent a lot of time playing with small embedded processor boards, like Arduino or Raspberry Pi, building everything from a talk box for my dog, to a retro-arcade system for my living room. This BASYS beast was different though because it allowed one to create hardware circuits at a very low level, inside the programmable fabric of the FPGA chip.

I wanted therefore to build something unique, something that took advantage of the fact I had fully-customizable hardware here and not just an existing processor.

And ay, there’s the rub, as Hamlet put it. The mere fact I could simulate any circuit I planned to download to the BASYS meant that I could also write that same algorithm as software for an existing system, like say a Python program running on a Raspberry Pi. Probably quicker. Probably easier. And probably with the same (or better) result.

This was a rub that unfortunately not only vexed me, but also the makers of programmable hardware chips, like Xilinx and Intel/Altera.

Who will buy your product if it is harder to use (and usually more expensive) than another solution? Cheap and easy-to-use processor-based systems like Arduino and Raspberry Pi have become increasingly more prevalent and capable over the past decade, cutting into the programmable hardware business.

The answer to why you would still want to build an FPGA system is (and always has been) speed. If you can describe your program/algorithm in Verilog or VHDL instead of Python, then you can implement it natively in hardware on one of these boards and it will run blindingly fast compared to a software implementation.

Python for instance is known not to be a speed-demon, and even a simple addition operation there results in multiple, perhaps dozens, of instructions. And each processor instruction can require multiple clock cycles to complete. A hardware implementation can do that same addition operation in one clock cycle.

The BASYS 3 board I have is over 10 years old and is used primarily for educational purposes. Countless Computer and Electrical Engineering undergrads have probably programmed one. Its max clock speed is 450MHz, way below that of any modern processor. But in most circumstances, an algorithm implemented on this old machine could still run circles around a Python program, running on the fastest CPU out there right now.

Problem was that I didn’t have any potential project plans that required that much performance. Nor do a lot of others, which leaves companies like Xilinx and Altera in a bit of a bind, and looking for new markets. They have been moving lately into areas like specialized hardware for machine learning, which I think is a smart play since it really is an area that has an almost limitless need for customizable, high-performance hardware.

Psychic Treble Damage

So I quickly gave up on creating something that could only exist on my FPGA board, coming to terms with the idea that this project was about the doing, not so much the result. It seemed like it would be good enough to just create something one-of-a-kind, with the satisfaction of knowing it is the world’s only flurb, or zoingle, or whatever.

But given the size of the world, this also turned out to be harder than it sounded.

I’ve long had this thought of building my own oddball processor and accompanying software stack from the ground up, and deliberately eschewing any kind of existing standards. No ARM core, no C, no GNU, no USB, no Unix. Everything created new, custom, and stubbornly incompatible with the rest of the world.

Building on existing standards and not re-inventing the wheel is of course the foundation of good engineering practice. There is very little monetary incentive in redoing things someone else has already figured out, and doing everything yourself forces one to work at a low level instead of “standing on the shoulders of giants”. So it is rarely done, unless there is a promise of discovering some new path forward with fundamental benefits. Frost’s proverbial road less traveled by.

I began to have somewhat grandiose visions of building a processor and software language of my own, that would be capable of implementing say a video game of some sort. Everything along the way new: Instruction set, compiler, low-level software, and game application. Who knows what I might discover along the way? I began to research this idea to see if anyone had done it, and was crushingly disappointed to find a lot of excellent “prior art” here.

Almost every place I’ve worked has had a legal department that strongly cautions engineers against attempting to research whether some innovative idea they have has already been done. The reason has to do with patent law, and something called Treble Damages. The basic idea is, if you violate a patent belonging to another company, they can sue for damages. It can often happen by accident, when people independently happen to arrive at the same solution to a problem.

But if you knowingly violate someone’s patent by copying it, that is another level entirely. Your company can be liable for additional punitive “Treble” damages in this case. So in order to keep “plausible deniability”, it is important for there not to be some electronic trail showing you knew something had been patented but decided to violate that patent by creating an equivalent.

I didn’t really have any patent law worries on my hands here. This was a side project, not work-related, and not something I planned to sell. But to find out that someone else had already created an impressive custom FPGA-based CPU, compiler, language, and accompanying game all on his own was devastating Treble Damage to my motivation. I didn’t really picture myself doing a better job than this guy, or even getting anywhere near as far as he did.

I then thought about doing a super, super custom FPGA project, whereby I create a video game, entirely in Verilog so it can be implemented in hardware directly. A video game without a processor involved - it seemed like crazy talk! Until I found multiple people had already done it. In fact, I found a guy who made a game on the very BASYS 3 FPGA board I was using.

And the more I looked, the more FPGA-native video games I found. Like this one. Or this one. It was clearly a sweet spot for FPGA usage, but it didn’t exactly seem like an interesting unexplored area, so I gave up on pursuing this idea as well.

My last thought was to go back to my roots, and try to do an FPGA implementation of the Digital PDP-8 minicomputer I learned to program on. I happened to have a set of original PDP-8 schematics, so it seemed I could try to build one using them as a reference.

But you probably can guess — this is also something that has been done multiple times. A project so common in fact the PDP-8 is an official library in OpenCores, the Open Source Hardware IP site.

Nothing is New but You

Now that I had caught up a little with what the rest of the world had been doing with FPGAs over the past 15 years while I wasn’t looking, I changed my thinking.

What I finally arrived at was the thought that I should not be worrying about doing something unique to the world. It was good enough for it to be unique to me. Lots of people had designed their own CPUs. But none of them were me.

It is a somewhat common capstone project for computer engineering students for instance to do some processor FPGA implementation. But not when I was an undergrad, because FPGAs did not even exist then. My first job out of college was actually working on a team designing a mainframe computer. But my job then was to design the memory system, not the CPU. And later, I worked on debuggers and simulators that frequently required me to interact with hardware designs of complex new CPUs. But always reading and debugging design code, not writing it, or even understanding how it works.

So I went back to the original plan, to finally design a CPU of my own, with no further goal other than to do it. But since I still didn't want to just mimic some existing architecture, I promised myself I would do weird, experimental things with the design when I could.

I was generally free from constraints, like needing to have a certain performance, to be commercially viable, or to be compatible with any existing thing.

So I started my journey on the less-taken road by making a nine-bit CPU. Why nine bits? Well, there's a healthy dose of “why not?” in there, but it also had an appealing “three of three” symmetry to it.

The big reason though is that it pretty much guaranteed it will not be very standard. Maybe there are other nine-bit machines out there, but if so it's not a large number. It is not that practical, for reasons I will go into in the next part of this series. But practical was also not on my list of design considerations, so I went ahead and sketched out an instruction set and architecture, and built a starting version of this machine.

The first Standards casualty of this 9-bit decision I encountered was bytes. No eight-bit quantities, no bytes. So I had to come up with a new term. Old mainframes and minicomputers with octal data sizes like 12, 18, or 36 bits just called their data quantities “words”.

The QIXOTE-1 (my working title for the CPU) is also an octal machine, given you can nicely fit 3 three-bit octal digits into 9 bits. But calling the 9-bit quantity a “word” seemed boring. So I did some research and discovered to my delight that a collection of nine of something is called a Nonad.

So the QIXOTE-1 is shaping up to be a fully-nonadic processor, and currently features two kilononads of memory! Satisfyingly weird, already.

I soon found a lot of really useful hardware and software things that just can’t be used, once you decide to build a nonadic system. And so you just have to then create a new and unique version yourself, out of necessity. And I guess that is the biggest motivation for going this way.

QIXOTE-1 has only run a few programs so far, but I have already learned a lot about what goes on behind the scenes that I’ve been taking for granted, all these years.

Well, I guess this kind of covers the “why” part of the project, which is where I would like to end for now. In the next installment, I’ll talk a little more about the QIXOTE-1, and the (hopefully interesting) things I’ve learned about CPU design in the process. See y’all back here for more nine-bit nerdiness then!

Explore Further

• Getting Started with FPGAs

• Some Things That Come in Groups of Nine

• The History of Don Quixote (project Gutenberg eBook)

Next Time: We dive deeper down the nine-bit rabbit hole and take a look at QIXOTE-1, with a few lessons I learned about how to design a CPU. And a few about how not to.

Nonstandard fun returns in: Holy Nonads, Part 000 000 010!

The Mad Ned Memo features nerdy tales and discussions from the world of computer engineering and technology — past, present, and future. Follow the link to see more, and if it’s your kind of thing, consider subscribing! You’ll get the Mad Ned Memo delivered to your inbox on a weekly basis, and never miss an issue. It’s cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

A man runs into a bar and frantically motions toward the beer tap and says “Quick! Before it starts!”

The bartender, confused, gives the man a beer, which he quickly downs. He again points urgently toward the tap and repeats, “Quick! Before it starts!”, and the bartender gives him another.

When he finishes that, he says a third time, “Quick Before it starts!”, but the bartender had had enough.

He says to the man, “Before what starts?? But first though, are you going to pay for all these beers buddy?”

And the man looks up at the bartender dejectedly and says, “It starts.”

This was a joke told to me 21 years ago, by a Russian guy in an Irish bar in Japan. I remember it because of that weird context, and also because the Russian guy was my enemy.

That sounds made-up. But the details are true, except maybe the part about the guy being Russian (he might have been Ukrainian), and of him being my enemy (he was more like a rival).

Unauthorized Products, Inc.

I had been sent to Japan on a somewhat desperate mission. We had built a monolithic beast, and it was getting out of control. That image fits nicely into a Godzilla theme kind of deal given the Japan trip, but it was a real matter of life and death for the product we had been working on.

We were a remnant of a small startup buyout by a much bigger company, in an east-meets-west coast affair. Initially our Massachusetts outpost continued to function as a small company, not clued in to the goings-on of our California overlords. And they were not clued in to ours.

Our management team had worked for big companies before, but had little experience navigating the political waters of a large organization in their new, elevated VP roles at the new one. So when disagreements arose over the role our group should play as a new division of the company, our management did what they always had done: they just went their own way.

We had created an entire product without permission from our management, as it turns out. Quick. Before it starts.

A sort of desperate fight had been going on between our founders and that of the company that had absorbed us, to attempt to retain control of new product development. Our new overseers wanted to integrate our technology into existing products. We wanted to build a new one, to replace the existing product.

That kind of talk though did not sit well with our remote management, and proposals and meetings about it were getting nowhere. So we just built our product anyway, without telling them. And then our CTO and I flew to California and presented it in front of the company’s entire sales staff at the annual sales kickoff meeting.

The management was mortified. The sales staff was excited. We left that strange trip (which kind of deserves its own story, probably) elated. We had shown a live demo of the new product, doing things that the old one had promised for years but failed to deliver. The salespeople had naturally assumed we had the full backing of R&D management, and that this represented a new direction for the company. They wanted it immediately, and told our upper management as much. So the company R&D leadership basically had no choice, but to let us try to build it.

It was kind of a genius play, for dealing with the roadblocks we faced.

But fast forward, six months or so. Whatever had transpired between our founders and the company management in terms of fallout for our R&D product coup was not immediately obvious, to me at least. What was obvious though was that our fragile little prototype product was not holding up well to real-life customer demand pressure. The few installations of it were at projects in large Japanese semiconductor companies, and a host of issues had cropped up. Nothing really worse than the issues the companies other, main-line products, mind you. But being an unproven thing, doubts had been raised, and our product was now in serious jeopardy.

Strange Engineer in a Strange Land

Our former CTO who had started us on this unorthodox product journey had left the company to retire on his startup success in those intervening months. So I was picked as the sole R&D representative of our product to be sent on a trip to Japan, to visit both existing and possible future customers and convince them to adopt it. I went along with our east-coast Marketing guy Rich, and his west-coast partner from corporate, Larry.

Also along for the trip was a senior R&D architect from our west-coast headquarters, Mark. Mark was the maybe-Russian joke-telling guy from the start of this story, and was also a vocal critic of our product and R&D group’s efforts. He had worked on a similar product prior to ours, that never went anywhere. But he continued to advocate for developing it, instead of backing our product and approach. We kind of suspected he was secretly still working on his version, but he had nothing to show on this trip and was ostensibly sent along by our central management to collect customer requirements for future products in the same area.

Next thing you know, Rich and I are wandering around Tokyo Station in the middle of the night, dragging our luggage sleepily after a 17 hour flight and trying to find our way to the right floor, right platform, right train to get us to a much-needed bed.

There is a certain kind of stamina that one acquires when they do these types of trips frequently, it seems. One I lacked, being an R&D guy who usually stayed at home, and I struggled to keep up. I had also foolishly brought along a laptop briefcase, thinking it was going to set the right impression given the formality of these meetings — suits were not optional here.

But Rich and Larry were both sporting backpacks, which are kind of the norm now for travel gear, but not in 2000. When I asked if the customers would find them to be un-business-like, they shrugged and said, they just get tossed under the table as soon as you enter the room so no one cares. So I lugged around my big heavy 2000-era laptop in this briefcase all week with aching arms, watching these guys basically hike through Japan, comfortably geared up with laptop backpacks.

Our week was chock full of customer presentations across multiple cities, often with two visits per day. We soon met up with Larry and Mark, who flew in from California. We were also joined by Leo, our Irish ex-pat Field Engineer who now lived in Japan, and our local sales account manager, Okamoto-san.

Everyone here seemed to know what they were doing, except me. Mark knew which sidewalk vending machine dispensed the hot coffee-in-a-can he wanted, and Rich was able to find the local Starbucks every morning for his Cafe Mocha and two chocolate croissants, which he referred to as his daily “happy moment.” And everyone was better at finding and eating fish, seeing it was not a favorite of mine.

Larry was perhaps the most seasoned traveler among us and had mastered the art of petty embezzlement. I watched him buy a $70 fountain pen in Akihabara and proudly announce it was going to be expensed as “lunch”. When asked how he planned to get away with that, he showed me the receipt for it, which was entirely in Kanji. He said it looked just like lunch to him, and probably also to our engish-speaking Accounts Payable department.

It seemed pretty petty to me at least, given how much I assumed he was making. But I had bigger concerns, about how to present our product to customers. I was not given the job of showing slides, but to do a more impromptu whiteboard discussion of how it worked, kind of a “straight from the R&D guy” kind of thing.

At one of our first meetings, I stood at the front of an expansive conference room in the mid-century-modern office building of an electronics company in Shin-Yokohama. It was full of engineers and engineering managers who had come to hear about our latest product offerings, and I had been sent up to the front as kind of an intermission between slide shows.

I was drawing this architectural diagram of our system, trying to add in enough details to it to be convincing, without being confusing to people unfamiliar with it. As I awkwardly tried figure out a way to do this, Rich whispered to me from the front row.

“Draw bigger.” he said. I stepped back and realized my diagram was sized for an office, not a huge conference room, and nothing I was writing could really be resolved from the twenty or more feet away everyone was. I erased it, redrew, explained, took questions. It seemed to go okay.

In the back of the room though, Mark lurked. He did not present a thing, but did ask a lot of questions when we got to the Q&A. They were the kind of questions someone who is plotting a coup of their own might ask.

Bar Room Diplomacy

As we went to more sites, I got better at it. By mid-week, I was feeling pretty good about the customer responses we were getting, and Rich and I were discussing newly requested product features as we rode the Shinkansen bullet train, rocketing us down to Osaka at 200MPH for yet more meetings.

I had even gotten past my killer jet-lag, and could almost keep up with Rich and Larry, who were as far as I could tell business trip robotic systems who never really seemed to get tired. The customer visits down in Osaka seemed to go even better than the earlier ones, and Leo and Okamoto-san seemed happy enough about our performance on the trip.

We all went out to an Irish bar in Osaka our Field Engineer Leo liked to frequent, for an end-of-trip drink or two. Stepping in there was a sort of cognitive dissonance one can only arrive at when the immersive world of Japan suddenly vanishes before you and is replaced by Ireland. Leo introduced us to his buddies and we ate and drank and eventually got to joke-telling, and Mark shared the one in the opener of the article.

For a moment there, I thought maybe we could bury the hatchet between East and West, and I was not thinking Japan vs. US. I was thinking about Mark and I working together. I kind of extended an olive branch that night, and said I didn’t want us to be rivals. Not sure what I was expecting as a response, but I really did not get it. Mark just made some kind of snide comment about how we should have made a better product and then we wouldn’t need any help from him.

I was disappointed, but not as much as I would be later in the evening. We went back to the hotel, had one more drink at the rooftop bar overlooking the city lights, which featured amazing views and terrible Margaritas. (To this day, I don’t know what possessed me to order a Margarita in Japan).

Leo and Okamoto-san stopped by my room after that, as it was time to say goodbye. We talked for a bit about the week’s events. Okamoto-san was tipsy, and before leaving came stumbling out of my bathroom, closing the door behind him. “Don’t go in there.” he cautioned sternly. And then with a smirk, said goodbye, stumbled out into the hall, and hopefully into a taxi somewhere.

Leo and I laughed, and I remarked that it was the first time all week I saw the casual side of Okamoto-san. We had gotten along well, and it seemed to me like he was on board with our product. But Leo shook his head, pained look suddenly coming over him.

“Okamoto-san is not going to recommend your product to the sales force.” he admitted.

I was stunned, seeing how well things seemed to have played out with our customers. “What?? Why? Is it because of the bugs? We are working on those..” I started on.

“No. It’s because he doesn’t think it will be around in six months. He doesn’t think it has the backing of management.”

I really had no reply to that. Leo was of course correct, it really didn’t have Management backing, even still. And Mark’s presence on the trip came clearly into focus for me at that moment. They were going to build something else. And there was no way we were going to be able to hold onto this thing.

Back To Reality, Oops There Goes Gravity

I arrived home feeling somewhat defeated, but at least had a great non-fish meal. We continued to work on the product for months after that trip, but indeed it did not ultimately succeed in Japan or elsewhere, and the entire thing was canceled within six months. In its place, a new product was added, designed by Mark and a small R&D team on the west coast. He had quietly been working on it the entire time, but with little fanfare. No splashy demos. No customer pitches. He had management backing, and when it was ready, only then did it get shown to people. And the Salesforce started selling it.

Mark was an extremely smart guy but very hard to work with, with way too many Machiavellian tendencies for my tastes. His product made it further than ours, but was also replaced a few years down the road by yet other software. I admit to not being a huge fan of Mark, I think if we had collaborated maybe we could have gotten it right the first time.

But his technique for getting a product to market successfully at least is something I admired, and try to follow to this day. It’s called Internal Success before External Success in my book, and it means simply: get your shit together before you try to sell it to someone. Maybe the internal success you need to achieve is technical. Maybe it is political. But whatever it is, do it first, before expanding your reach.

I recently had the pleasure of working on a very successful product feature and was asked for a presentation I did to include a slide showing positive customer quotes. Also on the slide was to be a list of positive quotes from our internal Field Engineers who had gotten behind the product idea and who also had good things to say.

I put our Field Engineer quotes first on the slides, the Customer quotes second.

And when I presented that slide, I said it was arranged in order of importance. I’m not sure everyone understood why, though.

Explore Further

• 137 Bar Jokes

• Tips for Getting Over Jet Lag

• Tips for a Good Whiteboard Presentation

Next Time: Why would anyone design a nine-bit CPU? If you find out, let me know. Mine is in progress. Nerdy and needless exploration over well-traveled territory, and ruminations thereof in part one of a (hopefully-multi-part) series: Holy Nonads, a Nine Bit CPU!

The Mad Ned Memo is published on a (more or less) weekly basis and features nerdy tales and discussions of computer technology. It frequently trends on technology-loving social media sites like Reddit or Hacker News, but you don’t have to chance missing out on an issue if you subscribe! It is cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

I spent a lot of time in the late 70s and early 80s crammed into small computer rooms. It was an era when computers needed a room of their own, and if you wanted to use one, you needed to be in it as well. I found that invariably, there was also a middle-aged chainsmoking woman in there somewhere with you too, doing data processing.

I don’t know if the job attracted middle-aged chainsmoking women, or if the job slowly morphed non-smoking young women this way over time. Whatever the case though, I endured a lot of secondhand smoke while learning to program. And so did the computer systems.

Here is where my first encounter with computer Field Service happened. One day in high school while I was in the computer room trying to extract Snoopy banner printouts from our PDP-8, a DEC Field Service guy showed up, with a strange device. It was like a mini washing machine, full of some kind of solvent I hope was not too cancer-causing. He proceeded to grab all of our RK05 disk packs, and take the covers off them. One by one, he dropped the raw disk platters into this machine.

And it washed them.

I was amazed. And I still am. I asked about it, and he said that there was a lot of smoke and dust that built up, and that affected the life of the disks (he may have given a side glance to Mrs. Sutton, who was in the corner puffing away as she typed on the school’s very dated IBM 029 card punch).

The washing machine spun and sloshed, and then the clean, dried disk was removed and put back in its case. He assured me they would work just as before, and as far as I could tell, they did. (It was after all a time before disk heads flew microns above the platter, so you could get away with exposing a disk to a dusty room. )

But I was struck by the confidence this service guy had with what he was doing. I had always considered our PDP-8 to be this priceless jewel, sitting cloistered in its own temple. You handled it with kid gloves and most often, you did not handle it directly at all. But the service tech would come in and pluck this machine apart with ease, doing what seemed to be dangerous things.

On another visit, the service guy came to check a problem we had with intermittent crashes. He brought his oscilloscope, and his own diagnostics RK05 disk. I was fascinated. Seeing the wires and boards inside the machine, watching the glowing green waveforms, and by his alien software that had direct control of the machine, without any of the familiar OS environment around it.

Experiences like this have a lot to do with why I became an Engineer. Peeking at what’s behind the curtain was always of interest to me, no matter what the device. And the more complex the better. Computers were pretty much the most complex beasts I had ever come across, and I imagined myself as that technician and getting to be the one who gets to take them apart.

It took a few years for me to learn more about the possible careers you could have in electronics and computers, and that one could aim towards a job not just fixing these machines, but designing and building them. I went to Engineering school just because of that interest, with little info on how hard it would be, or how promising a path it could open. After I graduated, I ended up working for Digital building computers, the very same company whose PDP-8 computer I had used in school.

The Inside Story

Once at DEC, my immediate fascination for watching Field Service work dropped off sharply. We were awash in computers there, in offices and data centers and at every site. Clusters of them had been created, and they were now networked and managed internally and somewhat invisibly. Also, we already had our share of hardware adventures in taking things apart and putting them together just as part of our jobs.

I did however enjoy hearing stories about weird Field Service situations. This would be mid-1980s, so no internet yet to spend time on instead of working, but we did have an internal employee networked discussion board system of sorts called “DEC Notes”. DEC Notes was widely used inside the company, and had a huge range of topics to explore, including a discussion from DEC Field Service about strange service calls.

This was a favorite topic of mine to browse. There were perhaps hundreds of stories there, about all sorts of weird and unlikely places customers put their PDP-11s for instance, including inside the bore tunnel for an underground nuclear test chamber. According to the story, that poor machine’s job was to collect as much data as possible and send it out in the few milliseconds between the blast and it getting vaporized.

Another one I remember was a kind of mystery story. It concerned a problem with the network at one of the DEC sites going down at almost exactly the same time every night. This had been happening for a while, but got to be a serious problem because it disrupted simulations that were running overnight on a project.

Field Service was called to find out why, and they narrowed it down to a switching system in an equipment closet in the building that kept rebooting. They replaced the router, to no effect. Later, logging and diagnostic software was added to see why the system kept resetting. Y2K was not yet a thing, but the idea that some sort of overflow or clock problem was happening was a leading theory, given it seemed to occur right around midnight.

Finally, in an exasperated and desperate move, a field service guy actually decided to camp out in the equipment closet at night to see what was happening with the router. Right around midnight, the door suddenly opened, much to the surprise of the field service camper. A hand reached in, unplugged the router, and plugged in… a vacuum.

It seems the nightly cleaning crew was in need of a power outlet in that particular stretch of hallway, and had decided to improvise.

Don’t Like It But I Guess I’m Burnin’

It was hard to tell how many of those stories are true, and how many had been fabricated or embellished when you read through all those DECNotes. This next one is a famous (or infamous) DEC Field Service story, and I always thought it was completely made up. But some quick research on it seems to point to enough detail to make it, as the Mythbusters would say, “Plausible”.

The phrase “Always Mount a Scratch Monkey” has since entered the hacker lexicon as a commonly-known meme, but I’m sharing the story of it again in the hope that at least some readers have not heard it. (fully expecting to get comments from old DECies that have though)

This tale concerns a lab involved with research using primates at the University of Toronto, in 1980. The Department of Medicine had been conducting experiments using monkeys, with electrodes attached directly to their brains. These electrodes and associated experiments were run using the department’s new VAX 11/780, which had a superior speed to the older PDP11/05 they had been using previously, and this speed was needed due to the nature of the real-time data collection and processing being done.

The problem was though that the VAX 780 was a very new, and buggy machine in 1980. (Some of the security-related bugs were things I wrote about taking advantage of previously.) At some point, the VAX started crashing, and DEC Field Service was called. They proceeded to check the machine out by shutting down VMS and running a set of dedicated hardware diagnostics tests, that exercised things like the CPU, disk, and memory.

Oh yeah. And the I/O system. That was attached to five live monkeys.

No one had bothered to tell the Field Service guy about these monkey connections, which were normally instrumented to read analog signals from the brains of the monkeys, but were also capable of generating analog voltages as output as well. A feature that was precariously (and as it turns out, insufficiently) disabled on the system.

Diagnostics being what they are, the VAX I/O system was put through grueling cycles of both reading and writing the I/O ports, resulting in voltages far beyond what was healthy being sent to the monkey brains. The monkeys all went through violent convulsions, and three actually died. In the telling of it, the Field Service guy was pretty traumatized and even threatened to call the Humane Society on the lab.

The lab itself seems also to have been doing sketchy if not unethical experiments in general and was later shut down. The whole story is pretty macabre, but as time went by, people (as is usually the case) found some humor in the whole incident.

The correct procedure when running disk drive diagnostics is to mount an unused, “scratch disk”, so the contents of a valuable disk are not destroyed as the diagnostics are run. The Field Service guy had unfortunately not brought a “scratch monkey” with him that day. Advice for that later circulated through DECnotes and beyond, to become the famous Field Service meme.

Take Your Monkey To The Genius Bar

I was going to go on to talk about how you really don’t see Field Service anymore, but I kept remembering how it is still around. The cable guy was here last week fixing my modem/fiber connection, and we need to have someone come and look at our wonky oven control panel someday.

I find it interesting that my laptop is worth more than our oven, yet unlike the oven, it would be really tough to get someone to actually show up at the house to fix it.

I thought about it and finally arrived at this handy algorithm for figuring out if Field Service is still a thing for whatever you have that’s broken:

Unfortunately for those wanting a computer repair guy to come to the house, everything works against you in the flow as computers get cheaper, more portable, and harder to repair. But if you are willing to go for a drive, you can still get yours fixed (sometimes).

Just make sure that if there are any monkeys attached, you show up to the Genius Bar with a scratch one!

…Got a good Field Service story to share?

Leave a comment

Explore Further

• The Scratch Monkey Story

• Shock The Monkey (Youtube.com)

• Adopt A Monkey (wildfutures.org)

Next Time: The author shares a drink with an enemy, makes the wrong friends, and other botched moves in a desparate business jaunt through Japan. Why they keep me at home mostly and not on the road in: Internal Success Before External Success

The Mad Ned Memo has been featured on Hackaday and is frequently popular on Hacker News and other tech-loving sites. But you don’t have to count on coming across it randomly if you subscribe! Get strange and nerdy tales of computer technology and engineering delivered straight to your inbox, and never miss an issue! It is cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

Hello everyone and welcome to a 2022 edition of the Mad Ned Memo! I’m starting the new year by saying “Hello, World!”, which is an activity I have engaged in many times before. Each of these greetings is joyful.

This experience is the time-honored exercise practiced by anyone trying to learn something new — including of course writers of all those starting programs that did nothing more than print “Hello, World!”.

That program in its varying incarnations has probably brought more joy to people than any other. I am sure fans of Candy Crush or Minecraft or Fortnite or something could quibble with that assumption. But given it is a short (usually one-line) program, the joy-per-code-line for the consumer of the output is inarguably off the charts!

Why does it always bring joy? Because it is an affirmation. Creators of programs that produce “Hello World” are seeking answers, and those answers have nothing to do with the content of the message their program produces. It has to do with the process needed to get the message in the first place.

These people are in uncharted waters, looking for any kind of recognizable landmark. You don’t really care what color the lighthouse is when lost at sea, just seeing the light is enough to make you extremely happy.

For some, the reason for being lost at sea is because they are new sailors. For the first-time programmer, any output from the computer that you yourself caused to happen is magical. But even the seasoned pro will find themselves returning to the safe harbor of “Hello World” when exploring new oceans.

Maybe you are a seasoned Python Admiral for instance, but now have just installed it on your new Raspberry Pi and created some cool display thing you are testing. You have a lot of unknowns on your new ship, and having at least one thing you can count on (like a bulletproof program in a language you have mastered) is always a welcome sight, just like it was when you were a newbie.

Hellos From Other Worlds

The nature of “Hello World” changes, depending on the venue. It is not always a simple print statement. I spent some time playing with Unity last year, the powerful game development platform and 3D engine that supports a “low code” development process. Here, even the simplest of scripts can produce amazingly complex results.

“Hello World” on Unity takes the form of displaying a 3D geometric solid of some sort, that you can navigate around with your mouse. This kind of output from a first-time program would have been unthinkable back when I first started Hello-Worlding (and not even possible, given the hardware available.) But given all the software capabilities already baked into the system, this 3D model program really only amounts to a few lines of code.

Still a worthwhile exercise to type it in. Even though it is not much code. And even though I’ve written lots of bigger programs before. Because although the program script itself is simple, Unity is not. When I finally got my cube to display so I could walk around it, I was pretty happy — because there were many new concepts and unfamiliar parts of the environment I had to learn just to get to this simple display.

I used to wonder if the modern young programmer of today would necessarily need to start with a Unity-like “Hello World”, when learning to program in order to be satisfied. After all, simple printing of text to the screen does not hold the same wow factor it once did.

I learned eventually that this was not really the case. I had the opportunity to teach a few people in their early 20’s how to program in the past few years - all of which had never written any code before. We started with a simple Python “Hello World” example — and I was prepared for them to be somewhat disappointed in the limited scope of their first accomplishment once they ran it.

Instead, when a student of mine ran their first “Hello, World” print program, I saw their eyes light up with delight. Delight that what they had told the computer to do had happened as instructed. Even in its simplicity, this was still a door that had opened to a magic world where they had control over the machine, moving them beyond just being a consumer of its output.

The One-Bit Hello of New Hardware

On Christmas of 1979, I opened what is perhaps the best Christmas present I will ever receive, my first computer. This was a budget machine even by 1979 standards, a Netronics ELF II, costing about $150. It featured 256 bytes of memory, a hex keypad, a two-digit LED display, and a single LED light you could program to turn on and off. (See my earlier article, How Many Bits Will Make You Happy? for more on my one-bit encounters with the ELF II)

Turning the LED on was the first program I ever wrote on a computer I actually owned, and doing so was exciting not because of the result, but because of the potential for more. That “more” for me is all the learning and adventures I’ve had for the past 40 years or so.

The blinking LED is also often the “Hello World” of hardware design. Getting a single bit of output to happen on new hardware always takes me back to that Christmas in 1979, in the same satisfying way. I have experimented with microcontrollers like Arduino, and that red LED coming on when I connect it to some pin of the board and test by driver code was a fantastic experience. Same feeling happened again later, when playing around with Raspberry Pi boards, and trying to get a piece of hardware to work with the GPIO outputs.

In one case though, it was turning an LED off that was the holy grail. When I worked as a hardware engineer in the Workstations group of Digital Equipment Corp., we had a new machine we were bringing to life, the AlphaStation 600. I had designed the motherboard for this machine, and in general it was going OK.

But the built-in floppy drive was acting up, and the prominent symptom of it was, the drive’s LED light was continuously lit, no matter what we did. There was a confusing array of permutations involved, because the floppy cable connector was not polarized, and also not symmetric in terms of all connectors on the cable being the same. There was a host and drive position, also the possibility of a “twist” in the cable or not to invert some signals, and also jumpers that could change things on the floppy.

Add to this the fact we were debugging new hardware, and the possibility that I had flubbed something in the motherboard layout and reversed the bus somewhere along the line. We spent days in the lab, swapping this and that, reversing things, changing cables, with the floppy LED frustratingly on all the time.

I eventually got to be a big enough delay that our head architect for the group was assigned to help figure it out, and we began an in-depth mapping of every single point along the chain, with lots of complex whiteboard drawings. Several days of debug later, the floppy relented, and the light went out. I’ve never been so happy to see an LED turn off as then. The contents of the whiteboard in the lab were erased, and replaced with the phrase:

“There is a light at the end of the floppy tunnel, and it is always on.”

No one knows who wrote it. (ok, everyone knows it was me)

Hellos for the New Year

This Christmas I revisited my “Hello World” LED lighting experience. For reasons that have yet to be justified, I bought myself this little FPGA board (this is a programmable hardware system that allows you to create your own gate logic).

I can’t really tell you why I bought this. The number of applications that need an FPGA solution, versus using something easier to work with like a Raspberry Pi, are fairly small. Usually things that require hardware speeds beyond what is achievable with an embedded processor. I have no such need or application, and in terms of experimenting with cutting-edge technology, this board would not even qualify, because it is over 10 years old.

What it does though is put me squarely back in touch with my hardware design roots, which I do like to revisit from time to time. Maybe it was an attempt to recapture that 1979 feeling, I don’t know. But I can say that when I wrote my first Verilog program for this board and downloaded it to run, it was pretty satisfying to see, once again, the little LED light start to blink.

I spent some good times debugging well-travelled circuits, like the 7-segment hex LED decoding in the picture above, which should be displaying “DA” but has a bonus segment lit.

I’m hoping to have more to say about this project later, which I have called QIXOTE, a reduction of / reference to Don Quixote, owing to it’s windmill-jousting nature. I think its a chance to veer of the normally travelled paths of using standard, already built stuff and try some weird experiments of sorts, but we will see. I think in the process there will be a lot of “Hello, World” joy as I try to figure it all out.

I am interested though in your “Hello, World” experiences - what things have you started with that are similarly simple, but brought you a lot of satisfaction once working? Tell us about it. Doesn’t have to be hardware or software, by the way. I can imagine someone’s first accordion tune would qualify!

Leave a comment

So, Happy 2022! Hope everyone is planning their own nerdy adventures this year. If not, I will have you covered.

-Ned

Explore Further

• “Hello World” in every language (helloworld.org)

• FPGA 101

• Accordion for Beginners

Next Time: A look back at the long-lost days of Field Service, when a guy came to your hardware, instead of your hardware going to the guy, or the trash. Roaming technicians and dead primates coming up in: Always Mount a Scratch Monkey!

The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

The Mad Ned Memo started as my pandemic writing hobby last April, and I really had no idea then if anyone would be interested in reading any of the nerdy content I wanted to serve up. It’s been great to see that some people at least are interested in these articles, and surprising to me always that you allow me to invade your inbox on a regular basis with somewhat random thoughts.

I occasionally write something that is what I call a “Negative Subscriber Article” — where more people decide to unsubscribe after reading a weekly post than subscribe. Honestly, this was a bit upsetting when it first happened, but I do understand that if you signed up after reading some nerdy thing about old mainframe memories, then the next thing you know we’re talking about Agile development, you might say “This isn’t the content I was expecting.”

These topics all fit together somehow in my head. But if it seems somewhat unfocused week over week, I’m sorry; I guess that’s the “Mad” part of the Memo. I’ve since come to terms with the Negative Subscriber thing. I now think of it as an alchemical process, refining raw materials into a precious filtrate. Or is it a precipitate? I always was bad at chemistry. Also, I need a marketing guy, probably calling your audience a “precipitate” is not wise.

But anyway - thanks so much to everyone who signed up this year! I’ve enjoyed hearing your thoughts, making some new friends, and all the discussions and comments we’ve had here.

Now, let’s take a quick look back at what’s been going on since our last Rewind.

Night of the Living Code

I’m retroactively angry I did not choose this as the title for my article about bringing my long-dead code for the TRS-80 back to life. The Dead Code Diaries was a catchy title. But undead sells better. I chose the title though because I thought it might be a series, where I cover bringing back to life some other old I was involved with, like the multi-player Rogue game I mentioned in the Screwing Around at Work post.

Still nothing to write about there, but my friend who owns this code did, at my urging, manage to get part of this very old code base to compile. I’ll keep on that.

We got a lot of interesting comments from people though with dead code of their own, both on Hacker News and in the comments section of the article. I was especially envious of the guy writing TRS-80 code who had Forrest Mims as his neighbor, an engineering legend I mentioned in my August Radio Shack article.

My Accidental Guest Stars

The top comment on that dead code article in Hacker News was a guy who mentioned still having code from 1977 running. It turned out to be none other than Walter Bright, computer wargaming pioneer and inventor of the mainframe game Empire, and the D programming language. I asked Walter if he would be interested in doing an interview, and he not only agreed to that, but also to do an AMA on Hacker News. This was a really popular interview with thousands of views, and hundreds showed up to talk with Walter on HN.

That same article spawned another accidental meeting, with computer text adventure legend Scott Adams. I was trying to email the people at the TRS-80 fan site trs-80.com to thank them for all the great things they did to preserve that machine, but accidentally emailed Scott who was on the email links list.

I wouldn’t blame him at all if he still thinks that was a ploy to get him to come to an interview, but it was really a dumb (yet happy) mistake! Scott was very gracious and agreed to an interview and AMA.

Thousands read the article and we had a great discussion about the old days of PC gaming, as well as looking at what he’s been up to recently with his new company, Clopas.

Really great discussions here, and really nice to make friends with some people who were positive influences for me in my teen years!

Startup Advice

Also in the Memo over the past few months, a bunch of articles relating to business topics. I shared my adventures transitioning from a large company to a tiny one, and how you both have to do stuff yourself, and get to do stuff yourself, in the process.

This article paired nicely I thought with another recent post, about how I miss working in crappy workplaces. It explored some let’s say ‘non conventional’ facilities I worked in (including that startup), and how it secretly made me happy to see how appalled some outsiders found them. This resonated with a few people, because I ended up getting several replies from others who also worked in dumpy places they liked, but which turned off visitors.

There was also a little frightening look at the Dobsonfly Larvae in that crappy workplace article. Sorry to bring that up again. I’m still processing that I think, give me time.

Then there was my cautionary tale about what happens when an R&D group has a lot of its design responsibility removed, and is asked to just implement things others created. This wasn’t a huge hit but I did find it interesting that at least a few other people found themselves in similar predicaments - with similar results.

This one also could have made a good horror-themed article, I should have moved it to Halloween week. Live and learn.

This brings us up to last week, where I shared my maybe unconventional thoughts about why crappy agile is good. I heard from a few people but am still very interested in what development processes people are actually using these days, and how they differ from “the book”. Drop a comment!

A Medium of Success?

I may have mentioned earlier that the Mad Ned Memo is also available on the online publishing site Medium - in a slightly different format. I’ve been slowly growing my presence over there, and Mad Ned content has appeared in several Medium publications, such as Index, The Haven, and UX Planet.

But it’s not intended as a replacement for this newsletter, as much as it is a place to write shorter pieces. Things that are excerpted from Mad Ned Memos, cut material, sneak previews, and articles that don’t really fit the theme well, like that time the cops forced me to buy monster cable. No real publication schedule, which is also nice from my perspective because I can put things out there when time permits.

If you are already a Medium member and are interested, you can check me out there at: https://medium.com/@mad-ned

I ended up getting my Medium account to post stuff and be in their partner program to make a few bucks, but found it to be interesting to browse content-wise as a reader too. Very short articles there, easy to just munch through like potato chips. A lot of click-baity stuff to be honest but also some good authors and publications too.

If you are thinking of becoming a Medium member at some point, give a bro a referral ! (Medium membership is all-you-can-eat, so you get access to everything there and not just my stuff)

But if it’s not your thing, do not worry — The existing, free, not-always-fitting-in-a-5-minute-read Mad Ned Memo is not going anywhere! I think I’d be frustrated if I had to condense everything I wrote into that short format.

Logging Out!

So that’s the small ad at the end of the mostly-ad-free Memo this week. I’m looking forward to a few weeks off, which gives time for ideas to percolate and bad-for-you food to be eaten.

I’m looking forward though to returning next year to this community we have created together, for more fun. If any of you have thoughts or ideas for what you want to hear more about, hear about instead, hear less about, or comments in general we didn’t get to from previous posts, drop me a note!

Leave a comment

Merry Christmas, Happy Holidays, to all those celebrating them! Peace and all the Best for the New Year! —Ned

Explore Further:

• A Boozy Eggnog Recipe

• 15 Holiday Lighting Hacks

• 7 Home New Years Party Tips

Next Year: The Mad Ned Memo is taking a break for the next few weeks, but returns in January, 2022 with more nerdy tales, interesting computer and game related discussions, unsolicited business advice, and hopefully more guests joining me to talk all of the above! See you back here, then.

The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

There have been a few instances in my work life where I have been vehemently against something, only to later do a 180 and become a big fan, after finally figuring out how wrong I was.

One example that comes to mind was in my days at Digital Equipment Corporation in the Alpha Workstations development group in the early 1990s. This was very much a disruptive time and place to be within the company. We were a brand new division of Digital, and we were pioneering a brand new CAD process for creating our brand new products. And unlike previous development teams at DEC that all used internally-developed CAD tools, we were using third-party, Unix-based tools.

It was my first exposure to Unix, as I and many of the other engineers there had spent almost all of our time using DEC’s proprietary operating system, VMS. Since the company was pretty much counting on the hardware engineers to be able to navigate this new operating system without impacting the development schedule, they sprung for an outside consultant to come in and teach us how to migrate from VMS to Unix.

I remember sitting at this training arms crossed, skeptically listening to the benefits of this alien outside operating system. Everything about it seemed hacky compared to VMS. Where VMS had very literal and descriptive commands like DIR to show a directory, DELETE to delete a file, and SHOW PROCESS to show what was running, Unix had strange abbreviated commands, like ls, rm, and ps. And when the trainer got to grep and awk, I almost lost my shit.

“grep?? What the hell does grep stand for?” I asked incredulously. The poor trainer did his best to explain that the point here was to create simple and speedy-to-use commands that could also in fact be chained together in powerful combinations. He said it didn’t really matter what the commands were called, because you would memorize them and they would become second nature, just like the VMS commands you are used to.

I didn’t buy it in the least, at the time. But he was definitely right, of course. In retrospect, I was a bit scared of the change, and was probably also intimidated by the thought of suddenly going from expert OS user to novice. I came around once I started actually using Unix. The more time I spent with it, the more I realized how much I could do with it compared to what I was doing with VMS. It was in fact hacky, as I had originally suspected. But therein lied its power.

Fast-forwarding about 20 years or so, I once again found myself on a development team caught in a sudden change of wind direction. This time it was a software development situation, and our management had announced we would be migrating our development process over to Agile.

I like to think I’ve always had a kind of pragmatic approach to building things, one that skips rules that are impeding progress when necessary. But I had spent years working in big hardware and software teams, and it had taught me to expect there to be a pretty rigid, waterfall-style development flow.

The next thing you know though I was sitting in an Agile training meeting, arms again crossed, listening to heretical talk about how we didn’t need to plan things out six months in advance, and could just do it in two-week “sprints.” It was Unix vs. VMS, all over again. No weeks writing detailed specs, no spec review phase before development starts. Insanity!

When I had started at Digital, I worked in a mainframe development group. Spec reviews were sometimes held between the hardware team, and the VMS team that was writing the operating system support for the new machine. These reviews were attended by dozens of people from each team and took a full week. They were held at hotel event rooms and featured fully catered lunches, and the VMS participants had to drive almost an hour to get there to attend.

This ridiculously-expensive development process soon went by the wayside, and while I do miss getting the free lunch, it’s quite obvious that there is no reality in which that was an efficient use of everyone’s time.

When I develop code today I am still a very big fan of planning things, and documenting what was done. But gone is process of spending days and days writing monster specs that detailed every aspect of a new product or feature.

I wrote a lot of huge design specs in the past, but almost always was left with a sense of disappointment, when the reviews of them were either poorly attended, or resulted in few meaningful comments. The honest truth was and is, people just don’t have the time, and maybe attention span, to pore through page after page of detailed specifications for an entire product or large feature in a single sitting, or event.

Everything new starts out imperfect and therefore does need to be reviewed at some point, and will get its chance either via some internal process to a company, or later by its customers. That latter situation is not usually the one you want. Finding problems is less expensive earlier in the process, and some kind of design review before implementation still seemed like something we could not do without.

Mr. Smith Goes to SCRUM School

This was very much on my mind when we transitioned to using Agile. It seemed to me that we had abandoned any sense of product planning, and in trade, management would attempt to exercise a level of control over scheduling low-level activities like individual feature development that was neither practical, nor necessary.

Many people on our development team were privately unhappy as well, but said nothing. So as a project lead, I was the vocal skeptic of the transition, figuring it was my job to raise concerns. In response, our management used a classic trick from the management playbook, which was to put the strongest opponent of a thing in charge of it. I was told I was going to be the Scrum Master of the team, and I was sent off to Certified Scrum Master (CSM) training.

Not going to go into too much detail here about Scrum or other Agile processes, since most either know what it is at this point, or don’t care. But a very brief description of my new job role would be, I was the foreman of our agile development team, and it was my job to make sure people were able to get their tasks done on time, over the two-week sprint cycle we now worked in.

This sounded to me then and sounds to me now like running a job shop, where workers are just cranking out things in assembly-line fashion. But the devil is in the details. What I learned after going to Agile school and then also putting it to practice for several years was that it was certainly possible to create a poorly-designed product, implemented by a micromanaged development team. We had some low points approaching that at one point.

But I also learned it was possible to adapt the Agile process to work for us, keeping the good parts, but kind of ignoring the stuff that didn’t make sense.

When I was at CSM school, the trainer there warned against just this. He said that people most often failed when trying to apply Scrum to their development teams because they were practicing “CRAGILE”, or “Crappy Agile.” A situation where a development team practiced Agile in name only, but only followed a select set of practices and not all of them.

An example of that might be, subverting the idea of breaking long tasks into shorter, achievable ones by creating vague stories like “Development, Part 1”.

The issue there would be one of ignoring the idea of Acceptance Criteria, and thus not being able to measure completion. If you can’t objectively actually say whether a story is done or not, you are really just practicing “Agile Theater”.

The Things We Left Behind

There were a lot of interesting ideas in CSM school I took away, but also to me at least there was a certain sense of over-zealousness about all the Agile development process details. I found myself among others in the class who were primarily full-time project management people, not developers. They were all pretty excited about things like metrics and tracking sprint performance and such, for instance, which I was less enthralled with.

Measuring the outcome of sprint cycles is an important part of the Agile process, and the idea is to use what you learned to improve the process going forward. This made a lot of sense to me and we continue to hold Sprint Retrospectives from time to time, which take the form of brainstorming sessions about improving our process, and avoiding going down dark paths like interrogating people about why this or that story did not get completed within the Sprint.

But there were things left behind from the classic Scrum textbook. The trainer who came in to train the rest of our team on Agile for instance was adamant about breaking work down into stories that are no more than a day long. We never even attempted this, it might be the first CRAGILE process change we did. It took a lot of work to convince developers that they could break a project they are working on that would take a month to do into smaller pieces of a few days or a week.

Breaking it down further to a day or less would have most certainly resulted in “Development, Part 1” types of stories, and “Agile Theater” to appease the management. The other big issue with such a fine-grained scheme was the amount of paperwork, in the form of entries in the Atlassian JIRA tracking system we were using.

The Agile Tail Wagging the Development Dog

I’m not going to slip into a whole review of Atlassian JIRA. It’s a complex and capable tool, with many features and also flaws. The biggest problem I think we faced with JIRA was making the tool work for us, instead of the other, tail-wagging-dog way around. In our early days of trying to plan sprints, we were very focused on completing all sprint content on time, and also in distributing tasks evenly to members of the team so no one was overburdened or left without something to work on.

It is definitely a “Cragile” alteration to attempt to load-balance all of your developers at the start of a sprint. The “correct” way according to Scrum would be to avoid making assignments of stories upfront, and have people take an available story during the sprint when they are free.

That process did not work well for us though, because we did not have completely interchangeable developers, and the tasks we put on our sprints required a lot of further estimation to be done to get any real sense of how big they truly were. We ended up with a process where we would assign all the sprint stories to people, they would break them down into smaller subtasks with better estimates, and then we’d have a meeting to try to balance out the work.

And that meeting took forever, the first time we attempted it.

Each of our eight developers had several stories, each with several subtasks. Trying to figure out how to add and delete stories and subtasks on and off the sprint, and swap around owners for them was a nightmare. The JIRA system was not set up to do this kind of thing, and was also very slow, which I will charitably attribute to some issue with our server hardware and not JIRA itself. The net result was, it would take us many hours to plan each sprint, working out people’s time on spreadsheets and then making tedious changes in JIRA for everyone.

You would think this should have been a sign we were on the wrong track and we would return to the classic Agile process. But no. A bunch of software engineers have other ideas of their own, often involving coding their way around obstacles.

We wrote a program using Atlassian’s REST API that let us extract all the subtasks for a sprint into a spreadsheet-like program, where we could easily move them around, to other people or sprints. It did all the math about who had how many hours of work in the plan for each sprint, and then let us do a bulk update to JIRA later, after all the changes had been made. Our planning meetings went from hours to minutes. We’ve used that process ever since.

In the end, the process has to work for you and your team, not the other way around. And if you need to ignore some rules to get there, that’s just fine.

Things We Kept

Not everything in Scrum Master Training went ignored though. Perhaps the best takeaway there was about how to run an efficient and useful standup meeting. When we moved to Agile and were told to run daily status meetings, everyone balked. Who had time to go to all these constant meetings? They were supposed to be quick, but ended up running long because everyone wanted to dive into too many details.

CSM school covered things like how to be a ruthless Scrum Master, and keep people from getting off track for too long. We worked on getting everyone on board with just exchanging status and not going too deep. And we got comfortable with sharing if we were waiting for someone, or blocked by something.

After a while, a funny thing happened. We would hold sprint retrospectives, to talk about what went right and wrong with a previous sprint. People started listing “the standups” as an example of something going right, and would even get cranky if we cancelled one.

Because we were getting value out of them. There were many times I would ask a prompting question about people’s obstacles, and someone would say “I’m waiting for Joe to finish his support code.” And then Joe, was at the meeting, would say something like “Oh, I didn’t know you were waiting for me.”

These types of interactions ended up removing delays that in our previous waterfall process, could have ballooned into weeks of waiting and exchanging email.

The Best Worst Process We Have

There were certainly downsides to moving to Agile. We had to adapt to having more informal planning processes, and it sometimes would come back to haunt us in the form of rework. We eventually got better at planning in investigation stories (known in Scrum as a Spike) to help us better estimate work and to work out details that would have previously been part of the Spec development process.

The benefits for our product team over the older waterfall process were pretty measurable though. Things just got a lot more streamlined, and we integrated our product validation into our development much earlier, which had quality benefits for us. Since our product was relatively new and had a small customer base, we really needed a process that let us adapt quickly to changing priorities, and this is an area that Agile excels in.

Hacky? Yes. But like Unix, therein lies its power.

So Agile development has been around a while, but is it here to stay? I’d say it depends on your definition of what constitutes “Agile”. I’ve seen a lot of articles recently about “Beyond Agile” or “Agile Development is Dead” and so on. People are looking for the next thing, and who knows what it will be.

But I would say whatever comes after it is going to be an evolution of Agile not an abandonment of it, because I really can’t see us returning to the highly-structured, years-long development processes I used back in my earlier engineering days.

But… If we could find a way to integrate a free lunch or two into the next development process, I would be on board!

Explore Further

• Unix For VMS Users

• Atlassian REST APIs

• 8 Catering Tips For Your Next Corporate Event

Next Week: Rewind Time, once again. We’ll wrap up the year with another look back at Memos past, with updates and highlights of past stories, discussions, and interviews. The Mad Ned Memo takes a short break after that for a few weeks, but returns in January for a new year of nerdy old computer stuff!

The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

A while back I published an interview with gaming pioneer Walter Bright, which happened due to an accidental meeting in the Hacker News discussion of a different article about TRS-80 game development I wrote. It turns out not to be the only happy accident resulting from that article. After publishing it, I had sent a note to the TRS-80 fansite I used for the article to thank them for their work, and ended up accidentally sending mail to Scott Adams, whose address was linked to the site.

He sent me back something polite, saying he was not in charge of the TRS-80 site, he was Scott Adams, the “Adventure Guy”. After that reply I felt foolish — Because I immediately realized I had mistakenly emailed the creator of Adventureland, widely regarded as the first text adventure game ever sold for microcomputers. Scott’s company, Adventure International, produced this and many other text adventure games through the 1980s, pioneering the genre of Interactive Fiction.

I apologized for my dumb mistake. A day later, I realized I had missed a golden chance to interview one of computing’s early game pioneers. I sent him something again, expecting no reply, but was pleasantly surprised when he not only replied back, but graciously agreed to talk with me about the old days of game development, and what he’s been up to lately. Here’s how that went down.

But first, a word from our sponsor (me). If you would like more nerdy stories, interviews, and discussions of computer software and hardware development over the past 40 years, consider subscribing. Get the weekly Mad Ned Memo delivered to your inbox, cost-free and ad-free! You can unsubscribe at any time.

Subscribe now

MNM: Scott, great to meet you finally, thanks for taking the time to chat with The Mad Ned Memo today! I am very interested in hearing about your current projects, but I thought we would maybe first spend a few minutes to talk about the early programming days. I know you had in the 1970s played the mainframe game Colossal Cave, and were inspired to build something similar for the microcomputer world. Was TRS-80 the first machine you decided to write a similar game for?

Scott: I had been working on computers for a long time before that. Before I had the TRS-80 (which we called an “appliance computer”, because you could buy it off-the-shelf) I had a kit computer called Sphere, a machine with a fascinating history, but not well known. It came out about the same time as the MITS Altair but was far better. Before that, my brother built a homebrew 16-bit computer, my other brother built a “TV Typewriter” for it, and I wrote perhaps the world’s first 16-bit game for it.

MNM: That would be the mid-70s, a 16-bit machine then was way ahead of its time. I had read about you and your brothers building hardware and software together. You had quite a technical focus in the family. Your parents doing?

Scott: They were definitely science-minded. My father was always pushing us, to take honors classes and so on, and my mother was always making sure we had what we needed. She got me enrolled for early admission at the University of Miami, I was going to skip my senior year and go into pre-Med. But I didn’t want to go, I wanted to finish my senior year. It’s one of the few times I ever won an argument with her.

I stayed in high school, and that changed everything for me. The state of Florida had an experiment they did. They put a computer terminal in one of the high schools to see what would happen. It was my school they picked, and I was able to use it to dial into the university mainframe using an acoustic modem. The first thing I wanted to do was to write games. I wrote a tic-tac-toe program for it that let you play against the computer.

MNM: I remember standing in line at the Boston Science Museum in the 1970s to play tic-tac-toe on their Honeywell mainframe. I think it’s interesting how the bar was low for what was considered an amazing game back then, and it made it possible for even a new programmer to make something that could ‘wow’ other people. Today the bar is a lot higher to impress game players — but of course the tools available to write games are amazing compared to the old days. Do you think that is a fair trade, for say a new programmer today who wants to create a game that other people like to play?

Scott: Having the right tool for the right job always makes the job go easier. But it doesn’t matter how many people like your game as long as you like your game, and are getting satisfaction from it. As long as you can be creative and make something the way you want it to go, it’s a win.

MNM: I agree. I always got a lot of satisfaction out of writing games, or even parts of them, even though they didn’t get played by a lot of people. Our history is similar there, but diverges when we start talking about what happened with Adventureland. That game was played by many. I used to have it for my VIC-20, and I recently found the original version again on one of the interactive fiction archives. Can I show you my attempt to play it?

Scott: Sure.

MNM: I died in like 11 turns with zero points. Does that break some sort of record?

Scott: Well, you did get out of the forest quickly, and that’s a plus!

MNM: To be fair, waking the dragon was a bad idea (who knew?) But the game ended there, and it even appears I went to Hell for it. Pretty Harsh.

Scott: Unfortunately it was. I did not give a lot of wiggle room for mistakes, although it was possible to get out of Limbo with a different choice, so it was not necessarily the end.

MNM: I have read some recent discussions about adventure game design and the trend towards avoiding the creation of deep paths that are dead ends. Has this kind of thinking informed your more recent game designs?

Scott: Yes, lessons learned. If you play Adventureland XL, you never have to start over. There is nothing you can do to prevent you from winning the game.

MNM: This is your 40th-anniversary reissue of the game. So is it a complete rewrite of Adventureland, or does it retain some of the original content?

Scott: It has all the content of the original, plus an additional new set of content. So if you want to have a better Adventureland experience, I would definitely recommend the XL version over the original.

MNM: Yeah I think the original probably only really interests retro-nerds like me, who enjoy seeing what was possible, given the severe limitations imposed by those early machines like the TRS-80. I remember it was tough to deal with things like article correctness for plurality (eg: “You can see a trees here”); something pretty trivial to deal with now, but expensive when you didn’t have a lot of memory to work with.

Scott: I actually had a fix for that even back then, but it isn’t in the version on the interactive fiction site I guess. The language I developed for creating these games handled that situation though.

MNM: So when you wrote Adventureland, was the idea to create a home product out of a mainframe text adventure game from the start, or did you write it first, and then decide to sell it?

Scott: With the TRS-80, I was interested in writing a game in BASIC because it supported strings. Whenever I learn a new programming language, I always want to write a game in it to learn it. So I thought about what game would use words and strings, and I saw Colossal Cave on the mainframe. I played it for a week, I was hooked, and I said, I want to do something like that. The business came later.

MNM: What always got in the way of selling games back then for me was the logistics of it all. I heard you had a Radio Shack in Florida order 25 copies of Adventureland in an early sale. We are talking cassette tape here. Did you have some special setup to produce them?

Scott: No I just recorded them one by one on my cassette recorder, I think it took all weekend.

MNM: After that, it got ported to many platforms. I played it on my VIC-20 which could not have been an easy port, it only had a 22 character screen width.

Scott: Commodore asked me to port to their platform and I told them no way, because it didn’t have enough memory. They said “What if it were a cartridge?”, and I said, there’s an idea. I think the cartridges we used were 12K which is a lot more than the 5K or so you had to work with in RAM.

MNM: It got ported to just about every home system then. Was there a “dream” machine to port to, and/or a “nightmare” port?

Scott: The TRS-80 was a great place to start, since it was really a text-only machine, the graphic system was very limited, so text-based games there were well received. The biggest problem I had with machines was their I/O systems. The Atari was an amazing system, but the peripherals, because of FCC requirements, were horrible. They literally had an audio bus to write to the disk drive, so it was extremely slow, but they didn’t want to get into trouble with RF interference.

MNM: Do you still own any of these machines?

Scott: The only machine I currently own is the TI-99/4. The main reason I kept this one is that it runs the game “Return to Pirates Island 2” that TI had me write specifically for them. It is a text adventure with graphics, and I think maybe one of the only cartridges that had graphics in a text adventure.

MNM: Fast forwarding a bit, there was a long span of time between Adventure International shutting its doors in 1986, and the start of your new company Clopas LLC, in 2016. What’s it like starting a new company after 25 years?

Scott: It’s totally different the second time around. Different challenges, and rewards. I believe the reason I am doing it this time is because God wanted me to, not because of financial rewards. I think God wants me to use this gift in this area towards His glory, and something for him is going to come out of it. And I’m OK with that.

MNM: I had lost track of you and your work over those 25 years, and I only recently learned for instance that you were a devout Christian, and that the idea for Clopas came up at the Christian Game Developer Conference (CGDC). In truth, I did not even know CGDC existed either. What would you say is the reason we need a separate venue for Christian gamers such as the CGDC, apart from say the mainstream game development world?

Scott: I’ve been to both the Game Developers Conference (GDC) and CGDC. GDC is primarily self-exultation, and trying to make money. That’s the basis of GDC - who’s the biggest and who’s the best, and how do we outshine our neighbors. CGDC was more about everyone coming together to help each other, with what they are doing. It’s just a totally different flavor.

MNM: So would you say there’s a difference in moral framework or bearing between the two?

Scott: Yes, certainly.

MNM: What then constitutes a “Christian” game? Is it one made by Christians, made for Christians, or is it about the moral standards the game abides by?

Scott: I don’t know what a “Christian Game” is. Were my classic games “Christian” games in content? No, they weren’t. Was God using them to uplift people? Yes, He was. So were they “Christian Games”? I don’t know. To me, any game God can use in His glory to uplift people and is a positive, to me I guess you could call that a “Christian Game”.

MNM: So at least some of my readers would not identify as Christian. I would think though many would be interested perhaps in a game considered “Uplifiting”, so long as it was not something really geared just for a Christian audience.

Scott: Yes. For instance, I wrote a game called “The Inheritance”. This is a game that introduces Bible ideas in the story, but is not necessarily a “Christian” game.

MNM: Well if the content is primarily Bible-based, some may debate the idea that it is not Christian in nature. But the question for me would be, would someone who does not identify as Christian enjoy playing that game?

Scott: I’ve had atheists for instance play the game, and tell me it was enjoyable, they liked the story and the puzzles. It was not a game that beat you over the head to convert to Christianity or something.

MNM: So it sounds then like the overall mission of Clopas is to provide games that as you say are “uplifting” and avoid glorification of violence and doing evil. These are kind of what used to be called “Family Values”; it was a term when I was younger I honestly can say was triggering for me as being a censorship issue. But after having kids and getting older, I see another side, of perhaps wanting some game content that you don’t have to worry about your kids consuming.

Scott: Clopas is not a Christian company writing Christian games, but we are a company of Christians, and we do believe everything we do should be uplifting, to God’s glory. So that’s the only rule, and it means our games need to be family-friendly. If a kid wants to say play one of our games with his Grandmother, there’s nothing problematic they would worry about.

MNM: You’ve got an interesting family-friendly thing going on now with creating hybrid graphics and text adventures based on licensed content from the Redwall series of books. This seems like a really rich world to explore.

Scott: Yes we have a few games there, and also we are aiming for a market for an underserved market, and that is “no graphics, no text” versions that are blind-compatible. You can play one of my games, Escape The Gloomer, on Alexa. Unfortunately though when you tell Alexa you want to play “Escape The Gloomer” it says “Oh, you want to groom your dog?” and it’s difficult to get Alexa to bring the game up.

MNM: Maybe Amazon could do something there to train it better.

Scott: I’ve worked directly with Amazon on it, but so far it’s still an issue.

MNM: Hope it gets straightened out, and I hope the no-text, no-graphics game series takes off for you, because it seems like a really good idea, and like you say, helps an underserved market.

I’ve got so much more to ask, but I think it might be a good time to wrap up. Let me ask you a question that maybe a younger interviewer might not ask you. You and I are old-timers in the computer industry, and being one I sometimes wonder, are we going to be writing code in “The Home”?

Scott: I have no idea. Programming is a creative mode, God gave us these gifts, and my creativity tends to come out when writing games. So if my mind is still active, I think I’ll be doing it. I’m not one to just sit there and watch TV for the rest of my life. I do like playing games too, but when I start playing games I begin to think I could be using time to write one instead, and that is usually a lot more fun.

MNM: Thanks so much Scott for taking the time to talk with me. I have on my “to-do” trying out Adventureland XL for one. I will try to not wake the dragon this time.

Scott: You can do whatever you want in that game. Just don’t give up and start over, keep moving forward!

MNM: Good advice for us all!

Explore Further

• Adventureland XL on Steam

• The Christian Game Developers Conference

• Team Clopas on Patreon

• The Interactive Fiction Archive

Next Time: Much has been said about the Agile development process, but not so much I guess to prevent an old Waterfall guy from going on about what happened when he was drafted into becoming a Certified Scrum Master. Making Agile work for you coming up in: Good Cragile: Crappy Agile That Works!

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

Sorry for the off-schedule Mad Ned Memo, but I wanted to let everyone know about a very special post coming up this week: an interview with computer gaming pioneer and father of Interactive Fiction, Scott Adams.

Scott’s company, Adventure International, produced interactive text adventures for just about every home computer platform from the late 1970’s through a good part of the 1980s, and kickstarted a game genre that has entertained countless people since.

Scott is still writing games 40 years after publishing his first one, and discusses his mission to create “Uplifting Games” via his new company, Clopas. I was very happy to be able to meet Scott and discuss these things, and I’m excited to share our chat this week with you.

And if you are interested in talking with him about his past work or his current projects yourself, we are also planning on holding an AMA on Hacker News on Wednesday! Check out the comments section of the article in my email or on my site for a link to the Hacker news discussion thread on Wednesday morning, or look for it on Hacker News directly, and post some questions for him on the thread.

Should be fun, see you all then! In the meantime, think of good things to ask Scott, and feel free to share this news with your Text Adventuring friends!

-Ned

Share

Digital Equipment Corporation was my first company, and I always thought of it as this great mothership, a giant technology behemoth sailing through the vast business universe, crewed by 140,000 hands. But the mothership, while formidable, became an increasingly attractive target for smaller, nimbler craft. Caught in the crossfire of the powerful new hardware its enemies brought to bear, Digital eventually lost structural integrity, and broke apart.

Somewhere in the middle of this circa 1997 space opera, I decided to jump ship. The glowing, burning chunks of the company were being boarded by outsiders, and my immediate manager whom I really enjoyed working for had already evacuated. His replacement was a generic middle-manager named Dennis — An Alien who came from somewhere in the WinTel galaxy and who was keen on converting all of our Unix CAD tools over to Windows NT.

When I pointed out how much work would have to be thrown out and then redone to accomplish this, he said something like: “I’m not trying to pull up your carrots, Ned.”

That’s when I knew it was time to leave. I’d had enough of the chaos and destruction going on, and I certainly was not going to let Dennis the Alien anywhere near my carrots. I called up my old manager and arranged for an interview at the place he went to, a small startup with 24 employees. I had not interviewed anywhere in 11 years, but in spite of some rustiness, did OK enough to get the job.

If there were any doubts about whether it was time to go, they vanished during my exit process. Dennis was not around the day I gave my notice, and so I went instead to our division director Fred, whom I had worked with for a long time. When I told him I was leaving, there was no shocked “Oh no!”, or attempts to lure me back. Not because they didn’t want me. Because I was probably the 5th person that week who had given his notice. Fred just nodded, and sighed. I was pretty sure he was eyeing the escape pods as well.

When I went to my exit interview, Susan the HR person asked me where I was going, and when I told her it was a small startup run by ex-DEC people, she asked me if they had any jobs there. I was kind of amused that the person conducting my exit interview wanted to come along with me, but I had to tell Susan that sadly, the escape pod only had room for one.

Stranger In A Strange Land

I set down on a small remote planet. If we were going for a Star Wars analogy, it would be more of a Dagobah situation than Tatooine, my admired and often-mysterious old manager standing in for Yoda, and the site as mentioned in another post looking a lot more like a swamp than a desert. The key characteristic though here was: small. There were probably DEC cafeterias with more employees than this company.

Small was not something I was really prepared for, after working for a giant company for so long. I of course knew what I was getting into at some level, being employee number 25 and all. But it’s different than you imagine though when you actually start interacting with the colonists of a tiny new world. I found myself shifting from fighting alien invaders, to becoming the alien myself. And here I had to relearn some basic customs, a couple of which I had taken for granted as being unchangeable.

Lesson 1: You Have To Do Everything Yourself

One of the first denizens of this new land I met was a guy named Marv, who was the IT department, along with being in charge of other infrastructural things like programming the dated telephone system that our CEO had picked up at a surplus sale. I sat under a skylight that leaked during rainstorms, and one day I looked up to see Marv above me with a green tarp, on the roof doing emergency building maintenance. (Thereafter the office area had a green, undersea vibe to it.)

Marv was a busy but efficient guy, and by the time I arrived had already set up my user login, which followed a first-initial, last-name convention. In my case, it made my login ‘nutzig’, which I had some reservations about using as my company-wide ID. Marv was reluctant to have to go change it, and he tried to sell it to me. It’s great, it’s fun, we can call you “The Nut”! he offered. Luckily my boss intervened to have him change it before he wore me down.

After that, we went on to setting up my Unix workstation, sadly a Sun machine which would have been heresy to use in my previous DEC workstation days. It was different than I was used to, and I went to Marv constantly to ask him to help configure it to my liking. This was normally a function of a much bigger IT department back at Digital, and the fact that Marv had given me root privileges to set it up would have been unheard of in my old job.

Marv seemed a bit irked that I kept asking him for help rather than figuring things out on my own, and I had to shift my thinking from “If it doesn’t work, have IT fix it” to “If it doesn’t work, try to fix it yourself first.” It was part of the first lesson of Small: self-sufficiency.

Marv stopped by the next day and asked if everything was working OK. I told him it was, to which he replied: “Good. Now start fuckin’ producing.”

This is when I knew I really liked Marv a lot.

The self-sufficiency lesson for me soon extended beyond IT matters. I found myself being sent on customer visits, sometimes solo, to see about issues they had. Such a thing would have been unheard of at DEC. In my 11 years there I directly interacted with customers perhaps twice, and each time, with a squadron of support people.

I remember going over to (soon to be experiencing hull-decompression also) Data General to look at a problem they were having with our software. It was then that it struck me that I was literally the face of the company, and whatever I did during this visit would reflect either positively or negatively on our product, company, and future sales to this customer.

That’s a lot of responsibility to take on as an individual, but also a lot of opportunity to affect change. I have worked at only larger companies since, and still sometimes meet one-on-one with a customer, but more often now, with a team. But I’ve carried forward the idea of “you are the face of the company” a lot more earnestly as being part of my job, even when meeting with customers in a group situation, and even when I only indirectly represent the company to the customer, through the things I create.

In the case of Data General, it was another doomed voyage situation. The chip they were working on was a totally asynchronous design, with (for the HW geeks), gated clocks, flow-through latches, and clock domains with non-overlapping frequencies.

In a way I think it was a futuristic design, we see more of these things now than 25 years ago. And who knows what will come with AI-designed hardware, and systems that mimic (also very asynchronous) neural networks. The trouble for DG though was their chip did not in any way work, and the verification tools of the time, including ours, were unable to debug it efficiently.

The problems with this project were not the sole cause of Data General’s end, but a bit of a harbinger if you ask me. I solved their immediate issue and flew away from there that day feeling I had done my best for them, but also feeling that it would not be long before the designers I met would be searching for escape craft of their own.

Lesson 2: You Can Do Everything Yourself

I also learned another lesson of Small, kind of the inverse of Lesson 1. This was the idea that once the bureaucracy of your job environment is removed, you are now free to do things that previously would never have been allowed. And in a small company situation, people are basically counting on you to not wait for formal permission to do something, but to take the initiative yourself. Knowing when and how to exercise this freedom is kind of the key skill set for mastering Lesson 2.

Our CTO Kevin was a guy I felt was just destined to live a charmed life, that included such feats as becoming independently wealthy three years after starting and selling his first company, along with smaller things, like hitting a hole-in-one on his first swing at our company pitch-and-putt golf outing.

One time Kevin got bored and went up onto the roof of our three-story Mill building with a fishing pole, and cast a line into the pond that abutted the building. Within seconds, a fairly large bass got hooked, and he reeled it up, much to the astonishment of some ladies who worked in another company located on the second floor. As they sat at the window assembling medical devices, a large fish just began levitating upward past them.

I don’t know why this is important to this story, but maybe just because it speaks to the level of informality that was in play on this strange planet I was on. Office NERF gun wars became a Silicon Valley cliché at some point, but in the 1990s I like to think our giant impromptu wars we had were on the cutting edge. Every employee was issued a sidearm when they were hired, and nightly capture-the-flag games were quite common.

Small here provided opportunity, and the CEO and CTO and other decision-makers of the company were not in some far-off corporate headquarters, they were the people you shot at with your NERF gun, and bumped into coming down from the roof with large fish. Everyone knew each other, and even an intern would have a chance to pitch ideas to the CEO.

I had been doing decent work in the company creating new interfaces for the product, and would get visibility, recognition, and guidance directly from Kevin and others in charge of the products we developed. Eventually they offered me a chance to work on building a whole new product, which in retrospect was probably a task beyond my level of experience then.

Perhaps there is another lesson in here about when to say no to an opportunity, but for better or worse, I took this offer. It was not something that would have been remotely possible at my previous job. Here is where I also learned a hard lesson about the right and wrong ways to do things all by yourself.

The product I had been put in charge of turned out for various reasons to be a dud. I can certainly take some of the blame for that, but there were many things working against it that were also out of my control. The one thing that was under my control though was the software architecture for the new product, which similarly turned out kind of bad.

What we were creating was really just a new mode of our old product, so it shared a lot of existing functionality, and in theory, code. The dilemma I faced was that the new product would do things differently, necessitating some fundamental changes to the code it was based on to make it extendable. The right solution here was a pretty deep refactoring of some of our software layers, including ones authored by different teams in our company. I think doing that would have been within my capability, perhaps with some help.

But years of working for a large, stratified organization had trained me to rule out that possibility. Proposing a big change to another group’s software at DEC (or worse, just changing it yourself) would in most cases have caused drawn-out conflicts, and the bureaucracy involved would bring inevitable delays and unneeded compromises.

The usual DEC way to deal with this was to just re-invent the wheel yourself, creating duplication, but thereby putting your project’s destiny in your own hands. (This siloed thinking of course caused a lot of issues at Digital, which I explored a bit previously in my article The Enemy Within.)

Following the DEC playbook, I built a product prototype that just duplicated some of the infrastructure code, rather than refactor something I was not in charge of to make it common to both products. In my head, this was a temporary measure, and I had the intention to work with the original authors to redo this “the right way” at some vague, unspecified point in the future. I got the prototype up and running pretty quickly this way, and Kevin who was excited about this project was soon showing it to customers, way before it was ready.

When inevitable problems cropped up, there was a review of the product and code, and the nature of my hacky implementation was revealed. This earned me a (luckily not permanent) reputation as a reckless, cut-and-paste hacker, and I was relieved of my architectural design duties on the product. It was probably a low point in my technical career, and I spent a few years after that in technical exile, managing people and projects but not writing much code.

Looking back it is obvious to me that I could have just gone in and reorganized the needed code myself, and it was not a task I had to wait for formal permission to do. There would have been a lot of scrutiny and review of my changes of course, but in general no red tape, and the creators of the code I would change were not the territorial types who would have minded me changing it. Another one to chalk up in favor of small.

My travels through space and time since have taken me to larger, more populated planets once again. But the lessons I learned on Planet Startup still hold in many ways. Grace Hopper, US Navy Rear Admiral, Computing Pioneer, and (for a brief period) Digital Employee is famous for saying:

“It is easier to ask forgiveness than it is to get permission.”

I have found this to be at least partly true. I think the modified, very software-developer-centric version of this for me became: “Don’t ask permission to write the code, ask permission to check it in.” My version skips the forgiveness part, because although there are indeed times when you should “just do it” and possibly upset people in the process, it’s not really a collaborative or reliable long-term strategy. You still need eventual buy-in with my modified version of avoiding asking permission. But it does allow for taking the initiative to do something nobody asked you to do, which is really a killer skill if you can master it.

So no matter what size spacecraft or planet or whatever you may find yourself on, my learned advice here is to not wait around too much. If you are waiting for someone to do something you can do, do it. It doesn’t matter if it is something you typically don’t do, just make it happen. And if you can help out in some way, don’t wait for someone to give you a perfectly green light beforehand, just go.

If you follow this advice, perhaps some Hopperish forgiveness will be needed in there, from time to time. But if you do it right, maybe your company will be the one blowing up the Death Star, rather than the other way around.

Explore Further

• Escape Pods (TVtropes.com)

• What Startup Employees Can Teach Us About Work (hbr.com)

• 10 Tips on When to Refactor Code

Next Time: Interactive Fiction games can trace their roots back to the late 1970s, and in the decades since have provided countless hours of entertainment for generations of players. We’ll catch up with the man who brought Adventure off of the mainframe and into our homes, spawning an entire genre. See what he’s up to now when we head back to the maze of twisty passages in: The Further Text Adventures of Scott Adams

Whether you hail from a big planet or a small one, consider subscribing to the Mad Ned Memo! You’ll receive weekly posts from the nerdy world of computer engineering and technology -- past, present, and future. (check the link for a sample of past articles). The Mad Ned Memo is cost-free and ad-free, and you can unsubscribe at any time!

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

I had my suspicions that something was terribly wrong with how our development team was organized, but I didn’t really put it all together until the day the Patent Attorney showed up. We had been working on a new product for a couple of years, a very large beast of a program that was used to analyze simulations of computer chips and provide useful information to the people verifying their correctness. In short, fertile ground for possible patentable ideas.

The company encouraged engineers to seek patents on work we did, and would send out someone from our legal department on a regular basis to solicit ideas for patents. This time though, we were coming up blank — even though the product we all worked on was super innovative and complex. The development team had been brought together to brainstorm with the patent person on possibilities, but everyone was kind of in a bad mood about it. She encouraged us to just start throwing out ideas, even if we thought they were not patentable ones. Silence. People just sat quietly, arms crossed.

The patent attorney shifted uncomfortably in her chair. Isn’t there some unique analysis feature we had worked on that we could look into patenting? she prompted.

No, we would sadly reply, the analysis logic for our product was handled by a different group. We were working lately just on a graphical user interface component for it.

That’s OK, she reassured. User interface designs can also be patented, especially if they solve a problem in a unique way.

And it was certainly true that the component we were building fit that description and did in fact have a lot of unique, probably patentable, ideas behind it. The problem was, even though we were building the component, we did not design it. Our software development group had turned into an implementation factory, churning out features invented by outsiders, but without much input from us on the actual design.

We referred the patent attorney to the other group that had designed the product interface, and she left our meeting without any ideas from our team to work on. It was not unusual for a brainstorming meeting like this to ultimately lead to nothing patented, but what was unusual was to hold a meeting where no one could think of a single good idea to even write down. It was awkward and everyone felt bad after the meeting. And I came away from that determined to try to do something about it.

The Bad Solution to the Good Problem

Trouble had been brewing for a while on this team. A management organizational shift had been made months back, in response to a perceived problem with our product’s current user interface design. Customers had complained about the usability, and to be honest, there were indeed issues there. For most of the development life of this product, software engineers without any UX design experience were building all the user interfaces.

With predictable results. Clunky user flows, obscure, hard-to-use controls, inconsistent use methodology, and so on. We were lucky in one sense that our customers were primarily also engineers, so there may have been some nerdy synergy regarding the very function-over-form design. But the complaints about the quality of the UI eventually reached upper management, who decided to do something about it.

They budgeted for hiring some UX design experts to take over the interface design of the product, which seemed like a good move to me when we first heard it. I initially welcomed having some people on the team who were skilled in interface design, but I soon learned to hate it. The problem turned out not to be with who they hired, but where.

Instead of adding the new designers to work as part of the development team, they were hired into a separate organization I will call the “Applications Group”.

The Applications Group consisted of engineers who interacted more directly with customers, working on technical problems but not directly developing products. It was part of an entirely separate division of the company from R&D, and there were at least three levels of management one had to traverse upward before reaching a common point between this group and our R&D development team.

What You Will Build is on a Need-to-Know Basis

A few weeks later we were called to a meeting with the new UX team, where they presented a pretty expansive redesign of our existing user interface, incorporating many new features and design changes. We had a lot of questions and feedback on what was proposed, because all of it had been created without any R&D input, and many things seemed difficult to implement or inadviseable for various reasons.

Like predictable engineers, we started providing feedback during the presentation. After several interruptions, the Applications Team presenter seemed visibly annoyed, and asked that we withhold all questions to the end so he could finish the presentation. This is a common thing for a presenter of something to ask, and it is usually only polite to do so. But the R&D staff attending this presentation felt they were being brushed off, and doubly so when at the end of the presentation, the presenter still refused to take questions or discuss the proposal.

“This is preliminary,” he said. “We are working on more detailed specifications, and you will have a chance to review them when they are finished”.

Nothing illustrated the problem we were having here better than that statement. It suggested that software engineers writing the code should only be permitted to review a design after it has been created, rather than to collaborate on its creation, to begin with.

Giving The Cat A Bath

As a senior member of the R&D staff, I felt it was kind of my job to cause trouble about this, on our team’s behalf. I met with the lead UX designer from the Applications Team, and pointed out to him that one’s ability to affect change once an idea has reached the review stage is severely diminished, compared to what can be done if that person is allowed to participate in the original design discussion.

He didn’t seem to feel there was a fundamental difference, or if he did, did not want to acknowledge it. The general attitude from him and the people in his organization was that the previous R&D-led design was bad, and they had been given the mandate to take charge of the product and fix it.

Some of that was true. But their version of things seemed to preclude any kind of collaboration or input from R&D during the design phase. The “Research” of “Research and Development” evokes images of people in lab coats with test tubes. In software development terms though, the “R” would include the exploration, prototyping, and design work. And that “R” had suddenly been removed from our job descriptions.

Various attempts of mine to convince the UX team to meet with us were rebuffed. I eventually took it to my manager and above, because our group even within the R&D organization was somewhat of a remote group, and it seemed possible to me that our main R&D group was not experiencing this complete takeover of things in as quite a severe manner as our remote team had.

And indeed, our second-level management was surprised to hear how siloed things had become, and offered to speak to the manager of the UX design person and require him to have meeting with us. While I appreciated the gesture, I told them that it probably was not going to be enough. I likened the situation to giving a cat a bath.

Cats don’t like taking a bath. You can force them to, but they will hate it, and try to spend the minimum amount of time they can in the water. Then afterward, they’ll hold it against you. This was the situation with compelling the UX team to attend our meetings. That particular analogy of mine resonated with a lot of people locally and in our remote management, and thereafter the idea of forcing people to collaborate with you was referred to in these cat-bathing terms.

A Trust Gap Like The Grand Canyon

Things kind of only got worse from there. In spite of our immediate R&D management agreeing with our assessment of things, they were pretty powerless to fix it, because the organizational siloing was very deep (or should it be tall?) The upper-level management we shared probably was in favor of letting the Applications Group drive the R&D design of things, given the very abstract level they worked at.

The people in the Applications Group took the mandate quite literally though. As the Agile “Product Owners” of our development Sprint team, they had also assumed the responsibility for determining what would be worked on, and in what order. Normally I would say it is kind of optimal to have someone like an Applications Group person who is close to the customer setting the priority for things. But in this case, it was coupled with all the other roles the team had assumed from our development group.

As a result, almost all actual decision-making of any sort had been removed from the team, including what would be done and when. Observing how things were going as a senior (and perhaps a bit cynical) engineer, the thought did cross my mind that this was an attempt to create a development group where no senior R&D people are needed. After all, if there are no decisions to make, and everything is already designed, it does not require a more expensive older engineer just to write code to spec.

The trouble with that theory was, the junior engineers on the team hated the organizational situation just as much, if not more, than I did. They complained a lot about it, and espoused even more radical ideas about what management intended, and where things would end for our group. They had no faith that they were working somewhere that valued their input or where there was a future for growth, and I was kind of surprised no one left somewhere in here.

At the lowest point, I was getting in arguments with the person prioritizing work because they objected to me scheduling R&D-centric tasks like refactoring, infrastructure work, and so on without first getting permission from him. I angrily reminded this guy that they were in charge of the Product priorities, not the R&D team, but they did not see any difference I suppose.

Also on at least one occasion towards the end of all this, there was a product design meeting attended by Applications Team and UX people from various remote sites, and they chose our building to have the meeting due to its central location. But no R&D people from the building they met in were invited to these meetings, which were about the very thing R&D had been asked to design.

When I called them out on it, I was told R&D wasn’t invited because it would be too big a team and be “Design By Committee”. I said it was instead “Design in an Ivory Tower”. No compromise was ever made. We had reached a zero-trust state, which is of course not a sustainable one for any organization.

The Deus Ex Ending

Sounds super-crazy, even now to me. The good news is, the company did not go out of business, the product didn’t get canceled, and nobody lost their job. Well, almost nobody. A few of the more arrogant players in this story either chose to leave the company, or were encouraged to choose to leave, after things came to a head and an inevitable second reorg happened. And I would be lying if I said I was sad about it.

Things coming to a head happened because work was just not getting done on time. Part of this could be attributed to extravagant and impractical UX designs getting too far along before they were determined to be unimplementable. Something that could be traced back again to a lack of R&D and UX collaboration.

But a larger part of it was that people in the development team were just showing up to work, and not much else. I had a friend once at Digital who gave me this unforgettable advice, right after we were bought by Compaq:

“When captured by the enemy, it is best to display model prisoner behavior.”

And that was exactly what had happened here. It wasn’t that people were deliberately trying to sabotage progress, they were showing up to work and doing their jobs as instructed. But nothing more.

I like to use the marketing term “Mindshare” to describe what you have when your employees feel empowered and are truly bought into what they are working on. Amazing things can happen when you have a team’s Mindshare, but in this case, it was nowhere to be found.

The reorg that followed disbanded the Application group, returned the UX function back into direct R&D management’s control, and integrated designers with software engineers. It is a bit Deus Ex Machina of an ending to the story, but I’ll take it. Things rapidly improved after that, and so they lived happily ever after.

I know what you may think - this was a biased opinion in favor of R&D, and there is probably a UX team side of the story. Certainly true. But I would say my strongest bias is not about favoring R&D over some other team.

My bias is about working collaboratively, instead of in separate groups that due to their organizational distance, create opportunities for conflict and mistrust. Doesn’t matter if that organization ends up being called “R&D”, or something else. Hell, we can call it Design and Development or something like that. The nerd in me would be happy working in the D&D group!

Explore Further

• Patenting an Invention (MIT)

• How To Bathe A Cat

• Breaking Silos In Your Organization

Next Time: The experience of moving to a company with 5600X less people than the one you were at. Small company adjustments and some pleasant surprises too as we talk serious downsizing in : When You End up at a Startup

The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

I try to do research for my articles. Or at least, some approximation thereof. While researching this one, I was surprised to learn that the subject company of the article, Heathkit, was still in business. So I had to revise my title a bit, which was going to be about how a “long-dead company” taught me things about good user experience (UX) design.

All apologies to Heathkit on that one. However, to be fair, it did go bankrupt in 2008 and was dead (to its kit customers at least) for a while. But as Miracle Max might say, it turns out our friend here was only “mostly dead”. Heath staged a comeback after restructuring in 2013. They reorganized, restarted, and are selling their signature electronic DIY kits again! And I hope it all goes well.

I also hope the new incarnation of Heathkit lives up to the older one, which for me set the bar for how a company invests in making their customers succeed. Their motto has always been “We Won’t Let You Fail”, and in my experience in the 1970s and 1980s with their products, I found it to be true. I built many of their kits and despite my questionable electronics knowledge and soldering skills of the time, never ended up with a brick.

The Original Maker Age

Heathkit traces its origins back to 1911 and was originally a light aircraft company founded by Edward Bayard Heath. Heath died in 1931 during a test flight of one of his aircraft, and his company went bankrupt. The company and the Heath name was later bought by Howard Anthony, who in 1947 started selling electronic kits to the growing community of ham radio and electronics enthusiasts of the mid-20th century. In a strange coincidence, Anthony also died in a plane crash in 1954, but the Heath name and Heathkit company lived on.

As I talked about a little in my Radio Shack article, Ham Radio and its enthusiasts were the original Makers, experimenting with new technology and building projects from kits and from scratch in their homes. This amateur radio scene was in full swing by the 1950s and through the 1960s, with Heath supplying a wide variety of radio equipment kits. By the 1970s (which is when I first came to know Heathkit) the company had branched out from radios into new product kits as well, including weather stations, alarm systems, and eventually, computers.

My Cat Hated Heathkit

Throughout the 70s and 80s I built (or helped build) various Heathkit projects, including an alarm system cleverly disguised as a book, a wind direction / wind speed weather station, and (helping a neighbor) eventually the ET3400 Computer Trainer, which was an early Heath’s foray into computer kits.

I still remember how exciting it was when we finished the ET3400, and turned it on and saw the LED display reading “CPU UP”. It was always very satisfying to finish any kit and see it come to life after all the effort and care you put into building it.

When I graduated college and started work, one of my early paychecks went to Heathkit, to buy the HERO Jr Robot. My alarmed family gently reminded me that I should also consider actually getting out and meeting other people and not stay in my new apartment building robots, but for nerdy me this was a very high priority, given how long I’d spent ogling things I could not afford in the Heathkit catalog.

I did leave the apartment and meet other people eventually, but not before completing this (as it turns out last) Heathkit project. I named the robot “Shithead” (my elegant way with words obviously goes way back) and assigned it the duty of keeping my cat Donovan in line. The cat was named after the singer of the song Mellow Yellow, because he was both similarly tempered and colored, but he also had the unfortunate habit of sharpening his claws on the drapes.

Shithead was outfitted with a squirt gun powered by an electric motor which was connected to a relay and wired to the only spare channel of the Hero Jr remote. I could pilot the robot into the living room and target the cat remotely when he was getting near the drapes, and eventually, just the sound of it entering the room would deter his bad behavior. All in all, I think the robot ended up more like a Dalek than the vaguely R2-D2 styling Heathkit was going after.

My Questionable Robot Building Skills

Yeah, a scratching post probably would have been cheaper. But then I would not have had the joy of building this great project and getting it to work! This is where we finally begin to talk about UX design. User experience is frequently associated with user interfaces for hardware or software, but it is a broader category than that, and covers the entire experience a user has when interacting with a product, from start to finish.

Heathkit took user experience seriously. This dedication to customer success manifested itself primarily through Heathkit’s instruction manuals, which were incredibly detailed and well-thought-out. Heath’s manual covered not just how to build their kits, but also how to troubleshoot and fix them if something went wrong.

Shithead for instance had issues. In my excitement to get it finished, I rushed through the build and ended up installing some components incorrectly, and the robot did not initially work. Since there wasn’t exactly a robot repairman I could call, the project would have been one expensive end-table if I could not fix it myself. Luckily, Heathkit was there for me.

The documentation for the HERO Jr contained detailed schematics and test measurement points, and information on what voltages and signals should be present on the various boards of the robot. This allowed me to narrow down the problem to a diode installed backward, something easily corrected. When I reinstalled it the right way, the robot sprang to life. I was delighted! Donovan was not.

What UX thing I learned here is something about taking into account the idea that your users make mistakes, and even if those are not your fault when creating a product, doing something to help them is always appreciated.

My Questionable UX Design Skills

For various reasons, I did not build many hardware projects for a while after that, (probably because I was getting more than my share of hardware projects at work), and I kind of lost track of Heathkit. They were bought by Zenith and tried to sell computers, with the same results as Radio Shack: eventual bankruptcy.

I continued to think about Heathkit long after they had disappeared as a company, especially later in my career when I was working on things like user interfaces for software we were developing at work. I have zero formal training in user interface design and probably should not have been allowed to make unilateral decisions about how parts of our GUI looked.

The same goes for writing user documentation, I am not a Tech Pubs guy but often find myself doing it. These situations seem to crop up often in my career, when products need to get out, the right people to design interfaces or write docs are not around, and R&D is left to the task.

In these situations, I do my best, and often take inspiration from what Heathkit has taught me. Here are a few of those ideas I try to keep in mind when creating something users will interact with.

1. Novice-Friendly is Always Appropriate

Even though the majority of Heathkit’s customers were probably experienced builders, they would always take time to include basic instructions for beginners, such as soldering technique. Experienced builders could just skip right over that page, it was never really annoying to see information you already know in the instructions.

There is an expert-friendly UI design school of thought that goes “you are only a novice once”, suggesting it's OK to create software that is hard to learn if it makes the experienced users more productive. I don’t buy this. If Heathkit taught me anything, it’s that Novice and Expert friendly do not have to be mutually exclusive. You can have tutorial modes and tool tips and basic versions of a UI for beginners without sacrificing expert productivity, for instance.

And these novice-friendly modes are worth investing in creating for your product, because although your customers may only be a novice once, that once is the first impression that will decide whether they come back again and again to your product, or move on to someone else’s.

2. Not Everybody Likes To Do Things the Same Way

This one seems super-obvious. But is it? I’ve gotten into arguments with other developers at work in the past about whether or not we need to make a feature available in more than one way - say on a menu, even though there is a key binding. Or on a toolbar button, even though the feature is also on a context menu.

The idea of streamlining user interfaces and reducing clutter is valid, and it is definitely possible to add too many buttons to something. But typically I see the thinking go the other way when an R&D guy designs a GUI. When coding, redundancy is a no-no, so having redundant ways to do things in a UI is sometimes avoided too much by a developer-turned-UX-designer. But people are all different. There are key-binding people and menu people and toolbar people out there, and providing a range of options for a function is useful, even if they all do the same thing.

Where Heathkit comes in here is again, with their instruction manuals (which are essentially their user interfaces). I was always impressed for instance that they would supply redundant circuit info, such as illustrations of an assembled board, X-Ray views of the traces of the board, schematics of the board, silkscreened information on the board itself to locate components, and written lists of components and testpoints.

A subset of these only would be needed just to assemble and test their kits. But by providing more than they needed to, they enabled a wider set of customers to succeed with their products.

3. You Can Never Have Too Much Documentation

Heathkit’s assembly instructions were very extensive, often 50 pages or more, sometimes with small helpful illustrations inlined with the assembly checklist. They always contained some beginner-oriented material as mentioned previously, but also even within the assembly portion of their manuals, the text descriptions were very detailed and comprehensive. (If there was an opposite to an IKEA instruction set, it would be Heathkit)

If you knew what you were doing and had no issues, probably a lot of this material could be considered superfluous. But even an expert builder would run into trouble sometimes, and having a highly detailed set of documents to describe how things should work greatly benefits beginner and expert alike, even if there is redundancy there.

I know for instance I would forgive a lot of repeated or long-worded descriptions of how a product works, if the documentation succeeded in helping me use the product the way I wanted to. As long as the information is not conflicting or confusing, I think what I took from Heathkit was that you really can’t have too much documentation, and I try to keep that in mind when writing user documentation myself, being generous with descriptions, examples, and details.

4. Your Customer’s Problems Are Your Problems

Finally, I would highlight the Heathkit motto of “We Won’t Let You Fail”, which should in truth be the motto of every company. Heathkit almost always included detailed troubleshooting instructions and test information for their products, and as a last resort even offered a repair service where you could send in your botched project to be fixed.

It wasn’t like Heathkit was the only company to create DIY kits, they had many competitors over the years. But what made them stand out was the mindset they had about what they were selling. It wasn’t just that they just sold DIY kits. They sold the experience of successfully building them.

There is obvious wisdom in that idea of selling the experience of success to customers, and not just a product meant to achieve it. And that philosophy can be applied beyond the world of DIY hardware kits to the software world as well. We could for instance talk a bit about how the troubleshooting part of Heathkit’s manuals has analogs in software having to do with producing better error messages and input checking for user interfaces. (Certainly a good topic, probably worth another article.)

But the customer success experience idea is something that spans beyond just one thing like handling user errors. It is about making things easy to learn, and useable by a wide variety of people with different preferences and levels of experience. About going the extra mile to explain things, and not making assumptions about whether or not someone already knows what you are talking about. It’s about being there for your customers when things go wrong, and providing ways for them to get back on track.

Maybe Heathkit will grow and regain (or even surpass) their former glory, or maybe not. Whatever the case, these lessons we take from their past are valid ones, and worth repeating. Also I do kind of hope Heath gets around to making a new robot. Because I have another cat, with a few bad habits.

Explore Further

• The Heathkit Virtual Museum

• Browse Old Heathkit Catalogs

• How to Solder (Instructables.com)

• Build-Your-Own-Dalek Plans

Next Time: A look back at a dark time in my career, when I worked on a team that was so siloed that the design and implementation parts of the job were done by different people, who rarely talked to each other. A spooky tale that missed Halloween coming up in: When the R from R&D goes missing

The Mad Ned Memo covers topics in Computer Engineering and Technology over the past 40 years. Sign up and get nerdy tales and discussions of computing’s past, present, and future delivered straight to your inbox, and never miss an issue! (See the link for a sample selection of past articles) The Mad Ned Memo is cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

When the Pandemic hit, I was working in a brand new office complex we had just moved into four months earlier. The new place was far and above our previous digs, which were steeped in dated 1990’s decor, and which had no real amenities or walkable destinations for food or shopping.

Everything about our old building kind of whispered “decline”. The carpeting featured geometric purple triangles straight out of a 90’s music video, the lighting was a dull fluorescent flicker in many places. Our building sat amongst a half-mile stretch of vacant properties, whose previous tenants either went under or moved to greener pastures. Half of our building itself was vacant, and you could peer through windows in locked doors at a dark, unoccupied sea of cubicles.

The new place by contrast was part of a recently renovated complex that featured a full-service cafeteria with in-house Starbucks, basketball court, arcade games, full fitness center, and more. Even our private space had many more perks to offer: trendy-looking break room, recreation room with Nintendo games and ping-pong table, and lots of varied, collaborative workspaces.

Really this was just bringing our office up to par with what other tech areas like Silicon Valley have had for years. Our office is on the US East Coast, and it seems that for whatever reason, we are always the last in the country to implement any trend or to get say, a new store or restaurant. (I mean, our town only just got a Popeye’s Chicken last month, and there’s like a huge line for it all the time.)

The company had convinced itself that it would be better for attracting young talent if we moved to a site more comparable with what we had in other parts of the country. So they chose a large, modern multi-tenant complex in an area densely packed with tech companies, restaurants, retail stores, and apartment complexes.

It sounds like the right move, but I left off some key details in my description. The new location was only about ten miles south of the old one, but the intervening highway was one of the most traffic-congested spans in the entire state during rush hours. For most people, this translated to another half hour of commuting time, sitting in stop-and-go traffic.

The younger part of our workforce that had not bought a house or otherwise settled down somewhere pondered moving closer to the office. What they found was that their rent was going to double, if they wanted a similar-sized apartment in that commercial zone. Most people I knew quickly abandoned the idea and just inherited the extra half hour of commute time.

Then there was the office itself. At some point before our move, the management had to broach the delicate subject of how our new cubicles would be downsized, both in terms of area and wall height. When I started work at Digital Equipment Corporation in the 1980s, the cubes there were a (now ridiculously large) 10x10, with walls I would guess were five feet or more in height. Later these became 8x10 sometime in the 2000s, and in the new move, 8x6.

People groused about it. But for most, downsizing seemed inevitable, given how the rest of the tech world had transitioned to spaces this size or smaller long ago. The bigger concern the office staff had was about privacy, and a worry we would lose our cube walls entirely and go to the “open office” plan one of our other new buildings in California had used a few years back. There was a lot of feedback sent to the architect of the new site about a concern for privacy, and what we ended up with is a compromise, with slightly shorter walls and more open doorways, but not an entirely open / low-wall system.

Reduced privacy though turned out not to be an issue. Because the new office was not really occupied at anywhere near the same level as the previous one. Our company has long had a pretty liberal approach to telecommuting, leaving it up to the individual managers to set a policy. Our site did have a fair number of 5-day office regulars, but also a lot of people who telecommuted mainly but still worked in the office for some unspecified number of days a week. After the move to the new site, that “unspecified number of days” began to trend towards zero.

And it wasn’t just the old-timers with long commutes and families like me that were staying home. The younger employees, who were the most excited initially about the new office space, were also showing up a lot less. What had happened, wondered the planners of this move? Pretty much just a preview of coming attractions. By March of 2020, even the most reliable office-goers would be forced to abandon ship and discover their new, home-office lives. But in our case, it felt like the verdict on the new space was already in, even before the Pandemic.

Maybe analyzing it all now is a moot point, given how things have gone the past year and a half with the huge shift to telecommuting everywhere. But for me at least, I can say during my short time in a modern office complex, that I missed that crappy, dreary old office of ours. It was easy to get to, had big opaque walls and pleasant-for-coding, dim lighting. The fact that it was a dump was somehow also compelling. It may have been a dump, but it was our dump, and I secretly reveled in the appalled looks we would get from corporate visitors from the west to that site.

I probably also liked the old office because I’d been trained for the past twenty years to like crappy offices.

Why They Cut The Wheels Off My Chair

While the New England area seems to always be behind in getting the latest trends, it is a leader in figuring out what to do with the old ones. In the 19th century, New England was the technological capital of the world, spearheading the industrial revolution with an impressive manufacturing capability. Thanks to abundant hydropower, mills producing textiles, furniture, machinery, and household goods sprang up everywhere.

Large numbers of people came with their families to work in these mills, spawning cities that still exist today. Most of the manufacturing left the area in the 20th century, but the mill buildings remained. Many fell into disrepair, burned down, or were otherwise abandoned. But many were repurposed, especially during the start of the electronics age.

My original employer, Digital Equipment Corporation, made its headquarters in such a mill, a large rambling complex of buildings originally built in the late 1800s to produce textiles, including blankets for the civil war. In the early 1990s, I spent a few years working at this amazing site.

I joined the Alpha Workstations group in Digital in 1991 as it was forming, and we all moved into a space on the 6th floor of Building 3. This was the top floor of the building and was once used as storage for wool bales. The floors here were quite uneven, bowing down in the center and up at the walls, and generally undulating in the other direction as you walked the long halls. Varying theories circulated as to why.

Some said it was just the age of the building, some said the weight of things stored there caused the bending, but my favorite theory I heard was it was due to lanolin, a natural wax produced by sheep that is present in wool, and which has a softening effect on things. Whatever the reason though, it created a pronounced list in a lot of the offices, especially mine which happened to be near a wall.

When I moved in I found the filing cabinet was shimmed with small pieces of wood to level it, so the drawers would not just roll open. When I swapped the existing rickety chair in the office for one I brought, I quickly learned that it would roll away from my desk when I sat down. I inspected the original chair that came with the office and discovered that someone had taken a saw and cut off the bottoms of all the wheels, to prevent it from rolling.

I stuck with that rickety chair, and learned a lot about the other oddities of the building. In the summer, the air conditioners on the roof leaked, and so we had plastic sheets to protect our monitors from shorting out. Office walls were just painted plywood, with almost no sound deadening, so you would hear everything going on everywhere. Navigation through the building could be tricky, even for a seasoned pro. In some spots more than 4 hallways intersected, and catwalks from one building to another did not start and end on the same floor.

The young people who comprised the Alpha Workstations team seemed to just revel in it all. I don’t recall anyone honestly complaining about the quality of the accommodations in a serious way. We all just accepted that the “historic” nature of this site came with a lot of weird things you had to adjust to. And not all of them were bad.

I personally took advantage of the fact the complex was so large and sprawling, by deliberately scheduling mandatory manufacturing reviews (which I hated and I really didn’t want a lot of people to show up for them) in conference rooms in obscure, far-away buildings. People would either get lost trying to get there, or just skip the meeting so they didn’t have to find it. Those reviews went smoothly!

The other great thing about DEC’s Mill was that the town was literally built around the site, so when you stepped out of the building, you were in the middle of Main Street. Right next to the Post Office, shops, restaurants. It was a tight symbiotic community, still functioning as it was intended over a hundred years after being built. When Digital shut down the site in the late 1990s, the town was devastated.

We moved to a nearby (but more remote) modern office building that had many more amenities, but lacked any kind of character, and was not really built to be part of a community. Everyone I knew missed the Mill.

A River Runs Through It

I left DEC a few years after that, to work for a company started by ex-DECies. They must have missed the Maynard Mill, because their startup had chosen another old mill building for their company. Much smaller and maybe not as old as the Maynard complex, but definitely with as much character. This particular building backed right up to the pond that used to supply its power, and a small waterfall ran down next to one side of the building, physically touching it at times.

We had a spring flood once, and the water reached a point where we could see it arcing over the windowpane of our conference room. In what was most certainly bad Feng shui, the water also ran under this particular conference room, and we had a little trap door in there you could open and look down at the rushing river. (Our founder and a senior manager had to be stopped from whitewater rafting down the waterfall, because of the decapitation risk of the bridge that was downstream.)

The landlord here had no business renting this building out as an office space, it was really a cash grab on his part and capitalizing on the tech boom of the time. It was rundown and smelled faintly of diesel fuel. All sorts of denizens infested the building, including mice (the appearance of which prompted an office procedure whereby my friend Keith would be called in to dispose of them) and also Dobsonfly Larvae that probably were native to the river.

For those who have not had the pleasure, see picture below. Scale here is like over three inches, and you haven’t had an exciting day at work until one of these bad boys has dropped from the ceiling onto your desk while running regressions! Makes you think about Star Trek’s Chekov and his ear-loving Ceti Eel.

OK. Looking back, that one is objectively horrifying, and I don’t really miss it.

But I miss working there in general, and even when the Dobsonfly visitors broke up the day, it gave us something to talk about. The outdoor views, as shown, were spectacular, as was the walk down the railroad tracks ten feet behind the building. (Visitors from Silicon Valley would have to be reassured when the building started shaking from an approaching train though.)

We eventually got bought by a bigger company and when corporate came out to assess whether to upgrade the site or move, they were horrified. They quizzed our CEO about the ventilation system, and how we had just random vents hanging from 100-year-old beams, with no suspended ceilings to facilitate “air return”. Where were the emergency shutoffs for things? Our CEO looked around and shrugged. No one had any idea. We also had a kind of large algae situation on one facade that faced the river which was not particularly attractive. It was obvious that the Suits felt the building did not project the proper image to customers and employees.

Then they started talking about the rent. How much were we paying, the assessment team lead asked? Our CEO said (if I remember) $17 per square foot.

“$17/sqft per month? That’s really not that cheap, about the same as in the Valley!”, the corporate guy exclaimed.

Then our CEO clarified that our rent was $17 per square foot per year, not per month. Which kind of put a damper on the whole “It’s cost-effective to be in a modern building” discussion. In the end, we were moved to a much more expensive building, that everyone hated a lot more. But it looked marvelous.

This is kind of where I’d like to end today. It’s really hard to explain the appeal of crappy buildings, but people do just fine in them, even thrive, if the building has “good bones”. And crappy buildings are cheap, as it turns out.

None of us know who is going back to the office, when, or if. Given that, I would say if you are starting a company or moving one, consider the crappy building. Save some money on the lease at least, just in case no one decides to come back. And for those who do return, there are stimulating activities, like cutting wheels off chairs and dodging monstrous insects from above!

Explore Further

• Early Industrialization in the Northeast

• 32 Practical Feng shui tips

• More Info than you want on DobsonFlies

Next Time: A companion piece perhaps to my Ode to Radio Shack. Let’s talk about another lost friend from my childhood, Heathkit, and how the original go-to company of the Makers set the bar for customer experience in: What a Long-Dead Company Taught Me About UX Design

It’s a hard sell getting people to sign up for more email, I know. But think about it: What do you have to look forward to in your Inbox? It could be the Mad Ned Memo! Get your weekly dose of nerdy computer stories and discussions, nestled right in there between your credit card bill and UPS shipping delay notification. The Mad Ned Memo is ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

I recently posted an article about resurrecting old code, and went into some detail about how I brought a program for the TRS-80 I wrote in 1982 back to life. This post had some interesting discussion on Hacker News, and among these comments was one from a reader who mentioned that his oldest code was from 1978, and is still available on GitHub.

The author of this response was none other than Walter Bright, compiler expert and creator of the D programming language, as well the author of the very famous program that he had referred to in his Hacker News reply. That program was Empire, written in 1978 for the DECsystem-10 mainframe and is one of the earliest examples of a computer wargame. Empire contained then-groundbreaking features we still know and love today, including maps featuring cities, water and complex landmasses, fog-of-war mechanics, and a formidable computer AI that plays by the same rules you do.

I encountered Empire while taking classes at the University of Hartford in 1981, where it was installed on their brand-new VAX 11/780 computer. It was the first time I ever played a computer wargame, and I was instantly hooked, spending valuable time on the system’s VT100 terminals conquering cities rather than doing my data structures homework.

I did pass that course, but no thanks to Walter. Forty years later, I was very surprised to have run across him in this way. I asked him if he would be willing to discuss the development of Empire with The Mad Ned Memo, a request to which he graciously agreed. I am delighted to share it with you now!

MNM: Hi Walter, thanks so much for taking the time to talk with The Mad Ned Memo about your work, and the development of Empire. I’ll start with an observation. Looking through your long list of accomplishments, Empire seems to be a bit of an outlier in your work, which has more of a focus on programming language, compiler design, and related computer science topics.  What are your thoughts about that?

WB: A perennial problem I had with Empire is the computers of the time simply were not powerful enough. It ran slowly, and games where the computer played itself lasted several hours. (Today, a second or two!) This meant I became more and more focused on optimizing the code, and so became more and more interested in compilers and languages. I figured I could do better than the existing ones!

MNM: Which would bring us to talking about the D programming language, something I want to touch on in a bit. But you just answered a question I was going to ask, about whether the game was the consequence of some computer science project, or the other way around. Sounds like the game came first. What was the inspiration?

WB: I actually invented Empire when I was 11. I built a game board out of a large sheet of plywood, painted it, made game pieces, etc. But, it turned out to be far too tedious to play. (I knew nothing of the paper wargames that were popular later.) So it got shelved. When I finally was able to use a computer, I realized it could remove the tedium and leave the fun part. A computer also relieved one of the burden of finding a friend who was interested enough to spend hours playing the opponent. The computer would be the opponent.

MNM: Only child here. Sounds very familiar. So were there other one-player computer games of the time that influenced you? I personally don’t know of any wargames prior to 1978, except perhaps Chris Crawford’s Tanktics.

WB: Computer games I played at the time were various Star Trek games, lunar lander games, ones out of the 101 BASIC Games book, etc. A particular favorite was Hamurabi. All were very simple. I've never heard of Tanktics.

MNM: How about non-computer wargames? Were you a fan of strategy board games like all those 1970s Avalon Hill games such as Panzer Blitz or Squad Leader?

WB: I was completely unaware of them, other than Risk and Stratego, both of which were influential for Empire. Another point of inspiration was in the movie The Battle of Britain (1968) there were scenes in the British dispatch and control center, which had a giant central map where people moved around counters representing airplanes and ships.

MNM: I would say you captured that control center feel with Empire, in a very immersive way. I was not kidding when I said I almost failed a Data Structures course in 1981 because I was playing Empire.

WB: Empire has caused many students to flunk out, and even a few divorces. I've received some angry emails over these.

MNM: It probably shouldn’t, but that makes me feel better! What about you, Are you a regular computer game player today?  Is there anything you found yourself hopelessly addicted to for a while? (including Empire itself)

WB: I worked as a video game tester in college, which wrecked my interest in “twitch” video games. My interest in Empire is not so much playing it anymore, it's devising a better computer strategy. I'm a lot more experienced in how to do such things today, and the temptation is strong to go do it. But I need to focus on my compiler stuff.

MNM: Speaking of gaming instead of working - I recently wrote an article called The Value of Screwing Around at Work, which detailed some time I spent working on a game instead of what I was supposed to be doing.  I’m interested to hear if Empire was developed at all when you really were supposed to be doing something else?  Or, was it part of an officially sanctioned project of some sort?

WB: I was careful to do it in such a way as nobody else could claim ownership of it. I.e. I used my own equipment and never did it in the office. I'd also get a signed statement from my employer(s) enumerating my side projects and acknowledging they had no interest in them, in advance. I *strongly* recommend doing this - it'll save one a lot of worry, grief, and money.

Nevertheless, I have worked on projects at a company that I wasn't supposed to be working on. They were rogue projects, in the company's best interests, and for the company. Some turned out to be pretty valuable for the company, so I have no regrets. I figured that since I was well paid, part of that pay was for my expertise in what would work for the company :-)

When I was at Boeing, the only computer was a PDP-11 in a separate air-conditioned room. I was not allowed to use it, because that was operated by a separate division of Boeing. (I was in the 757 Flight Controls group.) We were supposed to do calculations on paper with a calculator. I wasn't having that, and talked the sysop into giving me an account and the door access code. I wrote a number of Fortran numerical programs to do my work, and got good results from it, leading to me being assigned more and more of such work.

Eventually, my clandestine activities were discovered and the computer division demanded that I be reprimanded. This dispute went up several layers of management, until the uber manager of my division told the computer dept to lay off, that I was doing good work, and made my access official. In hindsight, I was at Boeing right on the cusp of the revolution away from paper towards computers.

(I was also supposed to write documents longhand, and hand them to the word processing pool to enter them. Ugh, I get writers' cramp signing a check. I cajoled the head of the WP pool to let me use one of the Wangs, and did the documents that way. I was apparently the only engineer to do so at the time. The WP pool was all women. My, how things have changed!)

MNM: Yeah the further back you go, the more controlling the computer environment, in general, seemed to be. My experience with mainframes of the 70’s and 80’s was that they were timeshared, limited-access systems as well. Did you have trouble with using that sometimes hard-to-get time to write Empire / ever get any grief for writing a game on the mainframe?

WB: I'd get grief for using too much computer time, and this was resolved by my restricting usage to the wee hours of the morning. Computer time was always hard to come by, the student demand for it far exceeded availability. I'd also do a lot of programming with pencil and paper, until I could get access.

I really wanted my own computer bad, and finally got one with the H11 (their version of the PDP-11) and set about creating an “11” version of Empire in assembler language.

https://github.com/DigitalMars/Empire-for-PDP-11

MNM: I’d imagine the AI routines could burn through allocated CPU time. I was always impressed with Empire’s enemy unit pathfinding. I remember reading an article about the development of that game Tanktics, and how the AI had a problem with units getting stuck in “U shaped lakes”.

WB: I was rather proud that Empire's computer strategy didn't have trouble with U-shaped land. It took a bit for me to figure out how to do it.

MNM: If I remember correctly, Chris Crawford kind of “cheated” and just eliminated U-shaped lakes from the maps in Tanktics, instead of working on the AI to handle it. Empire seemed to have pretty complex land mass / water configurations that the enemy had to navigate.

WB: I fixed the AI. One problem that nobody noticed was the waters all had to be connected. The AI couldn't handle a continent with, say, 3 big land-locked lakes.

MNM: That’s also a map optimization for the benefit of the AI, but a much less restrictive one I’d say. Another unique feature of the game you are credited with creating is “fog of war”, where the map is slowly revealed. Was there a non-computer inspiration or influence for this?

WB: Stratego :-) and of course The Battle of Britain, where radar was used to detect incoming enemy aircraft. I also knew about the Battle of Midway, where knowing and guessing where the enemy fleet was meant life or death.

The fog of war is impossible with the board game version of Empire, but with computers I knew I could make it work.

MNM: Wow. I never thought about it, but yeah, Stratego does implement “fog of war” quite nicely with the slowly-revealed pieces! So after all these inspirations, was the design of the game done up-front, or did you kind of figure it out as you programmed?

WB: The rules of the game were settled very early, and they worked so well I was reluctant to change them.

MNM: Wise. A wisdom though that I sometimes have trouble following! How did the development go from there? Any good/weird bug stories to share?

WB: Mostly it was trying to prevent the computer strategy from getting stuck in local optimas, like one piece just going uselessly back and forth. Being a Fortran program, all memory was statically allocated and so I never had any pointer bugs in it.

MNM: So are you a good player of your own game? (In my limited game design experience, I find others quickly eclipse me.)

WB: Not really. I was always thinking of improvements rather than getting immersed in it.

MNM: What is the “great unfinished project” you have?  Is there something, such as a different game (or non-game project even) that you abandoned you wished you had completed but never will?

WB: I did a Zork-type game (which was Advent at the time) but never completed it, called Castle. I graduated and lost interest in it. I had written a lot of code, but that has all disappeared.

MNM: You can’t save them all I guess. I would have liked to have seen what you had though. I see you rewrote Empire in another one of your major projects, the D Programming Language.  Was that done for the benefit of developing D, or to improve Empire (or both)?

WB: Every language needs a great game, so why not? It was fun anyway. The translation was very rote, so it did not take advantage of D's capabilities.

MNM: I will admit to not being familiar with D, however I have spent a lot of time with C and C++.  D to me seems borne out of a desire to do C++ ‘right’ - as in to address some of the flaws that are inherent in both.  Is that accurate, or is it selling it short? 

WB: D is simply easier to use than C++. People find they can get their projects up and running much faster in D, with the same performance and control. It's not really one aspect of D that enables this, it's the combined effect of quite a few things.

MNM: I’m curious to ask about those few things, but suspect that would be a whole other conversation. So I’ll try to wrap this one up with a last question, about what’s happening next.  Is there anything new you’ve been working on you’d like to share?

WB: When I finally did some learning on how neural networks worked, I was startled to discover that Empire's computer strategy relied on a primitive neural network-like method. The computer was far too slow to provide the large number of iterations required for training, so I would tweak the coefficients manually.

It makes me think about how a proper n.n. with automated training could produce a really effective computer strategy! I must resist the impulse to implement that.

It would also be fun to enable users to plug in their own "bots" to calculate the moves, and then there could be competitions among the bots. Wouldn't that be cool?

Cool indeed. I didn’t think to ask when we initially talked, but it seemed to me that there was something like this a while back featuring self-modifying code bots that ran together in a common memory space, trying to kill each other. (Walter later reminded me that this game was called Core War.)

In any event, I’d like to thank Walter for taking the time to talk to the Mad Ned Memo and share these details about Empire. Kind of makes me want to download it and try to find some neutral cities to take over before those dreaded “A”’s start coming through the fog-of-war!

Explore Further

• Walter Bright Home Page

• Empire: Wargame of The Century

• Winning Stratego Tactics

Next Time: If we ever go back to the office, I want one like the Millennium Falcon: Something that doesn’t look like much, but has got it where it counts. When bad digs make for good times coming up in: I Miss Working in the Crappiest Places

If you enjoyed this interview with computer gaming pioneer Walter Bright, consider subscribing! No spoilers, but we may have another guest coming in a few weeks to chat about the early days of computer game development that you will not want to miss! The Mad Ned Memo is cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

Victorian Engineers built a vast network of copper cables and switching stations to relay text messages, and eventually two-way audio, between distant points. Sounds like Steampunk stuff, but it’s just the old Telegraph and Telephone systems that evolved into what we use today. (Also memo to self: The phrase “Victorian Engineers” sounds cool, needs to be used more often.)

The telephone system was the Internet before the Internet, providing a pretty impressive capability to connect everyone’s home to countless other homes and businesses across the globe. But you know: Invent a technology, and people will begin messing around with it, almost immediately. In my last article, I mentioned a not-well-known meeting between Thomas Edison, inventor of the Phonograph, and Oberlin Smith, inventor of magnetic recording. Oberlin’s account of this meeting included an offhand comment from Edison about how phonograph recordings could be played backward, and the phrase “mad dog” played backward would become something “unspeakable” (at least for that point in time)

The fact that the inventor of the phonograph was screwing around with it and having it create Victorian-era obscenities from a backward recording is pretty good evidence that hackery and general technological clowning-around dates back much further than the invention of computers and the internet.

It rarely makes it into the history books though, and if the first thing Alexander Graham Bell said to Watson over the phone was actually “Farts! Farts! Farts!”, we probably would never know.

Shenanigans safe to say though were going on not only before the Internet, but well before any of our times. If it is the telephone system we are talking about specifically however, I can fill in some shenanigan information, starting in the 1960’s.

Ma-Ma-Ma Bell, It Will Get You

We had a rotary-dial phone in the 1960s, and my earliest memories as a kid were about it being a “party line”. Simply put, multiple households shared the same telephone line, so you could actually pick up the phone and hear someone else having a conversation. So I guess an early “hack”, if you can call it that, was to eavesdrop on people sharing your line.

I was a little young to really be interested in what adults in other houses were talking about, but obviously, it was a popular pastime among people with party lines. There were some subtleties to it, like the fact you could hear someone on the same line pick up the receiver because it created an audible click, giving the eaves-dropees a chance to know they were being listened to.

Telephones had been around almost 70 years by the time I ever used one, but even so, the 1960s phone situation was still pretty limited in scope. Even if you did not have a party line, chances are you had just one, or at most two (wired) phone extensions in your house on a single line. Much of this was because the one company in the US providing phone service and equipment, the Bell Telephone Company, charged subscribers extra if they wanted additional phones in their homes.

Again I am not talking about multiple lines, just multiple phones on the same line. We lived in a two-story house and had an extension each floor. But in our finished basement, we also had a “ringer”, which was a box that rang when the phone rang, but was not a fully functioning phone. The ringer was a grey area, and source of contention between us and the phone company, because they would routinely test to see how many phones were on the line to try to catch people evading their extension fees.

When I was a kid I had no idea how this detection magic happened, but as an engineer I later figured out that this was a basic impedance test on the line from the central office, to see how many device loads were on it. All phones came from Bell Telephone Company at this point, so they all had the same characteristic impedance that divided down, the more of them were connected in parallel. This made figuring out how many extensions on a line a matter of simple math. Anyway, our ringer was probably not a sanctioned Bell product or paid-for third extension, so when the phone repairman came to visit he would disconnect it. And then, after he left, we would reconnect it.

Bell Telephone would run afoul of US anti-trust laws in the 1980s, and was broken up into eight separate companies. The landscape quickly changed (for the better, in my opinion anyway), with unrestricted extensions allowed on a line, wireless phones, and and a much expanded array of better phone products and services.

Do You Have Prince Albert in a Can?

The rotary-dial phone system back then was only mildly hackable in an electronic sense, because it was so computer-free. But I and my intrepid friend Dave spent some time as tweens engaging in the “Social Engineering” aspects of it — namely making prank calls. We by no means were pioneers here. The anonymity, or at least the perceived anonymity of the non-computerized and non-caller-ID phone system made hassling random strangers back then a staple of bored-kid life.

Before my time for instance was the joke of calling a store and asking “Do you have Prince Albert in a Can?”, referring to a popular tobacco product. When the store employee said, “Why yes!” the kid would reply with “Well you better go let him out!” and then hang up the phone. How fun!

We never did this one, because no one knew what the hell Prince Albert in a can was, even in the 1970s. I guess the more common version from my time was “Is your refrigerator running? / Better go catch it!”, which was equally lame, in our opinion anyway.

Our brand of phone pranks was more along the lines of gaslighting random people by calling and not identifying ourselves, and when they asked who it was, we’d reply “Oh come on! You know who this is!”, to try to elicit some guess. From thereon we would pose as that person, in an increasingly cringeworthy way until the person on the other end catches on, and we’d hang up.

This kind of social engineering hack has the same DNA as a modern-day phishing scheme, except our intent was always squarely centered in mayhem and not profit. Our phone imposter game eventually went a bit too far. One day I observed a line technician repairing a cable and using his belt-mounted handset to call the Operator, and then say something like “Hello Operator, this is Repair. Can I have ID please?” And in response, the Operator would tell the repairman what the phone number he was calling from was.

This was quite useful for isolating a line in a phone trunk cable that could have hundreds of twisted pairs, but this “feature” of Operator interaction had no other practical value. Twelve-year-old me was fascinated by telephone repairmen and their gear, however, and I also had a deep awe/fear of the legendary telephone Operator — who could always be reached by dialing zero, and whose powers included not just allowing you to make collect calls, but also being able to identify what number you had called from.

It didn’t stop us from trying the “Can I have ID please?” trick ourselves. In my best phone repairman voice, I dialed zero then made the request, and the Operator dutifully read back my phone number to me. I was delighted, and probably should have quit while I was ahead. But some time later I repeated the trick, and the Operator got suspicious of me this time (probably because it sounded like a 12-year-old calling) and asked me for my badge number. In a panic, I hung up. Then the phone rang, and it dawned on me only then that the Operator not only knew who was calling, but could call them back.

I think we ran out of the house at that point, and luckily no one else was home to take that Operator callback. We had somehow managed to take the almost completely anonymous phone system and find a way to mess with the one person on it who could identify us. Very Twelve.

Le Phreak, C’est Chic

In the 1960s the telephone system in the US would begin to migrate to electronic switching, which is where the dawn of computer hacking begins. (Remote hacking, that is - not discounting some mainframe hackery before this)

The phone system could now make connections automatically — but to do it, the primitive switching systems of the day communicated with one another using simple signaling tones, which could be copied by end-users of the system.

As the story goes, a 7-year-old blind boy named Josef Engressia accidentally discovered a key phone switching frequency, 2600 hertz, due to characteristics of his voice that kept disabling the phone recording feature he relied on. Transmitting this frequency on a line tricked the telephone switch into thinking the call had ended, but left the line open allowing it to be used for free long-distance calling.

Hacking around on the phone network like this became known as Phreaking, and spawned what might be the first underground hacker community. A guy named John Draper is considered to be an original and legendary Phreaker. Draper as it turns out was friends with Engressia, and learned of the 2600 frequency trick. Not having the same voice characteristics as Engressia, Draper needed a new way to generate the 2600hz signal, and found that a giveaway whistle in a Cap’n Crunch cereal box produced the exact needed tone. This discovery earned him the hacker nickname “Cap’n Crunch”, or alternatively “Crunchman”.

Side Note: I was surprised at some embarrassingly-late point to learn that the famous hacker publication 2600: The Hacker Quarterly was referencing the 2600hz tone. For some reason I was thinking Atari 2600.. must be the gamer in me

Things got more complex from here, when DTMF / “Touch-Tone” dialing came along. Now phone switching systems used multiple frequencies to signal call numbers and functions, and again the phone company relied on a pretty bad “security through obscurity” plan to keep people from abusing it. That went about how you would expect, with hackers building all sorts of specialized boxes to exploit the phone system.

Phreaking as a topic could easily consume multiple articles, but unfortunately not written by me, because I was not really active in this space. Although — I was fascinated with DTMF dialing, when I learned it was a combination of a “row” and “column” frequency on the keypad, and further that there was a secret missing A/B/C/D column of buttons with special functions. I may have built a full 16-key DTMF pad to try it back then, but not sure I got anywhere with it.

War Dialing For No Dollars

It seems the further forward you go in time, the less interesting phone hacking becomes, at least from my perspective. Caller ID and computer system logging made it a lot harder to do anything anonymously, and long-distance calling got cheap once the phone system broke up, making phone hacking less worthwhile. I know that early cell phones were not protected well and became a hacker target, and even now there are people active in that space. But it feels like once computer networks began to spring up in the 1980s, the general hacker community moved on.

The first computer networks were the dial-up kind, where you would use a modem on your telephone line to call another computer directly. Modem lines then were mostly for dedicated use by companies, and no public internet-like directory existed, at least at first. We are talking pre-AOL, and even BBSs were just getting started. This is where my only real foray into black-hat hacking happened.

There used to be an old TV show called Dialing for Dollars, where a host would call people up while showing a movie and if you were watching and answered, you would win cash. When I think about the term “Dialing” this show comes to mind for some reason, but in the case of my Wardialing adventures, no dollars were involved, just dialing hackery for the sake of it.

What is Wardialing, some of you might ask? Click the link for the full deal, but in short is the idea of using a modem and computer to call successive telephone numbers, searching for other modems. The name comes from a scene in the 1983 movie Wargames, but I swear I was already thinking of building one before seeing the movie. What the movie added for me was a cool GUI that displayed the list of numbers it found modems on.

When I was a sophomore in college in 1983, I built a war dialer for my VIC-20 computer and replicated this Wargames interface (like many others, apparently).

For the hardware geeks: This was basically just a relay connected to a 600-ohm transformer, that could replicate rotary style, pulse-code dialing. On the input side I had a 567 PLL tuned to the modem signal frequency, to detect a remote system. So a couple of I/O pins to the VIC only were needed. Total cost about $10 in Radio Shack parts. I stuffed the whole thing in an underarm deodorant spray cap that dangled off our dorm room wall phone.

My roommate at the time was a black belt in Karate and threatened to break bones I did not even know I had if I ran up the phone bill with my ‘demon dialer’, but fortunately for my bones, the bill was fine — in spite of leaving my VIC to dial hundreds of numbers while I was at class. Just like in the movie, it did end up finding dozens of open modems to connect to when I returned. When we called all of these, a surprising number of them had little or no security, connecting us directly to a system without any login needed. (This no-security thing was a topic of another article I wrote about the 80’s hacking scene)

We snooped around a lot but I don’t recall doing anything more malicious than that. A lot of school system computers, and some business office systems that seemed to contain stuff that I am sure they would be horrified to know random college engineering students were poking around in. A notable line I remember getting onto was something to do with a NOAA weather satellite system.

I like to think we just accessed some data dump from the satellite, it was mostly tables of numbers with no heading info to tell us what we were looking at. I don’t think we had any kind of direct link going on.. that is I think we didn’t… And hopefully, we did not mess up anything satellite-related there in our poking around. (If there were any storms in the fall of 1983 that strangely did not get tracked properly though, I have no comment.)

But just like in my twelve-year-old prank-calling days, we again took this scheme too far. After calling one number on the modem list and getting an initial tone but no further response, we hung up. And then the phone rang. We picked it up, and heard a modem tone from some unknown system, that had called us back! Memories of the fearsome Operator from my past were certainly in play here, as was the actual plot of Wargames, in which I believe the WOPR computer does something similar to Matthew Broderick.

Anyway we were very freaked out and followed the same playbook as twelve-me, and ran outta there. As if that would have actually helped, if we had started global thermonuclear war or something. I was maybe 19 then, and so it seems seven years is not enough time to improve your hacking emergency plans. It was only later that I learned about the concept of a “toll-saver” feature, which allowed one to make a brief call to a system, hang up, and then have it call you back to save you the long-distance charges. This is almost certainly what was going on here, but since it was 1982 and before caller ID and so on, this would likely have been a feature of perhaps a phone company system. Probably just as well we didn't mess with that one.

So I suspect that some of my readers might have their own tales of the phone system to share. Please do! It is easy for me at least to forget what a bygone era the whole phone world really is at this point and how it might be of interest to those who missed it. But I have faith that we’ve got some people out there who messed around with Ma Bell. In the end, if something is connected to something else, someone is going to hack it!

Leave a comment

Explore Further

• The Breakup of the Bell System

• Whatever happened to Phone Phreaks? (The Atlantic)

• 7 Funny Prank Call Ideas

Next Time: Long before Command & Conquer, Steel Panthers, and Civilization there was Empire, a mainframe strategy game conceived in 1971 that would influence the computer wargame and strategy world for decades to come. I am very excited to bring readers a conversation I had recently with its creator, Walter Bright. So be sure to join us next week, as we talk about the pioneering days of computer game development!

The Mad Ned Memo covers topics in Computer Engineering and Technology over the past 40 years. Sign up and get nerdy tales and discussions of computing’s past, present, and future delivered straight to your inbox, and never miss an issue! (See the link for a sample selection of past articles) The Mad Ned Memo is cost-free and ad-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

This article is coming to you because of moving magnets. In spite of impressive advances with solid-state memory, the large storage arrays of “The Cloud” (including Substack’s cloud I would reasonably guess) still rely heavily on traditional hard disk drives, which operate by magnetizing very small areas of a thin coating on a rotating platter substrate. Those areas act as magnets themselves, creating a field that can be detected by a flying “head” that skims ever-so-close over the rotating platform these magnetic sources ride upon. Billions upon billions of tiny little magnets, spinning around in unison, forming the vast majority of the world’s stored electronic information. (Gee, I suddenly feel like Carl Sagan)

When I think about things in these terms, it seems like a pretty strange way to store information, and perhaps a bit precarious, considering how heavily we rely upon it. But this Magnetic Boogaloo has been going on for some time, and today we’ll dive into the early days of spinning storage, and a few other weird things from the early days of computing.

Those Few Other Weird Things

In a previous Mad Ned Memo, we had a great discussion about the (very) old days of mainframe computing, when the shift from mechanical systems to electronic ones necessitated faster mechanisms for storing data than the punched-paper approach that was prevalent at the time. In that article, I talked about strange electronic storage systems, like the Delay Line Memory and the Williams-Kilburn Tube.

My readers had a couple of contributions of their own to this list. Martin Cohen commented about using UCLA’s SWAC computer with Williams Tube memories dating back to 1949. He was programming it in 1964, so the machine was already very obsolete but appreciated that he could get time on it. I especially liked hearing about how this machine supported binary punch cards - I had not thought of that combo, all the punch cards I ever dealt with were just pure text. But it makes sense, given paper tape is essentially binary. Anyway Martin you win the award I would guess for oldest memory system programmed by a reader!

Reader EricV mentioned a pretty unique use for ferrite cores, in the EGRET instrument of the Compton Gamma Ray Observatory which launched in 1991, to study high-energy photons. The cores were apparently used to digitize signals coming from the gamma-ray detecting ‘spark chamber’. I didn’t see that detail in the wiki article, but EricV designs high-energy physics experiments so seems to know what he is talking about. Way cool, to see an old technology like core proving useful as late as the 1990s!

My favorite contribution though was from Tom Thornton, who mentioned a super-obscure memory system I had not heard of called Rod Memory, which was created by NCR in 1962 for their NCR 315 series of computers. Rod memory used tiny little rods to store information magnetically, rather than the doughnut-shaped cores of core memory. This geometry apparently allowed for some automation of assembly, as the rods could be magnetically aligned to fit into a matrix without manual intervention. I think though the significant note in the article was, the design avoided NCR having to pay royalties to IBM, who held the patents on core memory.

Thanks for all those weird contributions! Several readers though did point out a glaring hole in my storage article, that being my omission of memories involving moving magnets. Core memory, while magnetic, does not qualify for this category, but disks, drums, and tapes certainly do. I left these important things out because it was just such a big category to delve into, it would have blown up the article to an unwieldy length. I’ll try to make up for that, now.

Oberlin Smith, Long-Lost Father of Magnetic Recording

When you hear an old Edison-era recording from the 19th century that is full of scratches and pops, you either assume it has those problems because it is so old, or maybe because the old-timey people who recorded it were just happy to record anything in the first place, and didn’t really worry too much about the low quality.

Turns out that neither is the case. Those old recordings had pops and scratches even when they were new, due to the nature of what happens when a mechanical stylus travels over a medium with sound vibrations encoded on it, but which also contains flaws of some sort. Anyone who has played their Dark Side of the Moon vinyl LP too many times and/or left it outside the dust jacket on a non-clean surface (looks around guiltily) can confirm this phenomenon.

But it is also untrue that everyone was happy about it, even in 1898. Enter Oberlin Smith, industrialist and owner of a large metal press business that supplied parts to everything from rifles to Model T’s. Smith is described as a “tinkerer”, who could not look at some gadget without thinking of how to improve it. I would say he meets the modern-day definition of hacker, who among other things invented a remote control phonograph system so he could sit in a chair and select a record without getting up - pretty much the first jukebox.1

Smith seems to have been somewhat of an audiophile as well, because upon hearing Edison’s foil-cylinder sound recordings during a visit to his famous laboratory in 1897, thought the quality could be improved, and decided to do something about it. His idea was an early entry in a classic tech playbook: substitute a mechanical process with a non-mechanical one. In this case, getting rid of the vibrating stylus following grooves on a cylinder in favor of a magnetic thread reel and pickup coil.

Not a complete elimination of all mechanical action of course — that innovation really didn’t come until the solid-state memories of the 21st century. But merely eliminating the mechanically-encoded grooves of Edison’s recording medium in favor of a magnetic version that could be read electronically was a huge idea. One that would power the information age to come.

Unfortunately for Oberlin Smith, he was much too busy with his other business concerns to either patent his idea, or to commercialize it, and at one point just put it out in the public domain. Maybe it was just that he liked to hack and didn’t really want to pursue it further, I don’t know. He was in fact already rich and didn’t really need the royalty income.

Whatever the reason, Danish engineer Valdemar Poulsen ended up credited with inventing magnetic recording, even though he had previously seen and essentially copied Smiths’ ideas. To give Poulsen his due though, he was the one who came up with a practical magnetic wire recorder, whereas Smith never got anything out of the lab. But Smith went unrecognized for his contributions to magnetic recording until his original disclosure article was rediscovered in 1985.

Let’s Go To The Tape

After that, a bunch of other guys figured out how to bond metal oxide to tape, and we got magnetic tape recording, along with BASF, magnetic media giant. Vacuum tube amplifiers were on the scene by 1910, and the magnetic audio recording era was in full swing. It wasn’t until the 1950s though that anyone managed to use magnetic tape with a computer - something called UNISERVO for the Univac I Computer. Although it offered a pretty low information density of 128 bits per inch, it must have seemed like an enormous treasure trove of storage compared to other formats like punch cards.

The tape format lives on to today. IBM’s TS1160 tape drive for instance was released in 2018, holding up to 40TB per tape at a transfer speed of 400MB/S. That is not super-fast, when you do the math about how long it will take to record a full tape. But tape systems never were speed demons, and never had to be. Their mission was to provide removable storage capacity, which could be scaled just by buying more media, and allowed for things like archiving.

I still have a roll of DECTape - Digital’s “personal-sized” magnetic media developed for their PDP series computers. I bet if I could find a TU55 drive somewhere I could read all 256K or so of it, even today.

But let’s also be honest. Tape drives are also a pain in the ass. They make for great sci-fi movie props, but the rapidly spinning wheels on those soon-to-be-destroyed-by-Godzilla control center computers were probably rewinding, or seeking. Both of which were necessary evils in the tape game. As an owner of several cassette tape storage computers in the 1980s, I can tell you of my troubles locating a program on a cassette that I used to store multiple programs on, manually searching for a program start point back and forth on a tape. (yeah I know that’s what the counter is for - if you remember to use it!)

Cassette storage for early PCs was not even a truly electronic storage system — it basically operated as an audio recorder, storing modem-like sound output from the computer. This was really not super-efficient or fault-tolerant, compared to other commercial tape drives of the day. But it allowed companies like Radio Shack and Commodore to use off-the-shelf audio cassette recorders as a storage device. (Probably more importantly, to rebrand off-the-shelf audio cassette recorders as computer storage devices, with a very profitable markup.)

Drum Machine 1.0

This drum machine above did not provide the beats for Breakin 2: Electric Boogaloo — the ZAM41 pre-dates that 1984 classic by a few decades, and the general computer idea of a drum machine goes back even further, to the 1930s.

Drums were the precursor to hard disk drives, and were simpler to design because the heads did not have to move, and the tracks on the rotating drum were all the same length, unlike the concentric tracks of a disk. I was surprised in my research to learn that one of the earliest drum machines on something called the Atanasoff Berry Computer worked on capacitance rather than magnetics, and the drum consisted of banks of them that stored the data.

Magnetic drum storage started as a main memory solution for computers and were pretty small in capacity - under 100K bits. Eventually, they found a place as secondary storage systems, and drums were in regular use up until the 1970s, and if you consider the frighteningly outdated systems of the US Military, beyond that even. But in the mid-1950s, a new storage technology enters the chat.

Insert Drive Pun Here

I’m on deadline, so I will leave it to the readers to come up with a good disk drive topic header pun! “The Drive to Success?” … “Baby You Can Drive my Commodore?” I don’t know.

Leave a comment

Hard disk drives came on the scene in 1956 when IBM introduced the IBM 350 storage system, a complete beast of a disk drive containing 52 double-sided platters and weighing one ton. Super cumbersome, but the mid-century programmers using the RAMAC system they literally built around this drive then had the pleasure of five whole megabytes of storage to work with, which must have seemed like a galaxy. (A funny thought I had was: this article might not fit on it)

You got to hand to it IBM when it comes to thinking big. No disk drive at all had ever been commercially sold when they built RAMAC. So you would think they would start with like one platter, or maybe a couple. But no, IBM said 52 platters is what we are going with. Ballsy.

My favorite part of the article about it though is the part about how IBM’s management initially killed the project because they thought it would be a threat to their punch-card business. Which was of course correct, but I guess it took them a while to embrace the you-must-eat-your-own-young world of technology creation and obsolescence.

Speaking of beasts, a personal favorite old mainframe disk drive was the Librascope Disk File, only two of which were produced. This two-ton monster featured a four-foot platter, spinning at 900RPM, and holds the Guinness world record for largest disk platter. I seem to remember a story from a visit to the Computer Museum (when it was in Boston), about some mammoth hard drive like this on some old computer breaking loose from its mount and going across the room. I would think the angular momentum on some of these mega-drives would be killer. But I could not find any accounts of this type of failure - reader contributions also appreciated here!

In the case of the Librascope, it was a head crash that constituted the catastrophe, wiping out at least half the disk on one of the units. As an aside, I think it’s pretty interesting that the heads of a disk drive need to ‘fly’ over the disk surface, at a perilously close distance. And if for some reason the power fails or something goes wrong with the servo controlling them, they can crash into the magnetic “ground”, destroying the drive.

That’s something that in theory can still happen even today, but modern disk systems have many more levels of protection that minimize the odds of that happening. In fact, if we move forward in time from these early drives, there are a lot of things that are essentially the same. Smaller drives, higher density, better electronics. But still magnets, moving in circles.

Even though almost every metric, today’s storage solutions are better, I still think we are missing out on the excitement of designing and using these unwieldy storage beasts. For instance, the sound that Librascope drive made when the head crashed on that four-foot platter must have been incredible! And imagine getting to drive a forklift to install your next disk drive. Also exciting was the profit margins on storage back in the day - IBM leased the RAMAC drive at $3200 a month to customers.

$3200. A month. For 5MB. Come to think of it, I guess I’ll stick with my 512GB SSD. Even if I could fit this article on a RAMAC drive, I don’t think the current Mad Ned Memo income could pay the leasing fee.

Explore Further

• Breakin 2: Electric Boogaloo

• Starring The Computer (cool database of computers in movies)

• A History of Hard Drives

Next Time: The Victorians created a vast network of copper cables and switching stations, allowing for instant realtime audio communication and signaling between distant points. Sound like a Steampunk novel? Nope, just POTS - the Plain Old Telephone System! Invented so my friend Dave and I could make crank calls in the 1970s. How Ma Bell was just swell coming up in: Wardialing and other Phoney Stories.

It’s a hard sell getting people to sign up for more email, I know. But think about it: What do you have to look forward to in your Inbox? It could be the Mad Ned Memo! Get your weekly dose of nerdy computer stories and discussions, nestled right in there between your credit card bill and UPS shipping delay notification. The Mad Ned Memo is ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.

I’ve posted a lot about all the weird and nerdy things I have been up to in the past, but something I really have not spent much time on is talking about is anything to do with time I’ve spent at work as a manager. It actually turns out to be a lot, maybe six or seven years in a couple of different stints, sometimes with as many as ten people reporting to me. I don’t write about it much though because I don’t consider it to be my “core thing” — as in, the thing I really identify as being my calling in life.

But I have done it, and by some measures, I think I did a good job. My reports, in general, liked working with me from what I gathered at least. But I was fatefully bad at “managing up” and routinely demonstrating my worth and the worth of my groups to those above. Probably not unrelated: I lost my management position twice.

The first time it was because the company decided to follow the G.E. Jack Welch model of having a flat organization, and when they flattened us down to a mandatory five levels or less, I was bumped back from manager to individual contributor. The second time I was “de-managered” was during the 2009 recession, and the teams I was in charge of were off-shored, making my position unneeded. Came pretty close to losing my job but was able to move again back into a technical position.

So that’s the setup for who you are getting management advice from; not exactly a ringing endorsement of my qualifications on the subject, I know. But I like to think I learned a few things along the way though. I am sharing them here, even if to be honest it is not very likely that I will return to a full-time management job and use them myself any time soon.

Should You Take That Management Position?

On one occasion I took a management job in another group in order to leave a somewhat toxic, high-pressure work environment that had developed within my current group. It was an escape, and allowed me to work for a manager that I admired. Getting out of a bad work situation was probably the right thing. But the problem was, it really was not a job I found very interesting.

This “Line Manager” job had me working strictly as a people manager for several small groups, with about seven reports under me. In my previous management jobs, my responsibilities included a mix of technical work and supervision of junior employees, but in this case, there was no technical work, just the people manager part.

That right there should have been a warning sign to me. Some people aspire to move up the ladder, considering the individual technical contribution phase of their career as a stepping stone to bigger things. What I eventually learned in my case was, being an engineer is my “core thing”, not a step on a journey somewhere else - and attempting to abandon it completely to be a full-time manager was a mistake.

The biggest problem for me transitioning from engineer to manager was having to give up some amount of creative decision-making that I was used to in my technical position. The parts I really like about being an engineer tend to be finding good ways to solve problems, thinking up new approaches, getting past roadblocks by finding a non-obvious path, and so on.

The manager position I held though ended up being largely administrative. Attending meetings, holding employee 1x1s, tracking progress, giving feedback to employees on their work. All of these are valuable things to be doing, but it felt very much to me like “turn the crank”, meaning it was just a job and required very little actual decision-making on my part.

Looking back, I was not very excited about my job during some of these years. In the case of my company, line managers did not have a budget to control, had very limited ability to unilaterally make hiring and firing decisions, and lacked a lot of power to start new initiatives. So not much ability to actually effect change. Perhaps in a startup situation or a different company culture I would have fared better in this position, but I learned in the end that technical contribution was a better path for me.

Be a Beekeeper

In spite of any misgivings I might have had over those years about my manager jobs, I did try to give them my all. What I found was that I was much better at managing people who were achieving their goals, than I was at managing those who needed help because they were not. For that former case, I took a page from the book of a couple of previous managers I liked, who were very hands-off. I tried to model my management behaviors around things I appreciated from these former managers of mine. Providing top-level guidance, acting as a shield from outside disruptions (usually from upper management), being a cheerleader and advocate for people in my organization.

There is an old post from 1995 by science fiction author Orson Scott Card that compares the job of managing software engineers to that of bee-keeper. I am not sure I’m 100% in line with his version of the analogy, but I do like the general idea of software managers as beekeepers.

When you keep bees, you cannot really direct each bee to do things specifically, and attempting to do so is pretty counter-productive. What you can do though is to provide an environment that bees like. Protect them from danger. Provide access to materials they need. If you do that, and you are gentle in your overall management of them, you can harvest the honey. It was the general approach I preferred as a manager, and still prefer as someone who is managed.

This works great for managing people who are doing well, and I think it made me a pretty likable manager that people wanted to work for. As a result, I found it was a lot easier to get tough projects done, like quality pushes to fix bugs where no one really was enthusiastic about it. I could carry my gentle beekeper capital into these projects and get people motivated to make the honey.

The Hard Parts of Managing

But of course this is the easy part of the picture. In my tenure as manager, I was called upon to have difficult conversations with people as well. There were employees who were not doing what they needed to be doing, and my job required me to tell them about it, and find ways for them to improve. Some people could manage to improve and produce satisfactory work, but others could not, and I did have to fire a few people. There were also times when I have had to lay people off, and sometimes it was just people in the wrong place at the wrong time, and not someone with a real performance problem.

I’ve had people crying in my office after learning they have lost their jobs, and I have seen people get really defensive or angry when given negative feedback, to the point of quitting. I have had to intervene in a physical altercation between two employees, one of which was mine, and sort the whole situation out. I have had to tell an entire group of people that their project had been moved to another region of the world. What I came away with is an enhanced appreciation of just how hard the manager job really is.

A lasting effect of this has been that I try when possible to make sure my manager gets positive feedback as well. In addition to being a hard job, managing is often a thankless one. It is usually a lot more obvious when a technical contributor does something well than when someone in management does. You can see a cool new product feature in action but things like boosting a group’s morale, preventing someone from quitting over a short-term problem, or even making a decision to let someone go who needs to go are invisible, but equally valuable things.

In one case, we had to let go of someone who was creating havoc in our code, but who also refused to accept any feedback or modify his behavior, and was doing things like checking in code without reviews and then lying and saying it had been reviewed. It went on for far too long, but eventually, my boss had to make the call and fire this person. It was very tough because my boss was a really nice guy, and the guy we were firing was also (on a non-work level), pretty easy-going.

At the end of the day after the employee had collected his things and left, I visited my boss and thanked him, and told him that even though I knew it was hard, I thought he had made the right call. I could tell he really appreciated my support, but that also it was pretty uncommon for someone to actually say.

The Disciplinary Bonus

I was going to call this article “Getting Good at Bad Reviews” but I like the current title better because I am not sure you ever really can or should get good at it. Getting criticism from someone, even constructive criticism, is very often hard for both parties involved. It is even harder when the summary of a performance review is that the person needs to improve.

In some ways, it seems to me it should remain a hard task to give a “bad” review, because it should be infrequent. If you are giving so many “needs improvement” reviews that you got good at doing it, this would be a lot like a teacher who gives the entire class an “F” on their assignment — Is it because the kids are all stupid, or is it that you are a bad teacher?

So as such, I don’t have any always-works strategy regarding giving negative feedback to people, but I definitely know of some things you should avoid, and in doing so can allow you to maximize the chances of things going as smoothly as possible.

The first thing is about not giving mixed messages. There is this management strategy you may know called “the compliment sandwich”, where you say something positive about someone’s performance, then a criticism, then something positive at the end. So basically, good bread with bad meat. I am not going to completely condemn the idea, because it is good to highlight both positive and negative things in a performance review.

But the compliment sandwich can be confusing or even patronizing if done in an insincere or formulaic way. If someone thinks you are just throwing in positive feedback to make the negative more palatable, they are going to be less likely to listen to the message you are trying to give. Better in a lot of cases just to have a dedicated discussion about things that can be improved that is separate from the discussion and acknowledgment of the positive things.

Another example of mixed messaging that really bothered me a lot as a manager was how our bonus program was structured at one point. People would get a bonus, that had an ‘individual multiplier’ in the bonus calculation, based on the person’s performance. So the average guy got 1.0, but a good employee might get 1.1 or 1.2, and an underperforming employee got 0.9 maybe.

I have some issues with giving bonuses to underperforming employees, to begin with; I feel bonuses should be discretionary and not an entitlement. (I wrote about some personal experiences I had with bonus entitlement disasters before.) The real issue with this bonus plan though was the formula for your bonus was included in your bonus letter. So you would have the situation where someone got a “disciplinary bonus”, where the company gave them money, but also a message that they were getting less-than-average 0.9X bonus, because of their performance.

This confusing of incentives and performance review was (to me at least) a super-bad idea, because of the mixed message it gave. Bad idea for a company policy, and equally bad as a managerial strategy.

A Review is Just That

Aside from avoiding mixed messages, it turns out that I only have one real piece of advice left for managers regarding giving difficult reviews, and it is the idea that a review should actually be a review. What I mean here is, you should not be saying anything at an annual (or periodic) performance review that was not already covered in previous discussions with your report. It should literally just be a review of things you’ve talked about over the year, and no new criticism or negative feedback the employee has never heard should be given at it.

That sounds super simple, but I cannot tell you how many managers I have seen that violate this, and spring surprising, previously-undiscussed negative feedback on employees at their reviews. No one wants to be blind-sided by something during their review, much better to just go over known things from the past with an eye towards improving them.

I had an employee reporting to me who was going through a rough patch. He was burned out, was in the middle of a messy divorce, and had a previous boss who was quite critical of his missteps, regularly ranking him as “needs improvement”. When I took over the group he was part of, he was “acting out” on a routine basis, getting in heated arguments with people at meetings, and was in fact the person previously mentioned who got into a shoving match with an employee from another group.

In that incident, it had escalated and was about to go to HR when I stepped in, and my employee was actually thinking he had probably lost his job. That was a distinctly possible outcome, but in this case I talked with the other employee’s manager and we determined that an apology from my employee to the other would be sufficient. In my conversation with my employee, I was pretty blunt about the fact that his behavior was not acceptable, and that while he would keep his job, he had to apologize to the other employee, a plan to which he readily agreed with.

None of what I said then was really surprising information, it was already somewhat of a review and summary to my employee, and although blunt feedback, it was accepted. The same guy had a few other things go wrong later. In one notable instance he got mad one day and named an LSF queue job he submitted to our division’s compute farm “sh*t-f*cker”, except without the stars, which immediately drew the wrath of our IT department staff that regularly monitored our farm jobs.

We worked through that one too, and I maintained a position of making it clear what is and is not acceptable, but also trying to be an advocate for him to improve. When review time came, we covered his accomplishments, which in spite of these incidents was actually impressive. But we also spent time reviewing the things that went wrong. None of what I brought up though was news to him. He acknowledged struggling with anger issues and that he was working to address them, and I gave at least an open-faced compliment sandwich by saying while he still should work to improve in this area, there had in fact been good progress.

In the end this person met somebody new, resolved some other personal things, and took on a new role in the company in a different group. We’re still on great terms, and I see someone now who is basically a different person than when I met him. This is another great takeaway - the idea that people can drastically change from a problematic employee, to a great one, just based on the situation they are in. In this regard, it is often worth giving someone another chance, even if they struggled in a previous job. People are not doomed to be bad employees forever.

Not every story ends this way of course. It’s not possible to have everyone you manage be happy with the feedback you give, or even agree with the feedback you give. The best you can do is to be consistent and predictable in how you go about it, stick to facts whenever possible. I would keep a little file of review topics for each of my employees - not something I archived or curated like a CIA dossier, but just simple reminders with concrete information like dates and details of things that happened, good and bad. This helped focus on the facts and issues rather than get in arguments about subjective things, like were you a “good employee” or not.

So that’s pretty much it. Predictability is king, I think, when it comes to being a manager. It is a basic building block of trust. If you know what your manager wants and can be sure they are being forthright and honest with their opinions of your work, you can build a great trusting working relationship, even if in some cases you do not see eye-to-eye.

All the best to my manager friends out there. You have a hard job, but an important one. Keep on keeping the bees in the best way possible, and we’ll try to send some honey your way.

Explore Further

• Are You Cut Out for Management? (Monster.com)

• How to Set Up Your First Beehive

• Giving Negative Feedback (Indeed.com)

Next Time: A follow-up on a previous article about weird and old storage systems, with a discussion on moving/magnetic storage systems and some strange reader contributions as well (clarification: the contributions are strange, not necessarily the readers). Time to get your magnets moving, moving for, Old Memories 2: Magnetic Boogaloo !

The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.

Subscribe now

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.