MVP Summit 2015 – A Few (Surprising) Lessons Learned

MVP Summit is always an amazing event. This year was no exception.  It’s one part boot camp, one part super-secret secret-telling time, and one part family reunion. Along with that, we get cool swag (like the utterly amazing Data Platform jackets Jennifer Moser hooked us up with this year), interesting conversations, and time with the guys & gals who build the products we’ve bet our careers on. Needless to say, I was happy to be there.

This year was also a little different, and I want to talk about that for a minute. There has been a lot of buzz since Satya Nadella took the helm at Microsoft that things were going to be Different. That product teams were going to align, that they’d be smarter about how they build software, and that they’d move faster than they ever have before. I have to be honest… I thought it was all marketing hype. Until last week.

The very first thing I noticed on Monday morning was that the level of transparency was through the roof. As a person who builds software for a living, I know that we all err on the side of pretending like we have all the answers and that our process is bulletproof. That was not the message from anyone on the Microsoft team last week. While it is always awesome to hear about what’s new on the technical side of things, there was another level of value coming out of the talks. Honesty. A willingness to fail. Engagement that was real. Actual two-way conversations.

One of the things I love to do during presentations is take a lot of notes. Along with the obligatory talking points and feature notes, I like to write down things that are said by the presenters that resonate. I cannot share the exact quotes because of NDA rules, but I have been given permission to share the gist of what I learned.  Because I spend way too much time on Imgur, I’m including memes to illustrate my points.

Don’t be afraid to fail. Failing, and failing fast, gets you to the good stuff.

success kid

Sometimes, you have to admit that you’re doing something totally new and that you might not already be an expert. This is okay. Go learn it, then you can build it.

doge

There’s a lot of new stuff coming at us. Embrace it. It ain’t going away.

kitten hug

Applaud the person who points out that things aren’t on the right track.  She’s the one who is unafraid.  (And as Mr. Herbert taught us, fear is the mind-killer)

penguin cake

Experiment. Try something different. Be willing to fail and then try again. It’s science.

meme by: http://knowyourmeme.com/users/deathbyexile
That’s Neil deGrasse Tyson, y’all

In all seriousness, to hear these kinds of messages coming from the most venerable software development organization in our business was inspiring. It made me feel like going home and taking a few risks. It made me feel like we were all in this together. Data and data management is moving at an insane pace these days. Always changing, always moving forward. Keeping up is overwhelming on a good day. That the experts at Microsoft are saying , “We’re learning right along with you. We’ll get this.”, it is empowering.

My point is, the technical stuff was great. The product positioning information was helpful. But my real takeaway last week was that… well, let me share one little story…

I was in a meeting about a (NDA – sorry, y’all) thing. The presenter threw out some concepts and thoughts about the thing. I raised my hand and said, “I think I have a use case for you. Let me run you through a scenario that one of my clients has.” After I explained what I needed, I asked, “So, how would you solve this problem?”. The response? “I don’t know yet. But I think we can solve it together. Let’s stay in touch and see if we can come up with some good ideas.”

And that’s it right there. I went to a session about a topic where Microsoft didn’t have the answer yet. They still got in front of us and talked about where they were, what their goals were, and what they were doing to move forward. And when we had ideas or real-world problems to solve, they engaged. They asked us for help. Not “help”, as in, “fill out this survey for us; we promise we’ll do something with your feedback”. We were treated as peers and as people on the ground who had real value to add to the conversation. It was a little bit amazing.

And you know what? It’s working. They’re doing more, faster. They’re innovating in a way that big companies aren’t supposed to be able to do. I’m excited about where we’re headed.

So in short, thank you to Microsoft, the MVP Summit organizers, and everyone who makes our experience as MVP’s special. It was an awesome week.

Fail fast, my friends.

–Audrey

On Blogs – Think like a Journalist

Today, I was reading a blog post.  The article was published by a group that I would consider reliable and reputable.  It was on a topic that I have passing familiarity with, and would like to be better at.  I’m not going to name the post nor the topic, because that’s not the point.  Here’s what went down…

1130 Hours: Read post.  Surprised at the absolutes declared in the article.

1135 Hours: Read it again.  Think that either I’ve missed some really basic lessons on this topic, or that maybe the article has provided some less than ideal guidance.

