Tuesday, April 21, 2009

Star Trek, the Borg, and Peer Reviews

Once again we engage in a topic that might not seem, on the surface, to be of architectural significance. Good architecture rarely emanates from a single brain, rather it is from the pre-borg hive-mind that we achieve the elevated levels of elegance and purity found in systems that cannot fail, effortlessly scale, and extend with ease.

In a galaxy far, far away, there exists a quasi human species that has adapted to technology with such embracement that every thought of every being is shared, considered, and to the degree reasonable, executed flawlessly. I know this because I watch Star Trek. Everything I ever needed to know I learned from Star Trek. For instance, I know that engineers are not supposed to ever provide accurate estimates when asked how long a repair will take. Our answers must always be padded by a factor of 30% so as to appear to be miracle workers that can deliver under pressure.

I also learned never to wear a red shirt to work, don't insult the tall guy with the ugly forehead, and on the planet Vulcan, the seven year itch means something ENTIRELY different than on Earth. But I digress.

Humans on Terra Firma have not yet perfected the hive-mind of a Borg cube, and so we must share our thoughts via the provincial process of written and verbal communications. This makes the whole collectively-creating-an-architecture thingy a bit problematic. We architects have opinions about what is right, and learning that the left side of the northern hemisphere thinks our ice caps are melting, just torpedoes our photons!

I had the benefit, years ago as a cadet, to be on a development team where I was clearly the weakest member. Oh, I pulled my own way and found a niche as the user-interface guy, but I also had to pitch in and help with code throughout the application. This meant trudging through database calls, thread management, caches of caches, arrays of arrays, event-driven processes, transporter re-assemblies and host of other cool and terrifying app/dev scenarios. OK, I made up the part about transporter re-assemblies.

The point is that I had to learn to accept criticism from a variety of people, some of them younger than me; and I had to engage in frequent peer reviews to consider my own code with a clinical eye and personal detachment. It was tough at first because I had been a paid consultant for almost a decade by that time, so I didn't think I was a slouch. But I adopted the 'tude that being right and the author of great code was not as important as implementing the best ideas the team could generate. Sometimes those ideas were mine, but the law of proportionality (I was one of six) mandated that most of the time someone else's ideas would prevail.

It's like the time the Organians prevented Kirk from starting a war with the Klingons - He thought he was justified until the Organians made all of the weapons super hot so no one could fight. OK, so it's not exactly like that, but the point is, even Kirk had to admit when a better idea was presented.

Do you have a clinical eye and a personal detachment to your own efforts? Monty Python defines an argument as "a connected series of statements intended to establish a proposition." Clearly, I didn't learn that from Star Trek. Do you offer your code, or your documentation, or your proposals, or even long emails up for peer review? Do you accept criticism, commentary, or complaints about that which you produce, or is your first instinct to defend your creation because, of course, you're smart.

If your job involves the creation of a product (applications, systems, servers, white papers, architecture, ...) that is the result of experience, creativity, and judgment then you should actively seek out the opinions of others. Find two other people with whom you can build a challenge relationship based on the aspirations of higher quality regardless of authorship. Agree to consider everyone's ideas, including your own, with a clinical eye and a personal detachment.

Go where you've not gone before. Accept only the best ideas, do not resist because resistance is futile. Live long and prosper by engaging in fact-based, non-emotional peer reviews. Warp factor 10 - to infinity and beyond (wait... wrong meme).

Follow by Email