When I think of logical reasoning with just the right amount of emotion, I think of Mr. Spock from Star Trek.

The creator of Star Trek made the Spock character half human to preserve the emotional aspect of decision making. Spock was logical until some kind of conflict emerged that logic alone couldn’t overcome, and then his human side would reveal itself to help Spock make the best choice, usually in a matter that was purely emotional, such as sacrificing himself to save the Enterprise. Sometimes his team–the crew of the Enterprise–didn’t like the choice but most of the time, he brought a level of even thinking to the complex decisions a crew of a starship in the 23rd century faced. Dr. McCoy represented the purely emotional side of decision making, the foil to Mr. Spock, and Captain Kirk was the leader that was ultimately responsible for the outcome.

The Enterprise captain’s chair, where many decisions were made and carried out. I took this picture at the Icons of Science Fiction exhibit here in Seattle.

On the bridge of the Enterprise, the officers collaborated on decisions. The officers would debate the options, and the option’s value was weighted based on who presented it. Do we fire on the ship? Send an away team? Will raising shields show hostility? Captain Kirk would listen to the input of his officers and then go with the choice that he believed was the best. As the de facto leader, he had the power to do whatever he wanted, but as a smart leader, he listened to the experts around him.

According to B. Aubrey Fisher, collaborative teams making a decision should go through four stages: Orientation, Conflict, Emergence, and Reinforcement. In orientation, everyone meets and gets to know each other, and identify what the decision is. That’s when people size each other up and start to figure out how much of a voice they will have in the process. Then the conflict begins. People argue, dispute each other, and have heated discussions, and then work out their differences. (Dr. McCoy was often the voice of passion against Mr. Spock’s logic.) This leads to emergence, when the people talk and clear up any vague opinions. Finally, the people make a decision and justify it to themselves.

On the Enterprise, Captain Kirk assesses a situation and gets input from his officers, makes a decision, and communicates it immediately. The officers–his team–put the decision into effect (shields up!). Later, he’ll add the details of the decision scenario to his captain’s log. He gets the right information as fast as he can and makes a decision that he will stick to. Once you fire phasers, you don’t get to take them back.

Meanwhile, back at Starfleet HQ, the decision to extend peace accords with the Klingons goes through the decision making process, including the requisite approvals, and the status of the process is tracked by the diplomats involved. Once a decision is reached, it is communicated to the United Federation of Planets and the war is over. This is a longer process and involves a substantially larger number of people with wide expertise, but it’s not really that much different than what happens on the bridge of the Enterprise.

In both situations, the success of the decision making depends on the empowerment of the people involved, the availability of information, and the successful communication of the decision. This is what businesses need to understand if they want to be more agile and rapidly adapt to changing conditions in the world market. It’s up to us to help them

As the 23rd century gave way to the 24th and Captain Picard took the lead on the Enterprise, collaborative decision making improved and the crew responded more quickly, and more thoughtfully, to challenges. The Starfleet officers studied the decisions of previous crews and learned from them. They weren’t afraid to try something new or to challenge conventional thinking. And they always worked together.

With an investment in effective decision making, future generations of business leaders will be able to boldly go where no one has gone before.

“Calling all techies! [My wife] lost her contacts on iPhone during her latest sync. I’m restoring from a two-year-old backup, her second-most-recent backup, but wanted to restore from her contacts in her mail system. Unfortunately, she has a Mac but uses Outlook. This isn’t even an option in the iTunes/Info tab. Thoughts?”

Challenge…..ACCEPTED.

First, open up Outlook for Mac and click the Contacts tab. Then click File->Export…. Click the “Contacts to a list” option, then click the right arrow.

You’ll be prompted with a window to save the file. Name it something and put it somewhere by clicking Save. Click the Done button in Outlook and you’re finished exporting.

Now open up Address Book. Click File->Import… and find the file you exported from Outlook. Click the Open button and then you get this:

See that option that says “Ignore first card”? Make sure that’s checked. Now click the right arrow. You’ll be presented with the first contact in the list.

On this screen, for each contact, you can confirm that the fields are correctly mapped. You’ll have to do this for every contact. Or you can trust the import implicitly and just hit OK.

Once you have finished, clicking OK will import the contacts into Address Book and you’re good to go!

