I’m Old, Part LXXI: A Quick Nerdy Flashback

I’ve collected video games for years, especially the ones from the early 80’s. I’ve come to appreciate how much thought went into some of the cabinet designs. Most of them were built to withstand drunk adults and to be maintained. For example, some of the Williams cabinets have a little mirror on the inside of the cabinet. You loosen a couple wing nuts and the whole monitor easily slides back. From the back of the cabinet you can access all the monitor adjustment controls and see what’s going on in the mirror. Nice.

This is a Robotron that Joe Holt and I bought from a campus arcade in Oakland. We did some hackery and were able run Robotron, Joust or Stargate by swapping in a game board set and a control panel. It worked nicely. The control panel above was custom made by Bennett Leeds. He was going to make it out of plywood, but he didn’t have enough so he used mahogany. It seemed blasphemous to put plastic buttons in it, but so be it.

Joe and I had a good time with this. We pulled the ROMs from the Robotron and dumped them. Joe wrote a 6809 disassembler and we started taking the game apart bit by bit and came up with a decent functional model of the game.

Reposting a Memorial

Originally published Friday, July 25, 2008 10:15 here.

A Tribute To Robert Carroll

I found out last night that my high school physics teacher, Robert Carroll, passed away very recently.

He was a teacher that was hard as nails and had it in his mind that he was going to push his students closer to their actual abilities rather than to the accepted median.

