Category Archives: work

business, computing, nostalgia, work

Hiring for Potential and Building The Amiga Team

Leave a comment

I spent a good portion of my childhood in front of a Commodore Amiga 500, an amazing home computer for the late 1980s. I purchased mine used, after having saved months of hard-earned income delivering newspapers.

When author Brian Bagnall created a Kickstarter campaign to fund Commodore: The Amiga Years, a book about the history of the Amiga in 2015, I backed it. As Kickstarter projects go, 2 years later, I received it (now you can buy it on Amazon).

The Amiga was a really neat computer with great capabilities for its price point, much of it enabled by a number of custom chips. The design of these chips was lead by Jay Miner, a former Atari Engineer. I was surprised to learn that for one of the chips, Jay Miner hired Glenn Keller, an oceanographic engineer visiting California looking for work in submarine design, with no prior experience in chip design.

From The Amiga Years:
The engineer who would end up designing the detailed logic in Portia seemed like an unlikely candidate to design a disk controller and audio engine, considering he had no prior experience with either and didn’t even use computers.
…
In 1971, MIT accepted his application and he embarked on a masters in ocean engineering, graduating in 1976. As an oceanic engineer, Keller hoped to design everything from submersible craft to exotic instruments used in ocean exploration. “I’m the guy that builds all those weird things that the oceanographers use, and ships, and stuff,” he says.
When the oil crisis hit in 1973, Western powers began looking for alternative sources of energy. One of those potential sources was the power of ocean waves. The project caught Keller’s eye while he was attending MIT, and in 1977 he moved to Scotland to work for Stephen Salter, the inventor of “Salter’s duck”, a bobbing device that converted wave energy into electrical power.
The British government created the UK Wave Energy program and in turn, the University of Edinburgh received funds for the program. This resulted in them hiring Keller to work for the university.
The experience allowed Keller to develop skills in areas of analog electronics (with the study of waves playing an important role), digital electronics, and working with large water tanks to experiment with waves. “That resulted in some actual power generated from ocean waves,” he says. “It was a lot of fun.”
In March 1982, with oil prices returning to normal, the UK government shut down the Wave Energy program and Keller returned to the United States ready to continue his career in oceanographic engineering. He soon landed in California, where much of the development of submersibles was occurring. “I was up in the North Bay looking for oceanography jobs and ocean engineering jobs,” he recalls.
…
Soon, Keller was boarding a train for what would become a life changing experience. When he exited the train he was greeted by Jay Miner, wearing one of his trademark Hawaiian T-shirts. “I go to Sunnyvale, I show up at the train station, and there is this guy in a Lincoln Continental with a little dog sticking out,” laughs Keller.
…
One doubt Keller had was his lack of experience in the computer industry, or with personal computers of any sort. This was 1983, after all, and millions of personal computers had already permeated homes across North America. “I had done programming but I didn’t understand the world of personal computers or indeed the world of Silicon Valley,” he explains. “I hadn’t been there.”
Once at Koll Oakmead Park, Miner brought him into the shared office space with the whiteboards and block diagrams. Although Miner hoped the proposed system would have a great impact on Keller, he failed to get it. “I didn’t really understand why the architecture was so great in a general sense, because I didn’t know that much about where computers were at that point,” says Keller.
Instead, he hoped his diverse electronics background would give him enough skills for the job. “I had done a lot of electronics but no chips,” he says. “But I liked Jay and I always liked pretty colored wires. I had done a lot of different kinds of electronics. Being in ocean engineering, you do everything: digital, analog, interfaces, all that stuff. Even software. You do the whole thing. So I had a pretty broad base even though I hadn’t done chip design.”
Decades later, Keller sounds mystified as to why Miner would hire an oceanographic engineer into a computer company. “He hired me for some reason,” he says, musing the reason might be because, “I guessed correctly the difference between a flip flop and a latch.”
Most likely, Miner knew all he needed was an engineer with a good understanding of both analog and digital electronics for Portia. He could bridge the gap of chip design by mentoring a junior engineer.

A great story about a successful hire based on an assessment of someone’s potential to learn and grow.

Incidentally, in my high school years, that Amiga 500 landed me my first part time job at Dantek Computers, a small store that assembled IBM PC clones. By this time, around 1994, the Amiga was obsolete, and parent company Commodore was bankrupt. At my interview, Dan of Dantek looked at my resume, saw “Amiga”, and said in French:
“Amiga – ça c’est un signe de bon goût “. I started the next Thursday at 4 PM – I worked there after school for 2 years, and saved enough to pay for a good chunk of my engineering degree.

