One of the symptoms - or maybe sub-sins - of coding lonely is coding without requirements.  Let us start, as we so often do, with an analogy.

We're planning a big road trip, you and I. We're going somewhere on vacation.  Here's what we've decided so far: we're taking my van, the SQLbus. We're going somewhere warm, we're taking your friend Steve, and we're splitting all the costs three ways.  Now, given this plan, how successful do you think we're going to be at achieving a decent vacation?  Nobody's even talked about specifically where we're headed - do we even agree on what "warm" means?? Nobody's talked about supplies, where or how we're sleeping and eating - campgrounds? motel? B&B? - the direction we're headed, how long we're staying, how much we're willing to spend, etc etc etc. 

With a vacation like that, you're going to head out in a random direction; drive around for four times longer than you want to in THE most boring, backwater, ugly places possible; spend TEN times what you wanted to, and get next to no value out of it; and argue with your roadmates the whole way through.

This, my friend, is how software is developed and sold in shops all over the world every day.  Make no mistake: there are shops that do it up right, with requirements, tech specs, and solid code. May their days be fruitful and their nights free of support calls.
  But we're not preaching to those shops. We're preaching to the poor lost souls who wander, nearly directionless, through the deep mists of scope creep.

Okay, okay, enough waxing poetic.

Without clear directions from the business owners, you can't create clear tech specs, without which you can't create a system that works. In a shop that works without real requirements, everyone is used to coding lonely.  A revolutionary idea like gathering and documenting business rules will most likely meet with a lot of resistance.  Even if it doesn't, getting real requirements is something of an art form. You can't just send the BA an email to say "We need your requirements".  You have to sit down in a room with the business folk and developers, talk it out, write it down, poke holes in the use cases.  As you move through the development lifecycle, you'll have to revisit and update those requirements.

This stuff isn't fun, which is why nobody does it.  But while you can just hit the road with a friend and a credit card, you can't pin the success of your business on the planning methodology of a college road trip.

Happy days,
Jen McCown
http://www.MidnightDBA.com

P.S. Yes, I know I should've photoshopped the image to read "Code Trip", but gimme a break...it's not my strong suit, and it's past midnight!

This was rather a difficult blog to write, mostly because I feel like I have an underdeveloped grasp of women's issues.  I'm a fierce proponent of women's rights - people's rights in general - but in my mind I'm still stepping around the sensitive spots in society.  If I seem a bit awkward today, you will - I hope - understand why.

Today is International Women's Day, which is one hell of a big coincidence. I didn't know about the national day, but I was thinking hard today about Women in Technology.  Did you know there's a SQLPASS WIT virtual chapter?  I only heard of it last year.  And I have to admit to you, again, that when I first heard about the Women in Technology group, I rolled my eyes.  I quickly changed my mind at the WIT Luncheon at PASS09:

"Someone asked me yesterday what the big deal was with women in technology, why do we need our own cause?  ...at a base level it's largely about this lingering underlying assumption that certain things are men's jobs, not women's." - From my blog on the SQLPASS09 Women in Technology Luncheon

