Jason Specland: Consultant, Comedian

Making it up as I go along. Always.

Project Estimation for SharePoint: A Parable

EXT. OUTSIDE THE JUNGLE, DAY

An intrepid treasure hunter and his local guide stand trepidatiously outside of a dark, mysterious, wild jungle.

Treasure Hunter: How long will it take for us to get through the jungle?
Guide: It’s hard to say. The jungle is filled with dangerous traps and difficult terrain.
Treasure Hunter: Okay, how long will it take to get two miles through the jungle?
Guide: Seriously, it’s hard to say. I don’t know what we’re going to encounter…
Treasure Hunter: Just ballpark it for me.
Guide: Okay, well I’m really not certain, so I’m going to have to assume the worst… Three days?
Treasure Hunter: Three days!? To go two miles!? What are you, incompetent or something?
Guide: Okay, if everything goes absolutely perfectly… A day, maybe? But don’t hold me to that…

CUT TO: Two days later…

EXT. INSIDE A PIT TRAP IN THE MIDDLE OF THE JUNGLE, DAY

Treasure Hunter: We’re a day over budget. I’m not paying you for this, you know.

A Dog Named ‘Cat’: What Happens When You Name a SharePoint Field ‘DisplayName’?

Sometimes I feel bad for junior front-end developers who think they have a decent handle on things, and then get thrown into the world of SharePoint. They don’t have the SharePoint Spidey-sense that tells them something simple is going to go horribly wrong.

I was called on to assist a junior developer who was tearing his hair out trying to do simple CRUD operations on list items in SharePoint in an Angular application. I’d already written a (somewhat) simplifying Angular service to deal with most of the annoying parts of the REST API, so I was baffled that he was having so much trouble with it.

So I stepped into the code with him, making sure he was calling my service correctly. He was. I began to panic. Was there a bug in my service? I stepped into the service code. Everything looked fine, and SharePoint returned the proper “201 CREATED” response. But every field except one was being set.

The name of that field was “DisplayName”.

Curious.

I proceeded to create a new Custom List called “TestThisBug.” I created a field called “DisplayName” and another field called “FooDisplayName.”

sp2013-displayname-bug-in-interface

Simple, right? Then I tried to get the fields via the REST API.

sp2013-displayname-bug-in-rest

The field did not appear. Curiouser and curiouser.

I tweeted the tweet above, and told the developer to name the field something else and be on his way. I wondered, “What if we try the same operations using the JSOM?”

So, on my SharePoint 2013 VM, I fired up a Site Collection, created my list, and wrote me some JSOM code. I wrote some code that will get that list item, select a few fields (including “DisplayName”) and just display it in a table.

sp2013-every-field-but-displayname

I got every field I asked for, except for “DisplayName” which was silently disregarded. When I tried to ask for it directly via get_item('DisplayName') I was told it wasn’t initialized, despite the fact that I’d explicitly requested it.

sp2013-uninitialized-property-jsom

I began to wonder if I would run into the same creation issue my coworker was encountering. I wrote some more JSOM code to actually create a list item with the “DisplayName” field set. And, even more strangely… It worked!

sp2013-succesfully-created-item-with-jsom

I then logged on to my Office 365 Dev Tenant to see if this is still an issue.

o365-displayname-bug-in-rest

o365-displayname-bug-with-jsom-added-item

Yup! Sure is! You can see here that I can get the field name from the list via list.get_fields(), but when I return list items, the field is not returned, despite explicitly requesting it. You can also see that the “DisplayName” field that is returned from get_fields() doesn’t have any super-secret internal name that I’m missing.

But, as before, adding a list item with that field via JSOM works just fine:

o365-displayname-bug-with-jsom-added-item

So, kids, I guess the moral of this story is pretty simple: Don’t name your fields “DisplayName.”

Here’s the bug-test JSOM code.

Geniuses and Poets

“If we treat each other as if we are geniuses, poets and artists, we have a better chance of becoming that on stage.” — Del Close

Del Close, the Father of All Longform Improvisers

Del Close, the Father of All Longform Improvisers