Here are his standards as I remember them:

  • He assigned homework practically every night and accepted nothing late without a doctor’s note.
  • All work was turned in with a uniform heading on the paper.  Anything that deviated was not graded.
  • All problems had to be done in given/find/solution form with the final solution boxed in.  Anything that deviated was penalized heavily.
  • No erasing was allowed.  Work that was considered to be incorrect could be crossed out with a single line.  Anything that deviated was penalized.
  • Labs were recorded in a bound, unlined lab book.  He transitioned you into labs where you wrote out the entire lab (procedure, data, conclusions), neatly and legibly.  He collected lab books at random times.
  • Definitions for units were boilerplate: <x> is the <fundamental/derived> unit of <time/extension/volume/capacity…> in the <standard> system <defined as/based on> …  (Ex: A Newton is the derived unit of force in the MKS system, defined as 1 (kg m)/s2.

He made it clear that this was a class in which physics was used to teach us procedure.  He established the procedures and made it clear what it would cost us to step outside the bounds.  The first quiz that he gave was nearly impossible to pass because of the amount of detail.  In fact, there were routinely students who lost more points on the quiz than were available.  He graded on a curve and that was a survival mechanism.  He insisted on using the ironically titled book “Modern Physics” by Charles E. Dull (and others) published in 1955.  He also scheduled a mandatory test on senior skip day.  And if you did something exceptionally stupid/ill-advised/dangerous you would be given the “Dufus Award” (a rebranded cheerleading trophy) for the class period – his version of a dunce cap.

In the process he did something that few other teachers did: he taught us how to study, how to solve problems, how and when to attend to detail, how to be responsible for our actions or inactions.  He demanded good work and accepted little else.  A lot of his students went to hardcore engineering programs and had the tools in hand to succeed.  Although I did not ask him for this, he wrote honest, top-notch recommendations for college applications.

Out of frustration, my friend Mark Hamm would draw an elaborate caricature of him on the blackboard most mornings.  Without missing a beat, Mr. Carroll would look over the work, erase it and deftly draw a cartoon pig with an enormous ass, with an arrow pointing it out (ie, the ham).  No spite – he could dish it out and take it.

My oldest brother and his peers formed a group called the Honors Physics Consortium as a coping mechanism and went to the trouble of (eventually) self-publishing a book about their exploits.

Mr. Carroll had a very long career as a teacher: 38 years.  That’s 38 years of students who went through his class or roughly 800 students in his honors class that were affected by him.  While not everyone agreed with his methodology, I believe his method had strongly calculated purpose and prefer to believe that the other 799 students, like me, have come to recognize the benefits of the purpose.

Rest in peace, Mr. Carroll.

I’m Old, Part LXX: Sensible Strategy

When I started at Atalasoft, I was very happy to be in a mix of being in my wheelhouse and outside of it. The company’s main line of business centered on moving pixels from point a to point b, something I have done countless times in the past. What was new was working in C#, learning the expected idioms of the .NET ecosystem and learning what our customers wanted.

Stack of files

For example, we had a toolkit that included one hundred forty something separate objects for performing transforms on images in one way or another. If you walked all of PhotoShop’s menus and options, you’d have a pretty good idea of what was there. I thought this was really cool and a great selling point and looked at ways that this could be expanded or made easier to use and so on. I though of demos we could set up at trade shows, including a photo booth with goofy image transforms and so on. Most of that got shot down.

Here’s why: no matter how cool that kind of stuff was, no matter how eye-catching it might be, that wasn’t where the money was.

I’d like to say that I learned this lesson quickly, but it took some time and kind but persistent reminders from Bill Bither for it to really sink in. There was money to be made in the really boring side of image manipulation. For the most part, our customers wanted to be able to read scanned document images, do some simple manipulations, display the documents in a web browser or in a desktop application, and save the changes.

I’ll give you an example of what we did that was wrong and how we later corrected it. TIFF is an image format that gets used very often for scanned documents. On the surface, it looks like a very straight forward file format and one that you could write a very sensible set of tools for working with it in an afternoon. Except for one thing: because of this, the ecosystem of image files is polluted with crap files that were created by well-intentioned people who missed key portions of the spec. Don’t get me started talking about photometric misinterpretation and old-style JPEG files.

We had some basic tools for manipulating TIFF files, but they were kind of stinky. We assigned a job to one of our engineers to make a set of tools that would provide an accurate and bullet-proof representation of the data within a TIFF file and which would then let our customers manipulate them all they wanted.

And while this is a very useful thing to have, it is exactly the opposite of what our customers generally wanted. There were some that really cared about being able to stitch in a particular data tag into one IFD in a TIFF file, but for the most part our customers and potential customers didn’t care one whit. Most of our customers wanted to be able to do this to a TIFF document:

  • Find out how many pages there were
  • Read thumbnail images of each page
  • Read some basic metadata
  • Reorder pages
  • Remove pages
  • Add pages
  • Merge documents

And most importantly, they wanted to do all of those things without having to learn a single thing about the TIFF specification. Not. One. Thing. And I can’t say that I blame them. I’ve read the TIFF specification from cover to cover several times. It’s not exactly a page turner.

So I built a new set of tools to do all of these things and made them as kind and friendly to our customers as possible. I made a simple document object that contained a collection of page objects. You could manipulate the collection any way you wanted: shuffle, remove, add from other documents, whatever. Each page was a GOF flyweight pattern so that you could manipulate documents with potentially thousands of pages without taking a huge memory hit. The actual cost was paid when you committed a document by saving it.

The best part was that all of this was implemented in terms of the tool set that we had already shipped: the one that let you do all kinds of terrible things to a TIFF file, provided that you knew and understood the full specification. Any one of our customers could have implemented this themselves.

And here was the important lesson from all of this: our customers honestly didn’t care about flash. They had straight forward problems to solve and they didn’t want to become experts in images or documents or standards. They wanted to get their job done with as little effort as possible. If we gave them that through sane API design and with actual helpful technical support, then they could meet their goals and the cost of a license quickly paid for itself.

And we soon found out that there was a lot of business to be had doing just this. Fancy lens flare or glass brick transforms? Nah. Manipulate their collections of craptacular specification-violating TIFF files? Yes.

And I leave this here as a piece of advice for people who are looking to start their own businesses writing software tools or tool kits: there is a lot of business to be had in finding a pain point in day-to-day business programming and removing it. To quote Bruce Tognazzini: “It’s hard to be easy.” There is a nuance in building an API that does what your customers want 90% of the time with minimum pain. Take the time to become the expert and find out how to shield your customers from that pain and you will be on a road to success.