In my PASS recap (that's the eye roll blog, above), I said, "I'm going to get involved when I get back, and be sure to bring my daughter to a meeting or two.  ...she needs to see that what I do - being a technogeek - is really something cool and worthwhile."  Well I went looking around, and as it turns out, we don't have a local chapter of WIT, or anything like it. I'm thinking hard about starting a Dallas chapter of WIT, and I keep circling back to that same question: Why do women in technology need our own group? What can a group for women do for women?

It feels like a strange pond to jump into. On the one hand, gender differences in the workplace really seem like they should be a thing of the past. It seems almost silly, or as if we're trying to play The Woman Card, to say that there's a big enough need for WIT to form a local chapter in Dallas. But when I look at it closer, there are a number of things that speak to the need for a gender-centric group. Like I said, I want to show my daughter - all my kids, really - the reality of equal opportunity, equal ability.  And "women in tech" is a subject people love to talk about. There are some specialized issues, and there are specialized attitudes and feelings about it.

The other big thing that has me really interested in starting this chapter is this: At any given SQL user group meeting or conference, men outnumber women 20 to 1 at least.  In the workforce, men outnumber women. This tells me that something is bringing more men to the field, or at least to the meetings, than women.  Technology is an amazing, enthralling, and well-paying field, and I want to help make tech careers as available as possible.  It's not about excluding men - WIT loves involved men in tech. I think it must be about blowing away the last few cobwebs of "that's not for you, little girl".

Happy days,
Jen McCown
http://www.MidnightDBA.com

I'm going to be honest with you: my minor in college was in technical documentation. I can wield a bullet point list like a turbocharged light saber at the slightest sign of trouble.  But I must say that I've never, ever been in a shop that fell within acceptable parameters for product and process documentation. Either the documentation requirements were overreaching and cumbersome, and we ended up with documents that conformed to the rules, but weren't at all readable or helpful; or, the requirements were nil, and the halfhearted powerpoints and Word docs sitting abandoned out on Sharepoint were pathetically out of date.

I want to know what, if anything, is important to you as a DBA and developer. So answer me this:

• What's your stance on documentation? Love it, hate it, need it, avoid it?
• What (if anything) do you and your team document? Requirements, change requests, data dictionary, technical guide, user guide, help menus, testing, etc etc.
• What's the best or worst documentation experience you've had?

(Did you see that? See that fierce bullet point list?? Yowza!)

I rarely meet a soul who is actually enthusiastic about talking documentation, so I'm going to point the finger at a few people. I tag you, @SQLChicken, @BuckWoody, and @LadyRuna!  Those who I didn't tag specifically: consider yourself tagged regardless.

Happy days,
Jen McCown
http://www.midnightdba.com

Charity is awesome. SQL is awesome. Books are awesome.  A SQL book for charity is pure liquid #BACONWIN!  SQL Server MVP Deep Dives, benefitting WarChild.org, is such a book*.

And the good folk at the SQL Perspectives blog - Jeremy Lowell, Chris Shaw, and Richard Rodriguez - are adding more bacon to the awesomeness in the form of a chapter by chapter perspective on Deep Dives, complete with guest bloggers. *Ahem*  Like yours truly, for example. My blog on Chapter 5, Itzik Ben-Gan's "Gaps and Islands", was just published this morning. You know, if you feel like reading about an awesome chapter, in an awesome book, written by an awesome guy (meaning Itzik, not me, though I'm pretty cool too).  *Ahem*

Read the perspectives. Buy the book. You'll win karma points, knowledge, and the enjoyment of an excellent book, well written for a good cause.

Happy, charitable days,
Jen McCown
http://www.MidnightDBA.com  

* Footnote: "Responding to BillG’s MVP Summit challenge to “Do philanthropy where you are,” The SQL Server MVP Deep Dives book is a collaboration of 53 MVPs sharing their expertise and passion for SQL Server. This is an all-volunteer book. All author proceeds are going to WarChild.org – an organization that helps children traumatized by war. Because this is a book for charity, Manning Publications wanted to also donate and gave us a higher than normal royalty. In addition, if you purchase the book through this link: www.SQLServerMVPDeepDives.com then the purchase will also count toward Warchild's Manning affiliate account and Warchild will receive an extra 10% of the purchase." -Paul Nielsen

Another set of random thoughts have come together today to form a conclusion: I'm famous. I'm a movie star. Johnny Depp has surely heard of me.

World famous in Poland!

Not really, of course. I'm about as famous as my Walgreens pharmacist. But I've noticed that the people who meet me who have seen my blog or videos think I'm famous, and Sean and I occasionally get treated as semi-celebrities. Not in the champagne and limos sense, but more the "nervous to meet you" sense. It's yet another unanticipated result of the glory of being active on the Internetz, within a community. Some people see my stuff, my picture, my name, so I'm famous. (Seriously, guys, whatever. I don't have the actual numbers, but I think all of 20 people read my blog regularly. Which is fine.)

What's got me thinking about this?  First off, I'm working hard on a session for SQL Saturday #35, and I actually have to practice talking to empty rooms and pointing at a blank wall (I haven't finished my demos yet, okay?). So I envision standing in front of a room full of people, talking about SQLy things.  There's this...not illusion...but enhanced appearance of authority, because I stand up front and talk in front of a PowerPoint. Of course, anyone with any salt at all will be able to say whether I actually know what I'm talking about or not. I'm just exploring the idea of perceived authority.

Another thing that has me thinking on this is Brent Ozar's most recent blog "Dear Blog Author", where he says "bloggers seem like celebrities". It's true, they (we) do. When we see someone in the context of a fairly reliable medium, then we're influenced to associate the person with reliability, or expertise. "Hey, Oprah is on the internet, and so is Jen! So Jen is famous, like Oprah!" The more austere the medium, the more authority a person seems to have. So people who webcast are seen as more knowledgeable than bloggers (generally speaking), and book authors are more knowledgeable than webcasters.  