computing, security, work

Security: Not a new problem

Leave a comment

Here’s an OLD story about famous scientist Richard Feynman, who had fun cracking the safes of all his fellow scientists working on the Manhattan project in WW2:
http://www.cs.virginia.edu/cs588/safecracker.pdf (this is a long read best left for an evening at home).

What’s interesting is how easily you can draw parallels to the security issues we face today.  You could almost swap the word “safe” with “web application”, and “atom bomb design” with “financial data”, and the story almost carries over to today. These safes/filing cabinets contained documents relating to the atomic bomb (ie: something worth protecting).

To break the safes, he used:

  • social techniques
  • default safe codes
  • known design defects

Sound familiar?  What’s funny, is the reaction to his activities was not to improve security, but to try keep him out of the rooms, and pretend the problem didn’t exist.

work

People, Process, and the Sausage Factory

Leave a comment

In Product Development, we sometimes speak of “hiding the Sausage Factory”, meaning “hiding the complexities of software development and release” from our users. We want our users to enjoy using our products – they don’t need to know all the trials and tribulations it takes to get there.

In our Product Development Factory, we define standard processes and workflows, to bring some efficiency, consistency, and predictability to our work. However, we’re human – we’re not interchangeable cogs. Someone goes on vacation, people change roles, people move on – the successor may not do the same things in exactly the same way. There is an unwritten first step in every process: “Think”.

So I absolutely loved the following process story, that is ACTUALLY about sausage making and the importance of people in process, when I came across it on the This American Life podcast.

From https://www.thisamericanlife.org/241/20-acts-in-60-minutes/act-fourteen-8

In 1970, the Vienna Sausage Company of Chicago moved from the south end of the city to a new facility in the north end. The plant was brand new, state of the art, with perfect refrigeration, and spit clean. They move the production of their natural, old-world, hickory smoked, natural-casing hot dogs to this new facility. And it just isn’t as good as the product from their old facility. The hot dogs lack the right snap when you bit into them, and the color was more pink than red. Something was wrong.

Ingredients were the same, spices were the same, process was the same. Was the water different on the other side of town? They searched for a year and half, and could not identify the difference.

Then one night, a bunch of guys from the plant are out having a drink, gabbing about the good old days, back in the old plant on Maxwell Street. They start talking about this guy named Irving, one of those guys who knows everybody in the plant, has nicknames for everybody. And listen to what Irving’s job was. Every day, he would weave his way with the uncooked sausages through the maze of passageways in the old plant.

He would go through the hanging vents, where they hang the pastrami pieces, and it’s quite warm. And he would go through the boiler room, where they produced all the energy for the plant. He would go next to the tanks where they cook the corned beef, finally get around the corner, and in some cases, actually go up an elevator. And then he would be at the smokehouse. He would put it in the smokehouse and he would cook it.

And as they were telling stories about Irving– Irving this, Irving that– a light bulb goes off. In the fancy new modern plant, there was no Irving. Irving didn’t want to commute to the north side.

There was no maze of hallways. There was no half-hour trip where the sausage would get warm before they would cook it. In the new plant, they just stuffed the sausages in a cold room and cooked them in a smokehouse in the room next door to it. Irving’s trip was the secret ingredient that made the dogs red. So secret, even the guys who ran the plant didn’t know about it.

So they said, oh, my God, that is, of course, the reason. Why didn’t we know that? That’s the dumbest thing in the world to not realize. It’s right there.

How did they fix it? They built a new addition onto the plant about two years after moving in. In this room, they emulate the old area of the old plant… to simulate Irving’s walk across the old factory.

A process that was just a part of someone’s day, that no one had even recognized its significance. A human factor.

work

IT Process and Models over Time

Leave a comment

I recently came across this article:
My 20-Year Experience of Software Development Methodologies

The author discusses the methodologies he’s followed on various projects through the years, discusses the issues with each, and, presents that these are “collective fictions” that allow development teams to collaborate, an idea presented in the book Sapiens to describe how societies function in larger groups.

It’s an interesting read, and also interesting to reflect, on the changing processes and models used since I started working in software development. In 2006, the organization I worked for talked about reaching CMMI Level 3, and following a waterfall development model. By 2013, we were attending sessions on Six Sigma. In recent years, the interest has been in Agile/SCRUM.

The author accepts that methodologies are required to function at scale, but ultimately, what’s important is that you have teams that trust each other, and a structure in which agreements can be found. It will be interesting to see which models are trending 12 years from now.