the terminals shine

getting ready to start my day, doing a couple little tasks while watching AMC's Halt & Catch Fire in the background. i really love the show; mostly 'cause it's like re-living the microcomputer revolution. kids today don't know what it was like. every month something new and innovative came out. and most of the things that came out withered and died 'cause they were too expensive or the market for the product didn't really exist.

but at the time, that didn't matter too much. it was a crazy time and there were no rules. or rather, people were more willing to creatively bend them. i was on the tech side of the fence in the 80s and was privileged to work on firmware, application programs and even an operating system to compete with MacOS and Microsoft Windows. i wrote a lot of very cool code, but strangely, the only thing that's still in use from back in the day is some code for older ATM machines & a hack i wrote for DOS / Netware.

the common mis-conception of the 80's was sofware was written by lone coders working feverishly through the night. and that's not completely untrue. but there were plenty of small organizations, three or four coders working together to get stuff done. (and remember, this is back when version control was flinging floppies around the room.)

one of my favorite bits of writing from the time is this bit from Geoffrey James:

"The computer center is empty,
Silent except for the whine of the cooling fans.
I walk the rows of CPUs,
My skin prickling with magnetic flux.
I open a door, cold and hard,
And watch the lights dancing on the panels.
A machine without soul, men call it,
But its soul is the sweat of my comrades,
Within it lie the years of our lives,
Disappointment, friendship, sadness, joy,
The algorithmic exaltations,
The long nights filled with thankless toil,
I hear the echoes of sighs and laughter,
And in the darkened offices
The terminals shine like stars." --from The Tao of Programming

on enlightenment

had an amazing dream this morning where i reached enlightenment.

starting out as a visit to my childhood home in ohio, i remarked to myself how it looked different than what i remembered. further investigation revealed portions of it had been taken over as a dormitory by wright state university (apparently it was also much larger than i remember.)

randomly wandering into the downstairs family room, "i" split into multiple individuals representing not only the different parts of myself, but avatars of friends, family and mentors responsible for shaping my personality with Charles Baker playing the role of the friendly trickster and Peg AtKisson carrying a sword, representing my intellect.

my task was to complete (within a fixed amount of time) an introductory multiple choice test and then query 5 (sometimes 6) guardians of the experience of humanity (librarians of the akashic record?) to discover the secret to enlightenment. agriculture, mechanics (tool building), programming, and music/literature were the guardians i remember.

after being confused by a few questions, the part of me that was memory whispered a strategy in my ear. treating it like a logic puzzle, i asked each guardian what i had to ask the others to achieve enlightenment. apparently this was a good strategy, and in retrospect makes me wonder if half of the guardians always told the truth and the others always told lies.

the last couple of answers were unintelligible jibberish, but memory helped me out here and i just repeated the lines fed to me (thanks, mnemeosyne!)

when you reach enlightenment, there's apparently a very nice cocktail party where all the pieces of your psyche mingle, catch up on gossip and generally have a good time. i commented to one of the guardians that i didn't feel especially more enlightened and was told that i'm not the one who was enlightened.