Soooo, let's see. Blog, check. Internet videos, check. Public speaking, May 22 check.  I guess I'll write a book, and then the millions will pour in, right?

Right?

In all seriousness though, I'm writing and videoing and speaking to improve my own SQL skills, and hopefully to help out (and entertain) you guys.  I'm not one of the SQL demigods, but I know some stuff.  I'm really glad you're coming along for the ride. Even if you turned down my autograph headshots again.

-Jen McCown

http://www.MidnightDBA.com

Content rating: Beginner, tips

Right click to download the setup and example code here.

I had a neat little request come across my desk yesterday (we'll abstract the details a bit for separation of company and blog).  In essence, it was "find me all the salespeople this month that have met ALMOST all the requirements to get the Superdude bonus". They want to see who's meeting most, but not quite all, of their sales goals so that management can encourage them and send reminders. 

Let's say we already have a convenient rollup table with all the salespeople's monthly summary info in it, so we can focus.

Table 

Here's the rollup table:

Tip: By the way, I can't stress enough the importance of knowing and using your datatypes properly. Tinyint is only 1 byte, and holds integers from 0 to 255...why would I need int (4 bytes), or even smallint (2 bytes), to hold a month number? Save space where you can. (Now, I am using money instead of smallmoney, but hey, these guys are selling bridges and ladders to the moon....that's likely to rack up numbers higher than the $214,748 limit on smallmoney).

Requirements 

Let's say that the requirements for the superdude bonus stretch over three consecutive months, and are:

• Total sales of over $100,000 in month 1
• Total sales of over $150,000 in month 2
• Total sales of over $200,000 in month 3
• Sold at least 2 bridges in month 2
• Sold at least 4 bridges in month 3
• Bridge sales should be more than $90,000 in month 3

Hey, we don't make the rules; we just get them from the business owners, and confirm them very, very well.   

First step: Query to Meet All Sales Requirements 

I know we're looking for those guys who ALMOST qualify, but "almost" is harder than "does", so let's start working on "does qualify", and go from there. Now, all this data is coming from one table, but we're going to self-join that table to itself to get the different month's information, like so:

Tip: I don't actually advocate the use of SELECT *, but while we're developing - on our DEVELOPMENT box, not on our PRODUCTION box! - it's just shorthand. 

See what we did there? "month1", "month2", and "month3" are aliases for our joined tables; this lets us join a table to itself, and makes it comprehensible. Now we can ACTUALLY think of month1, month2, and month3 as different tables, because the join for each one returns a different set of data. Next up, let's turn our requirements into TSQL:

• Total sales of over $100,000 in month 1 => month1.totalSales > 100000
• Total sales of over $150,000 in month 2 => month2.totalSales > 150000
• Total sales of over $200,000 in month 3 => month3.totalSales > 200000
• Sold at least 2 bridges in month 2 => month2.BridgesSold >=2
• Sold at least 4 bridges in month 3 => month3.BridgesSold >=3
• Bridge sales should be more than $90,000 in month 3 => month3.bridgeSales > 90000

Next: Change to "Almost" Met Sales Requirements 

This query gets us the salespeople who DO qualify for the bonus. But what we need are the people who ALMOST qualify. Now, "almost" is going to be a business rule...do they want to see a report of people with enough total sales, but not enough bridge? People who qualify in month1 and 2, but not quite yet in 3? Find out what the business owners specifically mean by "almost", and then tailor your query. In our case, we've been asked for people who have month1 and 2 requirements, have 2 bridges sold in month 3, and are within 50% of their total and bridge sales in month 3. This changes the query thusly (ignoring the body of the query again, only WHERE clause changes):

Different "Almost"

If the business had decided another tack for "almost" - like, anyone who has met month 1 and month 2 requirements, and at least one month 3 requirement - we'd have a different WHERE:

No "Did Meet" Guys

You get the idea.  If we like, we can also eliminate those guys who DO meet all the criteria - after all, this is a report on potential bonus awardees:

That last AND NOT says, if a guy also meets all thre month3 criteria, I don't want to see him.

Make it Readable 

There's one more thing I'd like to do to this query, and that is to make it easily readable/usable. So let's change our SELECT statement (we'll ignore the FROM, JOIN, and WHERE clauses for now; they stay the same).  We'll use this latest set of requirements...that is, all month1 and month2 criteria are met. So let's show them WHICH month3 criteria are being met:

This will present the user with a lovely readout, something like this:

Beautiful. Happy days, all!

-Jen McCown

http://www.MidnightDBA.com

Here's the latest on the latest DBAs @ Midnight videos, "Stuff Auction" This time, WE HAVE A PLAN.

DBAs@Midnight: Stuff Auction Part 1:

• Recap of our week - MVP summit (Ozaaaaar!!) and Colorado skiing. 2 new blogcasts, Quest product placement, sort of.
• 3:00 Jen's new job
• 4:15 first topic - The Job Auction. What happens to your stuff when you leave a job...
• The Tom we mention is Tom Yager of InfoWorld.com
• 7:30 Jen admits to her dark urges.
• 9:00 The best ways to scope out the soon-to-be-available stuff.
• 10:55: "I take bribes, and suckups are welcome!"
• Sean punched Tim Ford's new ink.
• 13:30: There are some things that it's NEVER okay to do...

DBAs@Midnight: Stuff Auction Part 2:

• Jen's impression of Stanley from the Office. And then the end of topic salute, which turns out to be kinda stupid.
• Exam questions... "You're a SQL Server developer for XYZ corp..."
• 1:45 What are the things to focus on at a new job. Jen's answer...
• 4:30 Sean's answer...

• Continued, important first day questions.
• Brent Ozar's DBA checklists, Buck Woody's DBA checklist
• 2:30 Jen wanders briefly into kidland
• 3:00 Alerting and monitoring
• 5:00 Powershell solutions for info gathering and monitoring. sean's PS blog...
• 8:00 There's a DMV for that! Shirt ideas
• 9:00 Sean's MVP week talk with Brent Ozaaaaaaaar!!
• 12:30 More important first day tasks....business owners? Process? What's that?
• 13:20 Eddie Izzard, "Death death death death lunch, death death..."
• 14:00 Recap.
• 15:00 Clusters are like Hummvees - everyone wants one, but few know or need what they're actually for.
• 16:20 HA is often misunderstood... (You see how we start to wander after midnight?)
• 19:00 An NDA flashlight, and Jen announces how she's going to blog guides to these podcasts, because they wander around so much.
• 19:45 Sean actually <redacted> <redacted> Denali <redacted> Dan Jones.
• 21:26 We say goodnight.

-Jen McCown

http://www.midnightdba.com

“All things appear and disappear because of the concurrence of causes and conditions. Nothing ever exists entirely alone; everything is in relation to everything else.” -Hindu Prince Gautama Siddharta, the founder of Buddhism, 563-483 B.C.

Don't code lonely. Just don't do it...it's one of the major sins that will cause the gods of IT to unforgivingly smite you.  You don't want to be smitten smited smote smoten, do you?  Good then.

What do I mean by "code lonely"? I mean a lot of things, actually.  You code lonely when you code in a vacuum - without good interaction with the rest of your team. When we do this, we run a very high risk of missing an important element to the module, or slamming up against some other module in a way that breaks the application. (Go ahaed, ask me how I know...)  Talk to your team, attend meetings, send emails.  Don't code lonely.

I also mean coding maverick style: Sure, you may be one awesome Top Gun, but no one is immune from random mistakes and oversights. (Again, ask me how I know.)I'm remembering Michael Bolton in Office Space, "I probably put a decimal wrong or something.  S***, I'm always DOING that!"  Implement code reviews and stick with them.

If you're reading this blog, you likely read other blogs. I'd say you're probably on Twitter, maybe Facebook or LinkedIn...so I'm preaching to the choir on this point. But just in case the MidnightDBA Blog is your only link to the world of SQL Server professionals, understand my third meaning of "coding lonely": It is absolutely invaluable, imperative (and lots of other "i" words) that you CONNECT with your SQL community.  You have SO many options, and no excuses:

• Get on a social networking site and chat with data professionals, Microsoft MVPs, authors like Paul Randal and Buck Woody, and other bigwigs
• Read and comment on SQL blogs (more SQL blogs)
• Attend virtual user group meetings
• Attend physical user group meetings
• Attend webcast presentations
• Ask and answer questions on forums
• Read and contribute to articles on SQLServerPedia.com
• Volunteer with PASS or Women in Technology
• Attend and/or volunteer with code camps and SQL Saturdays
• Attend conferences like the PASS Summit, SQL Connections, or Microsoft TechEd