The past week at work has been kind of frustrating. Miscommunication all over the place. Balls being dropped. And all of it seems to end up in my lap for some reason, even though I’m not the guy in charge. I feel let down by people I trust. I get angry at people.

But then I take a moment to realize that we’re all inherently good people trying to do our best. We’re all on the same team. Even demanding clients aren’t demanding because they enjoy being jerks, but because they’re under their own set of pressures and deadlines. My coworkers didn’t drop the ball because they have a vendetta against me, but because just like me they have a ton of stuff on their plates and clear communication among a large number of people is a super-hard problem. And if I should lash out at them, they have no idea that I’ve had a crappy week and my son’s been sick and I just generally feel overwhelmed.

I know that I work among the very best. I see the results of their work every day. It’s just a matter of building that same level of deep, abiding trust with my coworkers that I have with my teammates.

Although I think they might look at me funny if I patted them on the shoulder and said, “I’ve got your back” before every work day…

Wednesday Links

A Rube Goldberg machine HTML form.

Randall Degges on why we shouldn’t worry too much about super-high availability without considering the cost.

Don Romaniello strikes another blow against the tyranny of “Who What Where” in improv.

Listen With Your Whole Body

In improv, we learn to “listen with our whole body.” When performing in a scene, it is important not just to hear the words that our scene partner says, but we must also “hear” their facial expression and their body language as well. Newer improvisers tend to lean so heavily on words that they miss these cues, or don’t send them. Experienced improvisers know that you can speak volumes without uttering a single syllable.

When coaching improv, I work very hard to get the people I’m coaching to realize this. To understand it. To feel it in their very bones. One of my favorite exercises for this is one in which two actors stand back-to-back, and think of an emotion… No, they don’t just think of an emotion… they use every bit of their sense memory to bring that emotion to life. They live in that moment as fully and completely as they can. And then they turn around, and begin the scene silently, taking in the full range of their partner’s face and body.

This exercise works because human beings have evolved over the millennia to be deeply and profoundly in tune with the most subtle emotions encoded in the human face. Take this classic example:

An Illustration of the "Thatcher Effect", by psychology professor Peter Thompson, 1980

An Illustration of the “Thatcher Effect”, by psychology professor Peter Thompson, 1980

When the image is upside down, nothing looks amiss. It is only when the face is right-side up that our supercharged facial recognition circuits kick in and the image suddenly appears grotesque.

As consultants, being able to listen to our clients, truly listen to them, requires listening with our whole bodies. We need to listen to both what they say and don’t say. We’ll find more often that what they don’t utter aloud can say so much more than what they do. What causes them pain? What do they fear?

This, however, is where our goals in improv and in consulting part ways. In improv, we always want to confirm fears. We want to make the pain worse. If there’s a fire, we want to pour gasoline on it rather than water. In consulting, it is our job to help our client, relieve their pain, and grow their business. Technology is a tool with which we do this, yes, but as far as tools in the belt go, technology isn’t nearly so important as empathy.

We’ll never truly understand what our client needs unless we listen with our whole body.

Improv Stuff This Week: (5/8/2016 – 5/14/2016)

Monday, May 9, 9:00 PM: Regina at the PIT (Underground, with Chariot)
Thursday, May 12, 8:30 PM: 10,000 Hours Session, “The End is In the Beginning” at Simple Studios It’s all about using the information you’ve already created to push your scenework forward, rather than continually inventing.
Saturday, May 14, 11:00 AM: Drop-in imrpov practice group at CAP 21, contact me for more info

Thursday Links

Nothing about the “Future of SharePoint” here. That’s been covered to death.

Making Your REST Calls Simpler by Changing the Metadata Setting by Marc D. Anderson (sympmarc). Help your SharePoint REST calls be a little less “chatty.” But, as Anders Austad points out, it must be enabled for use on-prem. (Also, it requires SharePoint 2013 Service Pack 1. You are on SP1 by now, right?)

FREE Office365 and AzureAD for Developers course on Udemy by Sahil Malik. Haven’t gone through it myself yet (it’s 7.5 hours long) but the source is an extremely well-trusted one.