Click through and watch in HD to get the full experience.

Back in the early Oughts, web services and service-oriented architecture were the rage. Microsoft’s .NET and Sun’s Java platform were the de facto tools and technologies that developers and architects used to build complex SOA capabilities. I was part of this wave of excitement, and I was very lucky to have the opportunity to work on an extremely ambitious project in research & development. This project aimed to unify the enterprise services (web services and otherwise) in a meaningful way.

I found some of the code for this project on an old USB stick and recorded a fifteen minute demo, which you can sit back and enjoy. I recommend clicking through to watch it on YouTube, as it’ll be easier to see.

This is the first time I’ve shown Retrospect since 2002, and since it was a project I was enormously passionate about, all the memories came flooding back and I was immediately familiar with it again.

I also had to fix numerous bugs to get it to work in Visual Studio 2010 and .NET Framework 4. As I navigated through the code, I felt a little sad. This project was abandoned, and the original server holding its source code (mercilessly housed in Visual SourceSafe) has long since been scrapped. The guy I worked on it with left EDS years ago, and the patents we filed lie dormant, never to be granted.

Retrospect does some amazing things that were really ahead of their time, like interface introspection, code generation, interactive code development in a graphical environment, service orchestration, and more.

Looking at the code really showed me how much I’ve grown as a developer, and how much I even knew back then. The architecture uses the MVC pattern, there’s a hearty attempt at separation of concerns, and the object-orientation is ambitious, if not wholly effective.

I sometimes wish I could redo the whole thing in WPF, but I have so many other things I need to do instead.

The chief engineer’s requirements were basic and simplistic: create something that tracked substation construction materials, like clevis joints and copper clad steel earthing rods. That was it. So that’s where I started, and I built a fairly simple Microsoft Excel 5.0 workbook to track everything. It was called Requisition Purchase Order Information, or REQPUROI for short. (Yeah, my creative naming skill was 1/300 back then.)

Not an actual screenshot of REQPUROI, but the same version of Excel.

As I learned more about the business and worked with the engineers, I added more features to REQPUROI. I listened to their complaints about their workflow, understood how they did their jobs, and figured out how I could make their jobs easier. I learned Visual Basic very quickly. Eventually, that Excel workbook could effectively model the cost of creating a substation in terms of the material costs. Further, it let the engineers identify opportunities to improve the design with a net reduction in construction costs. My eventual goal for it was to integrate with AutoCAD and the supply chain to track in real-time what materials were at the service center and determine what purchasing power the utility had in negotiating orders for more clevis joints and copper clad steel earthing rods. But instead, I was promoted into IT and my career took off.

I was nineteen years old.

Since then I’ve worked on some really cool stuff, the most recent of which was Future Health eConnect. When I started at Future Health, the company was still selling its legacy product, written in Visual FoxPro, called Virtual Office Suite. The president told me in my interview, “I have a vision of a new product, and I want you to build it.” So I did, with a lot of help from some great people. I hired a UI designer who worked exclusively on the Mac and iOS platforms, and we worked side by side for two solid months to come up with the design aesthetic and user experience for eConnect.

And now I can look at it with quite a bit of pride:

There is so much of me in that product, in its visual design, its layout, its features, the way it’s delivered, the user experience. There’s a lot I wish I could improve, but I know that it’s in great hands. I don’t want to go on and on about how great eConnect is here, so head on over to the YouTube channel to see some of its features. Go ahead, I’ll wait here.

Today I was thinking about REQPUROI and I wondered aloud what it would be now, all these years later, if I were still working on it. Some ideas I would have loved to be able to do back then:

• 3D visualization of the materials with callouts for individual components
• Direct integration with AutoCAD so the engineer could see the components that make up a deliverable piece of equipment
• Integration into an ERP system for supply chain management
• Export of materials lists for the as-builts, so the engineers could verify that the materials were in place post-construction
• A mobile version of the application with multitouch exploration of the materials and inventory
• Product lifecycle management capabilities so the engineers could see opportunities for reuse of materials post-extraction and manufacturing
• Utilization of ISO 10303 for exchange of information between REQPUROI and CAD/CAE as well as Product Data Management systems, internal and external

The possibilities are endless. The budget would have to be!

