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