Death by GPS, at Ars Technica. People blindly follow technology, get into trouble. Film at 11.

Unsubscribe

I’ve Seen the Future…

Well, by now every SharePoint person on Earth has seen and blogged about the #FutureOfSharePoint announcement. Most of the top SharePoint bloggers have just been sitting on all this until today, but I run in far humbler circles.

So let’s look at what I wanted, and what I got:

A Master Page that’s responsive and compatible with modern web design sensibilities. Microsoft has warned us against modifying it, lest we pay the “modification tax,” but our clients keep saying, “Responsive, responsive, responsive.” You’ve got to meet us half-way.

Office Dev PnP Tooling (or something like it) baked in to Visual Studio just as well as the Feature Framework tooling was baked in to VS 2012/2013. And while we’re on the subject, can we please have some less roundabout ways to get things done? As much as I love Vesa Juvonen and the work he and his team have done, this needs to have some real Microsoft institutional oomph behind it.

And while we’re at it, let’s have a better story for client-side, non-App/Add-in-oriented development. SharePoint 2013 is approaching the sunset and 2016 is being born, and I’ve still yet to actually write an app for a client. They don’t want to set up that infrastructure, and if they have no intention of adding untrusted stuff from the internet they shouldn’t have to.

Got it, got it, got it. I’m so psyched for the SharePoint Framework, I can barely contain myself.

Okay, this isn’t SharePoint so much, but what’s the deal with javascript Intellisense in an Angular app in Visual Studio? Eh, it won’t be much of an issue for me in the future, since after recently completing a moderately large javascript project, I now solemnly swear to use Typescript forever and ever, amen.

They explicitly showed people using the SharePoint Framework using VS Code. More modern “cool” tools, less monolithic IDEs. Nice.

Either integrate Yammer like you promised or get rid of the damn thing. I was at the SharePoint Conference in Vegas where they announced the acquisition, and the two products seem no better integrated today than they were then. SharePoint 2013 could have been the launchpad from which real Office Social Networking took off, but instead Microsoft strangled it with a garrote from the back seat of a late 70’s model sedan.

Some kind of way forward for InfoPath! Surely when it comes to something as basic to human business life as forms, there must be some happy medium between “let’s use an end-of-life’d technology that no one at Microsoft will touch with a ten foot pole” and “time to write another fat check to that javascript developer!” Sure I’m usually the javascript developer they write that fat check to, but I do have some sympathy for my clients.

Nope. Yammer and InfoPath are still dead as disco. Sorry, Tessio. It’s just business.

A device that sends an electric shock to any person who attempts to use SharePoint as a relational database back-end for a super-customized, nowhere-near-the-box, not-at-all-like-SharePoint front-end. Yes, this device would probably kill me, but my smoking corpse could serve as a warning to others…

Not only did I not get this, but the SharePoint Framework will probably encourage me to do more of that type of development. It’s probably best for my health anyway.

The Future of SharePoint

Today, at 12:30 PM my local time, Microsoft is doing a big reveal at an event they call, “The Future of SharePoint.” It’s apparently going to be something big, because the SharePoint Social Media Universe has been able to talk of nothing else for weeks now.

I’ll be anxiously watching this event today, but before I do, I thought about the things that I’d like to see in the future of SharePoint.

Crystal Ball on Ice, courtesy of https://www.flickr.com/photos/punktoad/4302556980, (CC BY 2.0)

Crystal Ball on Ice, courtesy of https://www.flickr.com/photos/punktoad/4302556980, (CC BY 2.0)