As an aside, I’ve always had a certain fascination with PLM. When I was at EDS, they owned Unigraphics, aka UGS, now part of Siemens, and I often daydreamed about what it would be like to work on PLM software. A few years later, I authored a proposal for Microsoft to use PLM in the development of the Xbox, but it went nowhere.

All of those bullet points up there are ambitious, to say the least. But that first one, hmm, that one’s interesting. In fact, Future Health eConnect has that feature. In the Subjective Note, there’s a 3D body diagram that allows the user to specify points of interest on a 3D model and annotate them. Here’s an example:

What’s really cool about this is you can rotate the 3D image, and the annotations move along with it, into and out of view:

I can’t take credit for this. That goes to the brilliant graphics engineer on the eConnect development staff. I just think it’s amazing and the functionality has a lot of other practical uses. It’s quite a bit more exciting than a clevis joint:

But the applicability is still there.

Can you imagine building something like a rocket and having a model of the rocket with all of its components, and the components’ components, all the way down to the nuts and bolts, and if you are missing any one of the components from a bolt to the ignition button, it’s indicated on that model? You would have a visual representation of the materials needed to build that rocket from start to finish, along with a printed report of the bill of materials, with integration into the supply chain, integration into the PLM tools, integration into the flight engineer’s laptop and the safety engineer’s iPad, integration with the factory floor systems for construction, with all of that available in a dashboard in the back office. The vice president of production development could say, “We’ve improved the time from design to test by a factor of three.” The vice president of manufacturing could say, “We reduced the cost to manufacture a rocket prototype by 11% over last year.”

As you can see, I’m very passionate about this.

At the utility, once a substation’s construction was completed, a team of engineers would inspect the substation. This process is known as an “as-built.” On the as-built, an engineer would visually inspect various items at the substation, enumerated on a checklist. He would use a spotter scope to look at the parts that were out of view or high up. The engineer tech would have a printout from REQPUROI and check off each item that the engineer confirmed was built as expected.

I imagine in a modern version of that materials tracking system, the engineer could use a handheld device, like a Droid or iPhone, to zoom in on the items and capture images, which could be analyzed on the device against a preset list of expected data points. Each substation would have its GPS coordinates stored in the tracking system, and each constructed component’s image could be geotagged. Back at the office, the data that was downloaded from the device into the main tracking system could be analyzed and spread out into the ERP system, the CAD system, and more.

With that capability now, in 2011, what can we do in 2021?

When I became the CTO of Future Health in 2009, one of my main initiatives was pushing our new product to the cloud. From a business perspective, I knew that the benefits of cloud computing–reduced cost, reduced support, scalability, security–would have an immediate impact. I also knew that from a marketing perspective, cloud was in. At the time, Microsoft’s cloud offering, Windows Azure, was in its infancy so it was not a contender for our product.

Fast-forward a year-and-a-half, and Windows Azure has grown into a comprehensive platform-as-a-service option. When we were starting up, PaaS was a concept more than a reality. Whereas Amazon AWS provides a straightforward infrastructure hosting solution in the cloud, Azure and its PaaS competitors offer more comprehensive capabilities that are designed to streamline the development and deployment of cloud applications.

One advantage that Microsoft has over other vendors is its connection to developers who use the Microsoft stack. As Microsoft has watched its bread and butter business move from the desktop into the enterprise, this connection becomes key to their cloud strategy. If a developer who builds ASP.NET applications for an insurance company can translate his skills to a PaaS cloud scenario, then that insurance company will logically consider that value when Microsoft comes calling with the Azure enterprise cloud offering.

This is, however, a bit of a double-edged sword for Microsoft. Web 2.0 leans heavily toward non-Microsoft development tools, like Python/Django, Ruby on Rails, LAMP, and even Java. Microsoft has had a lot of difficulty winning the hearts and minds of developers who are building applications like Facebook and Groupon. Further to that, the PaaS offerings in the open source realm don’t have the kind of baggage that a product like Azure has, as they don’t have to appeal to the enterprise. Heroku, for example, offers a very simplistic model for provisioning and deploying Ruby on Rails applications, with a fantastic add-on business model to add more capability like MongoDB, Cloudant, and memcache.

