Tuesday, September 17, 2013

Windows 8 in the Enterprise

I am a big fan of Windows 8.  I watched Hanselman's video early on, and I "get" the OS and what Microsoft is trying to do.  I have it installed on my desktops and laptops at home and absolutely love it. So when it came time to try out a Windows 8 tablet in the enterprise, I jumped at the chance.  Our support department loaned me an HP tablet with a build of Windows 8 on it to evaluate briefly.  Here's what I thought of it:

Network support:
For whatever reason, I was unable to connect to my work domain and remain connected.  This is not limited to the HP tablet device as our infrastructure group tried unsuccessfully to help me get my home laptop with Windows 8 on the network.  This wasn't a problem with older versions of Windows.

Mobile Iron support:
Our company has chosen to use Mobile Iron to deliver a mobile experience.  Mobile Iron explicitly does not support Windows 8.  This means that the best we can do with these devices is wifi on the local domain.  That’s not a great solution because it’s not truly mobile.

Ease of use:
The outlook client for Windows 8 works in the desktop only mode.  This means that the interface is not optimized for touch.  This makes Outlook difficult to use without a mouse.  The docking station the HP came with did not include a trackpad or a mouse, so I was constantly switching between touch and the keyboard, which isn’t particularly comfortable.  Compared to an iPad, it feels clunky and unnatural just to browse email.

Summary:
I know our organization is not ready to handle Windows 8.  Our choice of mobile vendors doesn’t support it.  I don’t know if the difficulty getting on the network is Windows 8 or my domain account, but for me, it’s an unusable mess.  Also, based on the difficulty of getting the device configured for use and the lack of Mobile Iron support, it’s also possible that Windows 8 isn’t ready for organizations, either.  I ended up giving the tablet back within a day, just very very disappointed.

I would love to hear any other opinions of people who have tried 8 in the Enterprise


Monday, September 16, 2013

The Myth and Danger of Experience

I was having a discussion with a veteran developer the other day.  During this discussion he laid out a problem that I knew another developer in the company had solved a while back.  Or at least it sounded the same. It was at least worth a five minute conversation in my book, and I advised him to talk to the other developer.

His response? 

“I've got twenty-five years experience writing code, and I don’t need anyone else’s input.” (paraphrased.  It was close to that, though.)

I was taken aback.  I am a strong proponent of collaboration.  I've heard and live the aphorisms.  You know, along the lines of “None of us is as smart as all of us.”  

Why in the world would anyone, presented with a willing second set of eyes and an open invitation to collaborate, refuse?  Fear of having to change what you've already done?  Fear that the other person will know more/you’ll be embarrassed?

Another thing that was said during that discussion:  "I can code on my own.  I have done this long enough to be accountable for the code I write.  At what point am I responsible for the work I do as an individual?" (paraphrased again.)

Again, I was agog.  My response was "Well, honestly, I feel that collaboration works well right down to writing lines of code.  It's called pair programming, and I would like to see us do more of this kind of work."  

He looked at me as if I'd said the sky was green and the grass was blue.  

I don't know.  I thought that in software and in life, as you got more experienced, you realized how much you don't know.  Like Socrates said, "True knowledge exists in knowing that you know nothing."  Except something about software development breeds in certain people this hubris, this certainty that they do not need other opinions, that they do not need to collaborate.

And in doing so they do not realize how isolated and shallow that "deep body" of experience actually is.

I don't assert whether solution that the veteran developer proposed was a good one or a bad one, given the requirements.  Only that if it was a good solution, a five minute conversation would not have changed it, and might have shared organizational knowledge around.   Instead, the siloing continues, and I continue to strive to break the silos.