it turns out that the i that i perceive myself to be is not the i that is enlightened. upon attaining enlightenment, every bit of you is enlightened and it's an experience that the conscious ego can't comprehend (maybe that's why it looks like a cocktail party where the rest of my society of mind is having a good time.)

Tom Deplonty will be happy to hear one of his compositions was being performed at the party. So Tom... you're apparently going to pen the soundtrack for enlightenment (no pressure.)

The Persistent Myth of Product

This morning i had to take it a little easy. I burned myself out last night debugging and needed a small break. So i spent a little extra time sipping my coffee, enjoying my garden and reading a random book from my young adulthood. The book i picked up from my bookshelf was Michael Tomcsyk's "The Home Computer Wars." It's a first-hand account of Commodore's rise as a home computing juggernaut in the early 1980's. Written in an informal, first-person style, it's a surprisingly fun read; sort of like a romance novel for tech geeks.

One of the things I noticed about the book was how few rules there were to making "hit computer products" in the early 80's. The market was still developing and everyone seemed to have their pet theories for how to build the next, great thing. The locations involved, Sunnyvale and Santa Clara, made me think of the companies I worked for in the valley; how their approach to structuring a business was straight out of the 80's and how that's probably why they're no longer around.

I'm thinking mostly of PalmSource, the software spin-off of Palm, Inc. PalmSource was structured in a pretty standard way: executive management at the top, different divisions for sales, marketing, operations and engineering. We worked in matrix style teams with product definition the responsibility of the team's product manager. I don't want to dispiarage anyone on the PalmSource team; with very few exceptions everyone involved were highly competent professionals. But in retrospect, I believe PalmSource's organization and rigid responsibilities set it up for failure.

My team was working on the software to secure apps on the device from other, potentially rogue apps. I was happy with the work I was doing, but the software security work I was doing quickly laid bare a sad truth: our product manager had no idea why we were including security features.

People who have implemented security features on products will probably understand how frustrating this can be. Security features frequently do things like pop up dialogue boxes or cause certain types of data accesses to fail. As feature developers, we can dial up the access protection and annoying interactions or we can dial them down. It's not exactly true that good user interface and good security are mutually exclusive, but it's frequently the case (especially in the first rev of a product.)

So as developers, we cheat. We have our software refer to configuration files to say how frequently we should annoy the user and what resources we don't let other programs access. It's great for the software developer, but it's really just kicking the can down the road. Someone, somewhere needs to make a decision about how often you annoy the user. And it's a horrible choice. If you err on the side of caution, people hate your user interface. If you err on the side of convenience, you open yourself up to vulnerabilities.

At PalmSource, we convinced ourselves that our product manager would make these decisions or would be the conduit for customer requirements. But we made a bit of a mistake. Our product manager, while very competent in the general handheld space, had about zero experience with security features and not a whole lot of experience evaluating user experience. And this was the guy who was going to make the decision in the usable vs. secure issue.

I don't blame our product manager. He was a good guy put in a situation outside his area of expertise. It did take him a little longer to recognize this than it should have, but he had a lot on his plate. As engineers, we had no way to report this issue to upper management because our management was actively hostile toward security features. (Seriously, my manager once fell asleep during a meeting when we were trying to explain the problem to him.) We had no authority to make a decision on our own, because PalmSource's corporate culture was "product tells engineering what to build, not the other way around."

In several old-school companies, the product management group is responsible for surveying the market, making educated guesses about economic trends and customer behaviour and developing a target for price and performance. Usually (hopefully) guided by the executive team's directives on ROI and general location in the price / quality matrix, they help engineering prioritize features for the products under development.

But it's increasingly important for product managers to have a deep knowledge of the product features. In the old days when the division between product marketing and engineering was established, products were effectively widgets with five or ten bullet-point features. The "quality" of your product was defined by the presence of a bullet-pointed feature or it's relative feature. Product managers didn't need to know what the features did, only that we had one.

Fast forward to the modern era... The iPhone finally got the term "user experience" on the lips of executives. Just-In-Time manufacturing is the default rather than the exception and various SaaS successes have people talking about how to provide value through an API. Selling software in Sili Valley is less about putting bullet points on boxes and more about adapting your API to fit into someone else's value chain.

So why do we still have product managers that aren't also sales engineers? Why did I, as an engineer, have to explain the business ramifications of poor design choices to our product manager? Why did I have to use back-channels to find engineers in our customer's organizations and ask *them* about their business objectives?

And I think the answer is "the Persistent Myth of Product."

There's a truism in marketing that to make money you can do two things: figure out what people want and make that, or figure out what you're good at making and make people want to buy it. In the early 80's, the vast majority of the populous wasn't familiar with what computers could do. It's safe to say people didn't know what they wanted. Sure, we all thought we wanted a device with more flashy graphics, a better keyboard and more memory. But that's just the "computer fetishist" view of computing products. What we needed to know in the early 80's was how these devices were going to fit into our lives.

And while I like to grouse about Apple's developer support from time to time, it's hard to argue they didn't do an EXCELLENT job communicating how Apple products fit into people's lives. When the Macintosh came out, IBM offered a series of ham-fisted windowing programs to counter the Mac's "ease of use" argument; ditto for Digital Research; ditto for Microsoft. I believe IBM and Microsoft survived because they understood the lucrative enterprise market.

In the early 2000's, Apple struck again with the iPod. It wasn't the first personal audio player, but it was the first to not treat the user interface as a bolt-on afterthought. And Apple did another EXCELLENT job communicating how the iPod fit in a user's life: buy an iPod, take your music with you. By comparison, Diamond and Creative were selling Rios and NOMADs like you would sell a PC component: by listing bullet points on the side of a box.

Traditional product managers are taught to identify key features of a product segment and then communicate those features to an engineering team. They are taught that all you have to do is make a widget slightly cheaper or slightly better and the world will beat a path to your door. And in many segments this is true.

But it's not true in software. Or at least it's not true for organizations that don't want to rely on dumb luck.

"Product" is not defined by a market, but by observing people, figuring out how technology can affect their lives, building it and communicating that change to the end user. Don't depend on an existing market to tell you what to build. Depend on your customer's need first. Or... figure out what you're good at building and figure out how it fits into your customer's life.