Heroku is nice, but I’m not convinced that Microsoft is as concerned, except for maybe the Heroku-Salesforce connection. Microsoft developers aren’t exactly the type to jump ship to a completely different technology that won’t pay their bills. AppHarbor, a Heroku-like offering for .NET developers, is the one to watch in the simplified PaaS space. It’s less expensive than Azure, easier to configure, cheaper, and takes a lot less time to deploy. AppHarbor still has a ways to go before I feel comfortable putting my company’s fortunes in their hands, but I am watching them closely.

As Microsoft fleshes out its Azure offering and figures out how to nail down the level of customizability and configuration that cloud developers require, it will become a much more attractive platform for developers that work outside the enterprise space.

Every day I have to find a balance between the two roles. When I’m working my dev team, we devise very innovative solutions to extremely complex problems. Then I put on my CTO hat and remind them that we have to limit scope so we reduce the delta on delivery. While still wearing that hat, I relay the release schedule and feature set to the president, marketing, and sales, and then react appropriately to their concerns.

What I have discovered in working these two roles is that I am capable of managing the duality and the separation very well. The real challenge comes in balancing what the executives want with what R&D can produce, and doing it without paying lip service. Every decision I make has to take into consideration the impact to our customers, the cost of the decision (in terms of both financials and people care), the overall timeline, the current assets versus future needs, the returns, and whether we’re capable.

To say the least, my communication skills have taken a giant leap forward since coming to work here over a year ago. I had plenty of experience dealing with C-level executives and even board members, but it was always on the side of delivery. In other words, I only had to make promises and then keep them. I was never involved in the process of deciding which promises to make.

Our customers are our greatest asset. They continuously provide amazing feedback for us, they help us improve the product, and they participate in its growth in a very organic way. I always try to keep that in mind when I’m planning our roadmap or working on a feature set. While the software architect in me really wants to build a compelling feature that the users are asking for and will love, the manager in me knows that working on that feature now, rather than six months from now, will cost us substantially more.

At the end of the day, all I really want to do is create compelling technology that makes someone’s life better, and I get to do that. To reach that goal, I turn to the advice of Tim Gunn: "Make it work."

Chris Farley: You remember when you were with the Beatles?
Paul McCartney: Yes.
Chris Farley: That was awesome.

But anyway, what I can tell you about this piece of functionality is that it’s really cool, and the reason I’m building it is because our customers said they wanted it on our product community site. Our customers might say something like, "We’d really like to have a picture of the patient available." I’ve wanted to add that functionality to our product for quite some time, so I started thinking about how I can add that to our product in a meaningful way that isn’t just tacked on.

Yeah, it’s a really neat product and a really neat new piece of functionality. When it’s released, I’ll tell you all about it.

Chris Farley: Now you were also in The Purple Rose of Cairo?
Jeff Daniels: Yes I was.
Chris Farley: Remember when you were doing your movie and Mia Farrow was watching and you, um, came down from the screen and talked to her and you were in black and white when you were on screen but then when you talked to her, you were in color.
Jeff Daniels: Yeah what about it?
Chris Farley: You remember that?

“All those names are all caps,” I said. “But I don’t want them in all caps, unless the name is Stella.”

Nobody laughed.

“How can I do this in C#?” I asked. Socrates would be proud.

I felt like a million answers were thrown at me. Use Substring! Use StrConv (that’s VB.NET)! Use the .NET function thingy!

And like magic, this code appeared.

string fixedFirstName;
var culture = Thread.CurrentThread.CurrentCulture;
var textInfo = culture.TextInfo;
fixedFirstName = textInfo.ToTitleCase(firstName.ToLower());

“Ok, that’s great, but we can make that a bit more concise, right?”

var fixedFirstName = Thread.CurrentThread.CurrentCulture.TextInfo.ToTitleCase(firstName.ToLower());

Save, build, run test, hg ci, hg push, go home and eat a salad. But I didn’t enjoy that salad. How could I after committing that abomination?

“Gut,” I said, “relax and digest that salad, because I’m about to cleanse my soul with a little bit of Ruby programming.”

And it was done.

firstName.downcase.capitalize!

We ship our product on June 7. It’s my first commercial software project. Everything I’ve done previous to this has been in the enterprise, relatively safe in the confines of a large corporation where the users were my coworkers and didn’t spend their own personal money on the stuff I created. This is something entirely different.

I like adventure.