Now these are not prognostications. I know an MVP or two, but they’ve remained faithful to their NDA’s. This is just what I would like to see happen with SharePoint.

  1. A Master Page that’s responsive and compatible with modern web design sensibilities. Microsoft has warned us against modifying it, lest we pay the “modification tax,” but our clients keep saying, “Responsive, responsive, responsive.” You’ve got to meet us half-way.
  2. Office Dev PnP Tooling (or something like it) baked in to Visual Studio just as well as the Feature Framework tooling was baked in to VS 2012/2013. And while we’re on the subject, can we please have some less roundabout ways to get things done? As much as I love Vesa Juvonen and the work he and his team have done, this needs to have some real Microsoft institutional oomph behind it.
  3. And while we’re at it, let’s have a better story for client-side, non-App/Add-in-oriented development. SharePoint 2013 is approaching the sunset and 2016 is being born, and I’ve still yet to actually write an app for a client. They don’t want to set up that infrastructure, and if they have no intention of adding untrusted stuff from the internet they shouldn’t have to.
  4. Okay, this isn’t SharePoint so much, but what’s the deal with javascript Intellisense in an Angular app in Visual Studio? Eh, it won’t be much of an issue for me in the future, since after recently completing a moderately large javascript project, I now solemnly swear to use Typescript forever and ever, amen.
  5. Either integrate Yammer like you promised or get rid of the damn thing. I was at the SharePoint Conference in Vegas where they announced the acquisition, and the two products seem no better integrated today than they were then. SharePoint 2013 could have been the launchpad from which real Office Social Networking took off, but instead Microsoft strangled it with a garrote from the back seat of a late 70’s model sedan.
  6. Some kind of way forward for InfoPath! Surely when it comes to something as basic to human business life as forms, there must be some happy medium between “let’s use an end-of-life’d technology that no one at Microsoft will touch with a ten foot pole” and “time to write another fat check to that javascript developer!” Sure I’m usually the javascript developer they write that fat check to, but I do have some sympathy for my clients.
  7. A device that sends an electric shock to any person who attempts to use SharePoint as a relational database back-end for a super-customized, nowhere-near-the-box, not-at-all-like-SharePoint front-end. Yes, this device would probably kill me, but my smoking corpse could serve as a warning to others…

It’s Not About the Bicycle

I’ve only been a consultant for about a year now, but I’ve been performing improv comedy for about twenty. And as I work more in consulting, I’m starting to see that consulting and improv comedy aren’t so different.

One trap that beginning improvisers tend to get caught up in is the idea that the arbitrary, imaginary thing that they’re doing is actually the important part of the scene. It’s not. The imaginary thing is just a vehicle that helps us explore human relationships and emotions. It’s the set dressing around which we build the characters that the audience really wants to see.

There’s an old improv coaching idiom that I use often: An audience never leaves an improv show saying, “Yeah, it was funny and all, but they never *did* finish putting together that bicycle!” Sure, come on stage and start building a bicycle, if that’s what the moment has inspired you to do. But we want to see how these particular characters react to building a bicycle.

Courtesy https://www.flickr.com/photos/radlmax/21830232766 (CC BY-ND 2.0)

Courtesy https://www.flickr.com/photos/radlmax/21830232766 (CC BY-ND 2.0)

Similarly, when you’re on a consulting gig, if you’re talking to the real decision makers, they don’t care about technology. They only care about what the technology does for their business. No CEO ever leaves a post-engagement meeting saying, “Yeah, we made a million dollars, but we never *did* use SharePoint!”

As technical consultants, it’s easy for us to get enmeshed in the minutia of technology. After all, that expertise is what they’re hiring us for, right? Wrong. They’re hiring us because we know how to use technology as a lever. Technology is a tool. If it doesn’t serve a useful business purpose, it’s a toy.

I’m a SharePoint developer, and my hammer is Visual Studio and when I have my tech-blinders on, everything can look like a nail. When you bring me in, chances are that someone’s already decided that their project is going to live on SharePoint. My instinct isn’t to argue with you. Who doesn’t love those juicy billable hours? But as a good consultant, I hope to be a trusted adviser to my clients. It’s my responsibility to say when SharePoint ain’t the tool for the job, even at the cost of billable hours. Hell, even at the cost of the whole gig. If someone respects the integrity of your advice, there will be work for you some other day.

Just like in improv, it’s the relationship that’s the important thing. It’s not about the bicycle. It’s about getting where you want to go.

« Older posts