1209 Hours: E-mail a friend who I know is an expert on the subject.  Ask him to read it and let me know if he thinks it is right.

1300 Hours: Get response from generous and patient friend.  His e-mail (which was longer than the blog post) explains in very clear terms that there are problems with not only the guidance that the article provides, but also how some of the fundamental concepts were represented.

1420 Hours: Go find another post on the same topic by another trusted expert.  Read it and confirm for the second time that my original suspicions about the article were correct.

1430 Hours: Pat myself on the back for knowing just enough about the topic to realize that it seemed off in the first place.

1445 Hours: Go back to blog post to write comment that maybe the article could use a second look.  See that someone has already done that.  Decide not to pile on.

Now, I’ve been watching a lot of The Newsroom and House of Cards lately, both of which have characters who are journalists.  I think that reading blog posts, articles, and books is a lot like being a journalist.  One source is not enough.  If you’re hearing something new or something that contradicts what you think you know, don’t take the article at face value.  Go find a second source, and make sure that the second source didn’t use your first source as their source.  (Caveat:  I do have a list of absolutely trusted writers.  But it is my list, and is based on a lot of factors.  Okay, fine.  I’ll share one.  His name rhymes with Tall Candle.)  Also, if you’re finding conflicting advice, don’t be afraid to ask questions.  Any writer worth her salt is willing to accept some peer review.

And yes, if you’re wondering, I felt very MacKenzie McHale for all of 3 seconds. 

??????????????????????????? (photo from: http://www.fanpop.com/clubs/the-newsroom-2012/images/33579445/title/mackenzie-mchale-photo)

I imagined myself, headset on, shouting, “We’re not going live with this until we confirm a second source!”  Then I remembered that no one but me was consuming this information.  Oh well.

If you’re on the other side of the keyboard and are writing an article you plan to send out into the world, here are a few guidelines to live by:

1) Unless you are 110% sure that your guidance applies 100% of the time, don’t speak in absolutes.  “It depends” is a running joke for a reason.

2) Find someone you trust to tech edit for you.  Heck, find two people.

3) Remember that there are a lot of young database professionals out there who are reading your work in order to figure out how to do their jobs.  Don’t take that lightly.

4) If someone comments on your article and says you’re wrong, engage with them.  They’ve taken the time to read and comment on your work.  Granted, there are trolls out there, but a thoughtful comment demands a thoughtful response.  And keep an open mind.

5) If you’re preaching something that goes against conventional thought, take the time to post links to opposing views.  Help your reader make an informed choice about which advice to follow.

6) Encourage your reader to do their own research with the information you’ve provided.

7) If you discover that you’ve presented bad information, correct the article.  Own it.

All that being said, the proliferation of online resources has made us all better.  Don’t be afraid to put your research and opinions out there.  Just research, verify, and test.  And look for that second source before going live with the scoop. 

Blog on, my friends…

–Audrey

Discovery… Not Just for Explorers

In the scramble to get hands on keyboards in a development shop, one of the most important phases of development often gets short shrift.  That phase is discovery.  I was lucky enough to spend a few weeks with one of our clients working through a formal discovery phase, and was reminded how valuable this time and effort can be.  It also got me thinking… How can any developer, regardless of project role, gather the information that normally comes out of a discovery effort?

Discovery Who? 

So what is Discovery, exactly?  Discovery is the part of development where you answer a few key and seemingly basic questions about the work you think you want to do.  These questions include:  Why? What? Who? When?  There are a few key outputs of a discovery cycle, including:

  • Problem statement – a short, concise explanation of what’s in need of improvement/enhancement/rework
  • Solution statement – a short, concise statement about what’s going to be done about the problem
  • Scope – a list of things that will be done, as well as a list of things that won’t be done
  • Assumptions – any assumptions that have been made about environment, people, technology, complexity, etc. in regards to the project
  • Risks – a list of things that can derail the project, which might include company direction, technology changes, dependent projects, or that “simple” external system that you need to integrate but haven’t had a chance to see yet
  • High-level time estimates – a high level SWAG (Stupid Wild-Ass Guess) at how long it should take to complete the work, or a time window based on other external factors
  • High-level resource needs – a high level list of people (or skill sets) and technology resources (hardware, software) that are needed to complete the project