"We must all hang together, or most assuredly, we will all hang seperately." Ben Franklin had it right.

Happy days,

Jen McCown

http://www.midnightdba.com/

Ok, we had the drawing for the SQL Server 2008 Internals ebook.

Come watch the vid to see if you won.

So thanks for playing guys and we'll see you next time.

Sean and Jen.

This week in honor of Valentine's Day and TSQL Tuesday, Relationships Edition, we're talking relationships.  First off, let's start with comic from The Oatmeal, "The Three Phases of Owning a Computer". The three phases are: The Honeymoon, The comfortable phase, and Behold, the dinosaur.  I love this comic because it's a beautiful illustration that relationships with many things - computers, cars, people, and in the case of this blog post, jobs - all follow similar patterns.  "How," you say?  Well, let's walk through one of your past relationships.

They Meet

First, of course, you meet. You're instantly attracted - maybe this gig has one SEXY bonus structure, or a really firm project plan.  You make inquiries, maybe talk a little, and wow...you two even like the same things!  You get to know each other, you're hired...boom, you're in a committed relationship!

The early days of a job are wonderful. You go to new places, meet new people, get to know the rhythm of things. You get presents...a new computer! A backpack! A desk! A Blackberry!! Wow, you're the best, baby!  It seems like those around you are friendly and intelligent, and anything is possible. Together you'll move mountains!

Getting to Know You 

Slowly, as you tell each other your stories and spend time together, oh so slowly, you begin to see each other's little faults.  That's really endearing at first. "Oh, sweetie, your dev environment is weak and slow? That's okay, we'll make it work."  Over time, little things become irritating, but that's just part of a normal relationship. "What do you mean you don't do code reviews?  And you let the .NET guys architect the database? That might be a problem, but let's not fight...I love you." 

If you're not meant to be together, things can start to get ugly.  One of you starts trying to change the other. "I noticed you were looking a little bit bored lately with these same admin tasks, and I thought it might help us if we watch some training videos together..."  Or maybe, "Look, I know you've always used SA/password for everything, but you CAN'T go on living like that.  It's unhealthy!"  Fights begin.

You've both put a lot into this relationship, and you can't believe it's really that bad.  Maybe a little time apart would help, a little vacation.  Maybe you need to spend MORE time together and try get back in sync.  This is true love, after all.

Leaving Town

If nothing works, you grow farther apart, and one day you realize that nearly everything about this place bothers you.  That godawful way they say "synergize your thinking out of the box", the endless prattle about restructuring, the procrastination...you just can't take it any more!

Finally, the realization comes: It's over.  You prepare yourself emotionally (and if you're smart, physically, by moving your things out of harm's way, saving off your personal code vault, and taking your stuffed Yoda home).  So you set a time and place to inform the other party. You get nervous. You think of JUST the right wording, what you want to say is the reason. Should you go with "it's not you, it's me"? Or "let's just be friends"?  What if you're leaving because you found something better?  For god's sake, don't compare...no one wants to hear "Oh man, you should SEE their boomin' data center!!"

And they may well react like a jilted lover. There's anger: "How could you leave us so close to our deadline??" Bartering: "We'll do better, we'll put those new processes in place next month, and let me see if I can get you a raise."  And the rare but simple acceptance: "We're sorry to see you go, good luck."

Of course, this is assuming you're the one breaking up.  It's a little different when your love leaves you, especially if you thought you were getting along so well. And like you, your company may have any one of a myriad of reasons for breaking your heart. There's logistics: "We can't afford to move you/pay you in the next quarter, it's just not meant to be." There's the growing apart: "It was so good back in the early days, but I've changed, you've changed, and it's just not working any more." And there's jealousy: "We saw your post on Monster.com, and I can't believe you're out trolling for other gigs. Get out, you hussy! And take that stupid bobble head with you!"

Recovery 

How do you mend a broken heart? How can you stop the rain from falling down?  Get back up on that horse!  If you lose your love, of course there will be a time for grieving. But if you wallow, there's no way any new company will find you attractive. So after a short respite, stand up, dust yourself off, look in the mirror and say, "I'm good enough, I'm smart enough, and doggone it, companies like me!"  Trust me, Mr or Mrs Right Job is out there, and waiting for their DBA in shining armor.

For more on letting your ex-job down gently (or not), see our DBAs@Midnight videos "Breaking up with your Boss".

-Jen "Lonely Heaps" McCown

http://www.MidnightDBA.com