Building a better Vulcan

Outside of the office, I love nostalgia, but inside, I am the first to promote change. Keep the things that work. Build on those things, and throw out the bad.

However, when Paramount Pictures took this approach with Star Trek, I was afraid of the change. I did not trust that JJ Abrams would be able to handle the job.

This was because I was not Paramount’s Product Owner, and their team did not ask me for buy-in, when they gathered requirements to fix something that I didn’t think was broken.

I was wrong. The movie was great, and I learned a lesson I have been preaching to others for years…

“The needs of the many outweigh the needs of the few.

–Mr. Spock, Wrath of Khan”

This became clear today, as I was reading new words of wisdom this week from Joel “on software” Spolsky…

“Typically, the product owner wants something simple and easy to understand for the users, featuring a telepathic user interface and a 30" screen that nonetheless fits in your pocket, while the developer wants something that is trivial to implement in code.

Lacking a product owner, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense if you’re a Vulcan. The best programmers are notoriously brilliant, and …have a tendency to get attached to their first ideas, especially when they’ve already written the code.

One of the best things a program manager can add to the software design process is a second opinion as to how things should be designed…

….ideas for how the UI should work, which might be better, or worse, than the developer’s idea. And then there’s a long debate.”

For those of you that speak Scrum, I have substituted Joel’s use of the label “Program Manager” for “Product Owner” to point out that our objectives are the same—the common techniques that work from one software process to the next are essentially the same. Common sense is universal.

Software Engineers know the “how” better than anyone, but the “what” must be defined by those that interact with the customer—or better, by the customer themselves. However, we can’t forget that ancient Decade proverb “everyone doesn’t know what they don’t know”. That’s where the give-and-take and “happy mediums” of good design come from.

Despite what you were taught, compromise is not a bad thing.

In fact, its what makes good teams great. Meeting in the middle has nothing to do with losing ground. It is about everyone coming together to see the big picture and finding the optimal solution for all involved.

Code long and prosper.