Notably absent is one thing:  How?  That’s because the how is design, not discovery.  Resist the overwhelming urge to start designing the solution before you fully define the problem.  This is the part that I struggle with every time I’m asked to help out with the discovery phase.

A Developer’s Life

Discovery information will come at you in one of two ways:  either you’ll be asked to answer the above questions and help define the project, or someone might come to you with all or part of this information and expect you to be involved in the subsequent phases of the project.  In both cases, it is absolutely vital that you (Yes, you… the dashing figure reading this post) feel comfortable with the outputs of discovery before you start designing or developing anything.  This is known (in my head) as Sneaky Discovery.   (Credit to Julie for her invention, the Sneaky Proof of Concept… I’ve adapted the concept for Discovery) It ain’t as evil as it sounds, I promise.  Let’s talk about this one for a bit.

I know… it can be uncomfortable to question a project’s intent or setup, especially when you haven’t been asked to.  But bear with me for a moment.  I’m not asking you to put on your fedora w/optional press pass tucked into the band and annoy the ever loving crap out of the people around you while sporting your best Humphrey Bogart voice.  I’m just asking you to take 30-60 minutes and make sure that you feel good about the work you’re about to do.  Let’s look at a dramatic reenactment of a common situation:

 

Scene: John, a diligent data professional is at his desk, working on the latest product release.  Enter Manager (Mike).

Manager: Hey! Bob!  How are you?

John: It’s, um, it’s John.  Not Bob.  I’m good.  What can I do for you?

Mike:  Good, Bob, good.  Glad to hear it.  I just walked out of a Very Important Meeting with Very Important People, and I have a new set of tasks for you.  We’re going to speed up Database X.  Also, I have these 17 new reports that need to be developed… um, somewhere.  Let me check my notes… Ah, there we are!  I’ll e-mail this right over to you so you can get started.  How long do you think this will take?  Can you have it by next Friday?

John takes a deep breath, and time stops.  Enter Mysterious Announcer (MA).

MA:  Right now, John is faced with a career conundrum.  His fate is in his hands, even though he doesn’t realize it right now.  He can either nod and say “Yessir, right on that, sir” and make his manager feel temporarily happy about his decision to hire John, or he can ask a few questions that might make his manager feel a bit uncomfortable in the short term, but will save the company thousands of dollars in the long term.  Let’s see how John handles it.

Time restarts. John turns to his Manager.

John:  Gee, Mike.  That’s a lot to absorb.  I have a few questions to ask before I commit to a time estimate.  Mind if we sit down and talk through the project together?

Mike: (uncertain) Sure?  I think we can do that.

Angels sing, bells ring, beautiful and intelligent women begin to notice John’s unconventional good looks and charming, yet adorably shy, personality

 

Friends, this is your moment to shine.  When faced with a situation like this, it’s up to you to do your own version of Sneaky Discovery and make sure that you’re not diving into the shallow end head-first.

When John gets a chance to talk to his manager, here are a few basic questions he should be asking:

1)      Why are we doing this?  What is the problem we’re trying to solve here?  (Problem Statement)

2)      What’s the solution that we’re going with?  Is it the only one available?  Why did we pick this one? (Solution Statement)

3)      What are the things that we’re going to do, and how does each of them help solve the problem we’re fixing?  What are we NOT doing? (Scope)

4)      Any assumptions about technology direction, complexity, or anything else that led us to the next Friday deadline? (Assumptions)

5)      Anything I should know that can cause us to get off track? (Risks)

6)      How long did you assume this project would take?  Have you made any commitments about delivery?  (High-level time)

7)      Who else is working on this? Do we have a dedicated development environment? (High-level resources)

8)      BONUS QUESTIONS #1: Who is impacted by this change?  Is it okay if I check in with them?

9)      BONUS QUESTIONS #2: How are we testing this?  How are we deploying it?

This conversation will probably take less than an hour for a narrow scope of work.  It does two things:  1) you step into the project with more information than you had initially and, 2) you show your manager that you want to understand the work you’re doing.  Good managers appreciate this.  If you’ve a manager who doesn’t appreciate your questions and desire to understand the work you’re doing, you’ve got a lot to think about, my friend.

Now, the worst case scenario is that John’s manager can’t answer these questions.  What to do then?  In a perfect world, you pull the comically large brake and hit the giant red STOP! button.  Now, it is up to you to decide how to handle the situation.  I’ll tell you how I normally handle stuff like this, because it happens… often.

 

Manager: Um, I don’t really know why we’re doing this.  The CTO asked for it, and I’m here to get it done.  That’s why I’ve been the vice president of middle management for 15 years, damn it!

Audrey:  Okay.  I can do this work.  However, let me lay out some of the risks for you.  We don’t understand why we’re doing it, and we might make poor design decisions because we don’t see the big picture.  Also, without a clear understanding of what problem we’re solving, I don’t know how to tell you that we’re done.

Manager: Okay, works for me.

Audrey:  Can you put that in an e-mail for me?

 

If I feel likely to get burned, I put my concerns/feedback in e-mail.  If I trust my manager to hear me, I tell him in person.  The point is that I never dive into design or development until I’ve either gained broad understanding of the project or at least told someone that I’m working under less than ideal circumstances.

As long as we’re all sharing, let me tell you… we’ve all been there.  We’ve all taken the task, done the work, and delivered something without really knowing why.  It happens.  The trick is to know when you’re dealing with a tough situation and how to mitigate risk to you as well as your team.

You’ll likely find that it is up to you to help flesh out those Assumptions and Risks, and to make suggestions about Scope.  As the in the trenches guy, you’re probably aware of issues that your manager isn’t.  Don’t be shy about sharing that information.  Trust me, ‘tis better to air the dirty laundry at the beginning of the project than to grumble at the end because you “just knew” that this issue was going to come up.

An Aside on Scope

We’ve all heard of it, and if you’ve worked for any amount of time in this business, you’ve lived it.  The dreaded scope creep.  Many times, scope creep happens because discovery was left wanting.  Or, the team isn’t disciplined about sticking to the original scope.  The pain of scope creep is never totally avoided, but it can be minimized.  Foremost, make sure that you have some scope to work with.  Remember how Manager Mike said that he wanted to “speed up Database X”?  Wow, that’s a broad statement.  He also wants to do it pretty quickly.  This means that you probably can’t re-architect the entire system or purchase shiny new hardware to solve this problem.  You might end up with something like this in your scope statement:

Task:  Speed up Database X

In Scope:
1. Tune top 10 worst performing queries
2. Examine index maintenance plan and add key missing indexes
3. Archive old data that is no longer used and remove from primary database
 
Out of Scope:
1. Change logical design of the database
2. Upgrade hardware
3. Rework data access layer

On a highly regulated team, this may end up in a formal document.  If you’re like many developers and things run a little more fast and loose in your shop, there is nothing wrong with shooting off an e-mail or having a conversation about what can be done in the time you have.  You could say, “Mike, we have a week and a half to do this work.  Let’s focus on low-hanging fruit and non-invasive changes.  When we have more time, we can talk about more aggressive changes”.  (Managers love idioms like “low-hanging fruit”)  He might say, “Great!”, or he might come back with, “So if we wanted to address your out of scope items, how long would that take?”  Both are acceptable responses, and you should be ready for them.  Point is, put some boundaries around the work you’re doing, and set expectations about how much can really be done with the time and budget provided.  This allows you to be the guy who never says, “No”, but also protects you from unreasonable requirements.

Final Thoughts

One last thought on discovery within the development cycle.  As developers, we want to know everything up front.  We want details, and we want them now.  Here’s the thing… it ain’t gonna happen.  Take a deep breath, accept the unknowable, and focus your Sneaky Discovery efforts on getting some clarity on why you’re doing what you’re doing, what you’re doing (and not doing), and what might throw the project off.  The rest will shake out during design and development (and possibly testing), and that’s okay.  We’re never going to get it perfectly right, but asking a few of the right questions at the right time can get everyone comfortable with how the rest of the project is going to go.

Now, get out there, get proactive, discover some stuff, and get vocal about how your work fits into the larger picture!  I’m rooting for you!

–Audrey

A Giant Thank You, and a Link

First of all, thanks so much to everyone who supported, organized, and attended the Day of Data Warehousing fundraiser yesterday. I am humbled and honored to have had a chance to spend the day with all of you. Couldn’t have asked for a better group to spend a Thursday with!

As promised, here is the link to my slides, demos, databases, and documentation: http://sdrv.ms/16tszZZ

If you have any questions, comments, feedback, or just want to say hi, please get in touch!

Personal E-Mail: audreydhammonds@gmail.com
Work E-Mail: audrey.hammonds@innovativearchitect.com
Twitter: @DataAudrey

Model on, my friends…

–Audrey

Great way to begin 2013! (Hint: it involves a TLA)

Quick, happy announcement… My fellow Datachix, Julie Smith, has received the SQL Server MVP award for 2013!  Also, I’ve been renewed as a SQL Server MVP for 2013.  What does this mean?  Yeah… 100% of the people who blog on this site (all two of us) are MVPs!

mvp

So, Julie, while I am not the first to congratulate you, let me be the first to do it on our blog. 🙂

On a personal note, I am grateful and humbled to be a part of the MVP community for another year.  Having experienced 12 months of the program, I’m honored that Microsoft saw fit to include me for another year.

As a bonus, here’s a picture of Julie being awesome:

Wizard

Rock on, my friend!

–Audrey

p.s. Note to self:  It’s been a while since you blogged about anything, Audrey.  Get your act together and post more often!  (Nodding…)

Thoughts on the Latest PASS Fracas…

First, I want to tell you what this post is NOT about. It is not about the PASS BoD. It is not about Sri Sridharan. It’s not about my opinion of the decisions made by the PASS BoD in regards to the two open board positions. Okay, glad we got that out of the way.

Here’s what it is about. Community. Family. Even when we don’t agree with each other.

Let me tell you a story about myself… When I was 13, I played softball. My team took first place in our league, and that meant that we got to compete in the District Tournament. Now, our coach had the option to select 4 players from other teams in our league to supplement our team at the tournament. One of his selections was a first baseman. I was the first baseman for our team. I got benched. I was furious! I thought it was unfair that I lost my spot, when I helped our team win the league. I thought I should be on the field. I even went so far as to write a very strongly worded letter to my coach. (Yeah, I was THAT kid) I was complaining to my mom about the ordeal, and said that I didn’t like the girl who took my position.

Here’s what she said to me: “Honey, let me ask you something. What’s more important to you? That you’re the one on the field or that your team wins? She’s taller than you (important in a first baseman) and has a better bat. Are you going to blame her for your coach’s decision? You need to decide right now who you are. Are you the person who thinks of your team first or yourself first? I expect you to put the team first, and you had better be the loudest, most supportive person on that bench, and be ready to step up whenever you’re needed”.

My mom was never one to mince words. It was a hard lesson to learn as a kid, but a good one. Even though I disagreed with the coach, I stayed on the team. I cheered every play, and was ready to sub in as needed. Guess what? We won the District Tournament. I would have missed out had I quit.

What does this have to do with our latest PASS drama? Well, besides giving me an opportunity to tell you a story about myself, there is a point here. We’re a community, and a family. While we don’t always agree, and sometimes disagree vehemently, we’re still part of the same team.

And here’s my point. We might not all agree with the decisions made by our PASS BoD, but let’s cheer for our players. Let’s give Kendal van Dyke (Blog | Twitter) and James Rowland-Jones (Blog | Twitter) the best possible chance to be successful and effective as appointed board members. Will we hold them to a high standard? Of course. Don’t we always? Will we ask them to do a (mostly) thankless job for no pay? Yes. Will we tell them when we think they’ve made a bad decision? Yes, we’re pretty good at that. But, let’s give them a chance. They didn’t ask to be put in the middle of a controversy. They stepped up and accepted leadership roles within our community. That counts for something. Now, I don’t know James Rowland-Jones, so I can’t speak from experience about him.  But I can only assume that he cares about this community based on what he wrote here. I know Kendal personally, and I know that he’s a kind, hard-working person with honorable motivations.

Should we blindly follow the Board of Directors?  No, of course not.  Should we have an opportunity to vote on the by-laws?  Yes. Should we raise the red flag when we disagree?  Hell yes.  However, should we blame and publicly vilify two community volunteers who got stuck in the middle? Absolutely not.

Let’s all take a deep breath. I’ve done it, and here’s what I asked myself. If I were in Kendal or James’ shoes right now, what’s the one thing I would ask for? The answer I came up with is, “Give me a fair chance to show everyone that I can do right by the community”.

So that’s what I’m doing. Kendal and James – I’m cheering you on. I hope that you work hard and lead us well.

Wait… One more note before I go… Let’s be kind to each other.  The world is tough enough as it is without mean people in it. 

–Audrey

#Meme15 – Why do you blog?

I have a confession to make… Blogging is hard. Staring at a blank page, cursor blinking in that impatient, foot-tapping way, crappy blog ideas spewing from my desperate mind like oil at Spindletop circa 1901.

Pictured: Audrey having crap ideas

“I know… I’ll blog about my cat. I’ll, um, equate my cat’s love of shiny things to my love of foreign key constraints. You know, because foreign keys are shiny. Wait? What? I’m an idiot.” So, when Jason Strate (B | T) proposed the idea of #meme15, I was all for it. Tell me what to blog about? Save me from myself? Sign me up!

This week’s questions are:

1) Why did you start blogging?

2) Why do you currently blog?

Question 1: Why did you start blogging?

Let’s go way back to January 2010. Julie Smith (B | T) and I were talking and we said, “Hey! Let’s do a blog! It’ll be fun! We can write funny stories, be irreverent, and amuse ourselves with our oodles of witty”. I’m pretty sure there was wine involved. We didn’t think much about networking or career development or even education. We just thought it would be fun to do. Some technical blogs can be, shall we say… dry. We name no names. We both like the idea of making data fun. “Hey”, we thought, “we crack ourselves up regularly. Maybe we can crack someone else up”. That’s it. Almost 2 years later, we’re still blogging. We love it. And our reasons for it have evolved. Which brings us to…

Question 2: Why do you currently blog?

Easy. I can name all my reasons in three words: Me. You. Us. Oh, you want details? Gosh, you’re demanding. Okay, twist my arm. I’ll elaborate.

1) I blog for myself.

This is an important principle to me. I blog because I enjoy it. My first rule of writing is: Amuse Yourself. If something amuses me, I like to share the fun. I think that as humans, we’re all storytellers. We want to know that there are people willing to listen to our stories, and what is a blog post but a story? Sure, it might not be Shakespeare, but it’s still my story. It could be called narcissism to say that I want people to hear what I have to say, and that’s okay. Anyone who tells you that they’re 100% altruistic is probably trying to recruit you into their cult. Don’t believe them. They’re going to make you wear burlap robes and ugly running shoes and refer to their leader as Supreme Ultimate Bob. And burlap is so 1990’s.

Trust me. I'm only thinking of you.

Point is, on the day that I don’t get a rush from hitting “Publish” on a post is the day I stop blogging.

p.s. That’s my Gavin, showing off his new winking skills. Watch out ladies!

2) I blog for you.

It’s sappy. I know. But it’s true. Absolutely NOTHING in my professional life makes me happier than having someone tell me that a blog post I wrote (or a presentation I did) helped them do their job better. The idea that something I put out there made somebody else look smart… that’s so cool.

Dramatic reenactment: Me hugging our readers

Photo courtesy of Stuart Miles http://www.freedigitalphotos.net/images/view_photog.php?photogid=2664

This is part of the evolution of blogging. When we started, I honestly didn’t think anyone was paying attention. Then, I had a few people come up to me and say that they’d read my post on Random Topic X, and that they had a question or that they’d applied my solution. It was a little scary to realize that people occasionally pay attention to my ramblings. I realized that I had a responsibility to be as correct as I knew how, and to continue to share what I learn. And it is so SATISFYING to share information. Try it. You’ll like it.

3) I blog for us.

By us, I mean the SQL Community. A community like ours requires care and feeding. I’ve benefitted in a thousand ways from this loose network of passionate people, and if I’m going to take from the community, I feel an obligation to give something back. If everyone read blog posts but no one ever wrote them, then we’d all be reading the same Microsoft Support articles about Installing SQL Server 6.5 over and over again. Boring. Blogging allows me to contribute to this awesome community while letting my Geek Flag fly.

What? I'm a geek, not an artist.

Plus, I get to have cool conversations with interesting people. Like I said, “Sign me up”.

Blog on, my friends…

–Audrey