|
|
|
|
SSIS and ETL
Thoughts about Database and Software Development, and the tools of the trade.
-
Introduction
In SSIS 2005, the Lookup Transformation will fail if it does not find a matching record in the lookup table if configured with the default settings.
Build the Data Flow
Create a Data Flow Task and add an OLEDB Source. In the OLEDB Source Adapter, connect to AdventureWorks and use the following T-SQL statement to extract data from the AdventureWorks.Person.Contact:
Select FirstName, MiddleName, LastName
From Person.Contact
Configuring the Lookup
Drag a Lookup onto the Data Flow canvas and connect the output of the OLEDB Source Adapter to it. Open the editor and connect to a destination - any destination. For me, I used AndyWorks because I'm so vain.
I also clicked the New button beside the "Use a table or a view" dropdown and created a table in AndyWorks from inside SSIS (love that feature!).
Next I clicked the columns tab and the transformation auto-mapped the available Input Columns to the Available Lookup Columns. I checked all the columns in the Available Lookup Columns, then prefaced each Output Alias with "Dest_":
Designed to Fail
If I execute this task right now, it will fail:
The error is: [Correlate [xx]] Error: Row yielded no match during lookup. The name of the Lookup transformation is "Correlate".
The reason? The new table is empty, so there are no records that match the rows in the pipeline (from the OLEDB Source Adapter, which is reading the AdventureWorks.Person.Contact table). So how do we keep it from failing?
How to Keep the Lookup From Failing
Click the Configure Error Output button:
When the Configure Error Output window displays, change the Error response to the Lookup Output from Fail Component to Ignore Failure:
Now when you execute the Data Flow Task, it will succeed:
There are still no records in the destination table. The difference is how the Lookup Transformation responds to not finding a match in the destination for rows flowing from the OLEDB Source Adapter.
:{> Andy
|
-
Introduction
This post is the ninth part of a ramble-rant about the software business. The current posts in this series are:
This post is an introduction to metaproblems and discusses a common metaproblem: drama.
Problems
I define a problem as an unsolved issue. It could be minor. Or it could threaten your project, llivelihood, or even your life. Problems share some characteristics:
- Problems are not symptoms.
- Problems are not effects.
- Problems rarely scale.
The symptoms of a problem are related to the problem. We usually think of symptoms medically. If you have a common cold you exhibit symptoms. The symptoms indicate you have a cold, but they are not the root cause of the cold. The root cause is something else - some virus or other. As I type, Emma Grace is sneezing. Sneezing is a symptom, she's either coming down with a cold or reacting to an allergy. It's also snowing, so the weather is a problem.
We can treat the symptoms. In fact, Christy just gave Emma an antihistamine to alleviate her sneezing. Treating the symptoms is not without merit - sometimes it's the best you can do.
As a result of Emma's cold, she cannot go play in the snow that is falling as I type. The snow also caused the postponment of SQL Saturday #30 in Richmond. Both are examples of effects of a problem.
Emma's cold is running its course. The snow will continue falling. The actual problems are: the cold and the weather. Emma could catch another cold - that would be a different problem. The symptoms could grow worse; that would fall under more symptoms. Emma's cold remains the problem. The snow is forecast to fall into the evening. Other activities are cancelled or postponed in our area this weekend as a result. These are more effects. The problem is still the weather. The problems don't scale, though the symptoms and effects can and often do.
Metaproblems
The diagram above is my attempt at visualizing a metaproblem (yes, I made up another word. I can do that. I'm an author.). A metaproblem is a problem with a problem.
An example of a metaproblem is: Emma is upset that she can't play in the snow with the boys. Another example: I'm bummed about postponing SQL Saturday #30 because some speakers and attendees won't be able to make the new date.
Metaproblems are manufactured by people. In business, the most prevalent category of metaproblems is drama.
A server crashes due to a hard drive failure. Your boss calls you screaming that it's your job to anticipate hardware failures and replace hard drives the week before they fail. The failed hard drive is the Problem. Your boss's illogical emotional rant is drama.
Drama is More Work
For everyone involved in the actual solution, drama is just more work. The time spent responding to the overreactions of others is really time that could be spent solving the Problem.
Some Irony
When the Problem is solved, the people manufacturing the drama will secretly congratulate themselves for their "contribution" - believing the additional workload and stress they added to the hearts and minds of those actually solving the Problem (punching them in the brain) helped in some way.
Nothing could be farther from the truth.
If you don't have your hands on or in the solution, you can do one of three things to help:
-
Get your hands on or in the solution.
-
Stay out of the way of those with their hands on or in the solution.
-
* (Not yet... I'm saving this for a follow-up post in this series)
Overcoming Drama
How do we deal with drama when faced with it? That very question is flawed. You cannot deal with drama when faced with it: It's not within your realm of influence, it's nothing you can change. The root of drama is in someone else's mind and you cannot affect that unless you're Matt Parkman.
Drama, when it is occurring, is best identified as such and then ignored. In the example above, explaining the hard drive failure is the Problem and the steps you're taking to replace and rebuild it should suffice. If it doesn't, you could be the victim of a Crappy Job. Personally, I don't even acknowledge the drama that attaches itself to Problems.
Serious efforts at curbing drama happen before and after drama strikes.
Before it happens, recognize and communicate the potential impedance drama adds to any real Problem. After the fact, point out the Problem and the metaproblems, starting with the drama. Be specific about the amount of time it took to solve the Problem and the additional time wasted mitigating the drama.
Conclusion
I view Problems as challenges. When I'm feeling clever, I refer to obstacles as "something to overcome." They represent an opportunity for me to learn something and demonstrate that knowledge on the quest.
* I'll dive into a better response to Problems in an upcoming post in this series.
:{> Andy
|
-
Introduction
Andy Warren (Blog - @sqlAndy) is a DBA's DBA. He is a friend and mentor. He calls 'em like he sees 'em, and I haven't seen him pull a punch yet.
I requested an interview with Andy before I learned of the transfer of SQL Saturday to PASS. Sometimes life works out that way...
The Interview
How did you, Brian, and Steve come up with the SQL Saturday idea? What inspired you? What need were you trying to meet in the community?
Brian and I had both been to a few Code Camps, and as you know they are interesting because of the diversity, and the price! We were doing SQL presentations there, but most of the attendees were developers, very few DBA’s. So it wasn’t a stretch to think about doing a SQL only event, but we had no idea if it would work. The one thing we saw early was that with the Code Camps there was no main site, no shared knowledge, and very much an anti-money attitude. For developers it makes sense that they all want to build their own site with the latest and greatest technology, but they spent a lot of time on something that didn’t really change the event. Also, most of the time the web site was what you saw – no admin tools. Back in 2007 most events had speakers submit abstracts via Word docs. Functional, but time consuming. So the focus of the early vision was thinking “can we build a SQL only event?” and if we can, “can we fix all the challenges we see in the Code Camp model?”. I’d say at the time we were focused on attendees and event management, we had not yet realized the growth that would happen when we provided an outlet for SQL speakers. At the time it seemed awfully ambitious to think about building a national franchise. I think in hindsight the thing we got right was that within the SQL community the web site is just an enabler, and that offering coaching based on our experience convinced people to try events that would not have otherwise.
As a SQL Community Enabler (love that description!), what's been your biggest challenge(s)? Have you faced competition? How did you overcome the challenge(s)?
I think the biggest challenge is figuring out the minimum set of rules that would work. Too many rules and it would just cause event leads to go do their own thing, even if it meant losing out on some advantages the SQLSaturday platform offers. For example, one rule is that you can’t charge for the event, but it’s ok to charge for lunch as long as you allow them to bring their own lunch. We came up with this because not every event leader will be a great fund raiser, and sponsors are less likely to spend as much at small venues (and we want it to work in small cities!). There has really been no competition, we work closely with the Code Camps here in Florida and share lessons back and forth, but really no completion in the SQL Server space. I’d say the second biggest challenge was the web site – how much of the process can we bake in and steer event owners down a given path. It’s the same tradeoff; good tools save time, but if it forces you to work in a way you don’t like, the tools don’t matter. I think we’ve done ok on that so far. Always more that could be done, but we do enough of the critical stuff that it works.
You write about balancing between too many and too few rules, and also refer to SQL Saturday as a franchise - that's quite a balancing act. Has the number of rules increased over time? Have they morphed?
We still don’t have many rules. I do a lot of “recommending”, but the main rules are that the event has to be free and that we should show preference to local speakers. Maybe we could use a few more, but we’ve done amazingly well by giving the event leaders a lot of room to decide what works best for them and their attendees. I think franchise is the perfect word for what we’ve built. We provide a framework and coaching, lots of behind the scenes support, but just like real franchises it’s ultimately up to that local owner. Some are great at finding speakers, some are good fund raisers, some are all done by one person and some are done by committee. It definitely has an entrepreneurial feel to it at the event level.
As an event organizer, I think the SQL Saturday website is awesome! Brag some about SQLSaturday.com!
There are two parts to it, the public site and the admin site. On the public side of things we tried to make it very easy to use, from registration to submitting a session to signing up as a sponsor. We show the list of submitted sessions plus any suggested sessions from registrants. This let’s registrants see the event build, and it helps the speakers find a niche on the schedule that hasn’t been filled yet. Sponsors sign up online and select one of the configured sponsorship rates, and then we send them an invoice and a PayPal link. When they pay the invoice we automatically show them on the sponsor page. Just a handful of aspx pages on top of a SQL 200 database, it’s simple and effective. Last year we finally paid a designer to do the look and feel that you see today, much better than the very plain look I did the first time around!
The admin tools are really the powerful part. New events submit a request online, plugging in a few required data points. We take a look at that and either just approve it or schedule a call, but once it’s approved we email them a login to the admin site. From there they can change a lot. Not everything, but a lot. The core pages are the same across events, but they can change the number of tracks, the sponsor levels, add notes to the front page, change the event date, and more. We have a bunch of reports (running on Report Server) that lets them see and export the data in a few different ways, from a basic attendee list to personalized raffle tickets to schedules to post on the door of each room (track). There’s a task list that we set up for each event to remind them of milestones, we load a set of well-known sponsors and their contact information, and we’ve been testing out something we call auto-messaging, a set of about 20 messages that are set to go out at EventDay – x, a solution we put in place for event leaders that struggle with messaging. My favorite part is the messaging UI which lets them pick from a number of predefined mailing lists (speakers, attendees, sponsors, more), insert custom links as well as tokens, preview it, and then schedule it to be sent. Nothing fancy, just think of it as a very vertical application that lets an event leader do the things they need to do without writing update queries.
I understand you initiated the conversation(s) to transition SQL Saturday to PASS - why? Why not just keep SQL Saturday independent of the global PASS organization? In your opinion, how does the change-of-ownership impact SQL Saturday, PASS, and the average Database Professional?
From the beginning it felt like these events should be something that PASS should be doing, because they are grassroots and normally tightly coupled to a local chapter. For a chapter, an all-day event serves as both a membership drive (that benefits PASS) and as a fund raiser that potentially allows the chapter to bring in some out of town speakers to their monthly meetings. It was also a decision about scale – as we grow more events so does the time required for coaching and while I love doing it, it’s not always the best use of my time from a business perspective. As far as the impact of the change, I’m really hoping for zero negative impact, and over the next year even some positive impact. There will be a busy couple months doing the transition, most of which will be knowledge transfer and really getting PASS HQ to internalize the dynamics of locally driven events, and then I think things will be normal or better.
I’ve heard a lot of nervousness about the move, and to be candid, it’s all about whether PASS will maintain the momentum. As I mentioned in a comment on my blog, I think 2 years ago it wouldn’t have worked; today, I think PASS HQ is ready to tackle it. I think we’ve all said that PASS has to be more than the Summit, I think this is the right vehicle for moving in that direction. Instead of two annual events, now we have 20+ annual events and a basis for growing even more. We’ve just got to make sure it gets the attention it needs and I’ll be watching that closely, and I know many in the community will be as well.
But to answer more directly, if all goes well I think it’s a positive change for SQLSaturday because we’ll have more staff behind it and the ability to scale to even more events, PASS gets a lot more grass roots community involvement, and as we grow events we should see SQLSaturday coming to a lot more cities. I expect that to be US focused initially, but certainly there is no reason it can’t spread to other regions.
Last question. You're on the PASS Board, participate in the leadership of Orlando SQL Server User Group, partner with Brian Knight and Steve Jones in a few business ventures; What's next for Andy Warren?
That’s a hard question. As you know I make my living as a SQL trainer and I’ve enjoyed the work, but over the past few months I’ve started to miss the challenges of working with a team on a project. So while I haven’t decided yet, I’m definitely considering moving more towards consulting or even a role back in corporate life, or perhaps working with a vendor in the SQL Server tool space. I’m having a lot of fun working on SQLShare.com and that is really about training too, what I consider ‘pure’ professional development for SQL Server users. I’ll continue that regardless of other career moves I may make. Working on the PASS Board has been a good experience. I’m really torn about running for re-election, mainly due to the time it demands – no decision yet! I’ve got a few other ideas that involve the SQL community around career and professional development that I’d like to put more time into this year, so I’m also trying to free up time for that. It’s fun and challenging and frustrating to be at the point of re-invention, seeing a lot of opportunities and deciding which to choose. I wrote something earlier this year that captures it well – I’m looking for an industrial strength challenge. It’ll be interesting to see what develops.
Conclusion
Thanks for taking time out of your busy schedule to answer these questions Andy!
:{> Andy
|
-
Introduction
I maintain the best way to start a blog post or article is with an image that grabs the reader's attention. So I asked my good friend Frank La Vigne (Blog - @Tableteer) to help me out some with his mad Photoshop skillz.
TBDDEOTP
While describing G. Andrew Duthie (Blog - @DevHammer) in a Richmond Code Camp keynote, I coined the acronym TBDDEOTP (The Best Damn Developer Evangelist On The Planet). Andrew is awesome and we love him in Richmond and southern Virginia - and geeks all around the Mid-Atlantic love him as well.
One of the reasons we love him is he engages and participates with us right where we live. He blogs. He's on Twitter and LinkedIn. He attends meetings and sometimes presents - like tonight at Richmond.Net! When Andrew sees an opportunity to get personally involved, he does. Which brings me to...
Southern Maryland GiveCamp
Jim Pendarvis (Blog - @JRPendarvis) is doing a fantastic job organizing the first Mid-Atlantic region GiveCamp - the Southern Maryland GiveCamp.
GiveCamps are a neat idea. Developers donate their time for a weekend development project that benefits a charity or non-profit. At the end of the weekend, the charity or non-profit has an application or website developed at no cost. There's more to it than that (obviously), so check out the Southern Maryland GiveCamp website for more details.
"So Why the Photochop of Duthie Sporting a Mohawk, Andy?"
I'm glad you asked!
G. Andrew Duthie has pledged to bring clippers the Southern Maryland GiveCamp and cut his hair in Mohawk style if 100 developers sign up and show up for the event! Thanks to Frank's photoshop skillz, you have a preview of what this might look like (thanks Frank!).
:{> Andy
|
-
Introduction
I got a cool email from Chris Shaw (Web - Blog - @SQLShaw) at the end of January. It began:
There are few DBA’s here in Colorado Springs that thought it would be fun to go through the book chapter by chapter and talk about what we got out of the chapter that week. Each week 3 of us are going to be posting a lessons learned sort of deal.
How Cool!
The SQL Server community keeps finding new ways to engage with and around SQL Server MVP Deep Dives! This is by far the coolest book project in which I've had the honor of participating.
I look forward to learning more from Richard Rodriguez, Jeremy Lowell, and Chris on their site: SqlPerspectives.
:{> Andy
|
-
Introduction
A while back I wrote about developer communities. The series consists of these posts:
This post covers feedback to developer communities from the business community.
The Lifecycle
I see the interaction between developer communities and the business community as a lifecycle. The developer community participates in the lifecycle by adding business value, in the form of education and skills, to the community members. The business community participates in the lifecycle by sponsoring the developer community.
The business community can measure the impact of its sponsorship dollars pretty easily: How many people are "touched" by the presentation? Sponsorship partners in the Richmond VA Developer Community tell me the ROI is real and beneficial for them: the recruiting firms tell me they can earn the cost of a Platinum Sponsorship from placing a single developer in a contract lasting from a few weeks to a few months, depending on the nature of the gig. The rest of the money earned from placing that developer - and all the other developers "touched" by the recruiting firm's participation in the developer community - is profit.
Feedback?
So how does the developer community get feedback? I ask for it. (filed under: Duh!) I find surveys impersonal and somewhat cardboard. So I send individual emails. Yes, I copy and paste the content to make sure the responses are to the same questions, but I send individual and personalized emails. You can do this with a dozen or so sponsors. It's not hard. Trust me.
Questions
I ask:
- Which Richmond Developer Community meeting / event was your favorite of all time? Of last year?
- What can we do to make sure the right people - the people who need us most - are hearing about our meetings / events?
- What can I (Andy) do better? What should I never do again?
- Do you have any suggestions about how we can improve our value to members? To you?
Conclusion
To remain effective - to sustain your developer community - you need to constantly improve. That may mean more meetings, it may mean more structure to your meeting times and locations. Your business partners / sponsors know a thing or two about providing value to your community. Why not ask them what they think?
You don't have to do everything they suggest, but I guarantee you will learn something you didn't know if you email them and ask those questions. Plus, you'll demonstrate your commitment to participating in the lifecycle with them. Try it!
:{> Andy
|
-
Introduction
This post is the eighth part of a ramble-rant about the software business. The current posts in this series are:
I'm a big fan of 15-minute meetings. It's an engineering thing. It's all about...
Multitasking
I have discovered something about myself: I suck at multi-tasking.
It's true I do a lot of things, but the way they get done is not pretty. Note: This is not a complaint, it is part confession and part recognition-of-reality. The recognition of reality is I have two hands and one mind. I can only dedicate them to a single task at a time. The confession is: I like it this way.
I'm a notorious monotasker. It's genetic (or, at least, epigenetic). I remember when I discovered this in third grade. We were given a page of arithmetic in math class. I started solving the problems and everything else "went away." Have you seen the movie For the Love of the Game? Costner's character focuses while on the pitcher's mound, saying "Clear the mechanism" and the crowd noise fades to nothing. That happened to me at age 8 in that classroom in Burkeville VA.
It's happened since when I'm coding or doing engineering work. I remember designing electrical control systems in 1990's when I ran a small industrial automation shop. I'd get to the office around 5:00 AM, make a pot of coffee and start working. In an hour or so, I'd get hungry and eat something. Then I'd make another pot of coffee and work for another hour. And then I'd look up and it would be dark outside. I would think "But I've only bee at work a couple hours!" In fact, I'd put in 12 - 14 hours.
Time-Slicing
Since I can only do one thing at a time (and since I really enjoy doing only one thing at a time), I need a solution to get more than one thing done in a given time period. My solution? Time-slicing. Computers do this.
Back when we used to carve our own ICs out of wood, computers had but one CPU. Can you believe that? A single CPU. It's true kids, I'm telling you - look it up on the interweb if you don't believe me. Back then, computers would do one thing for a while, and then go do something else for a while.
Humans who are bad at multitasking can mimic this behavior, which brings me to...
The Beauty of the 15-Minute Meeting
If we have only 15-minutes to talk about something, we're not going to waste a lot of time. The very length of the meeting creates a sense of urgency.
Plus - and I love this - 15-minute meetings break my day into 40 intervals (for a 10-hour day). If I go with 1-hour meetings, I only have 10 intervals. I can work on 4 times as much stuff if I slice my day into 15-minute intervals.
I find 1-hour meetings have 5 times as many people invited to them than 15-minute meetings. That's one of the reasons the meeting is an hour long - to give everyone a chance to talk. And here's the interesting part: most of any meeting consists of two people communicating while the others listen. For those of us who practice "math" that means a lot more people are listening, zoning out, or ignoring the meeting and doing meaningful, productive work instead in a 1-hour meeting.
15-minute meetings should never have more than ten people. And really, three or four is optimal. Identify the people who can best make the decision, get them together in a 15-minute meeting, and make the call.
"What About the Other People Who Need to Know About the Decision?"
Send them an email.
Conclusion
Want to increase the signal-to-noise ratio in your day? 15-minute meetings are a more effective use of everyone's time.
:{> Andy
|
-
We're postponing SQL Saturday #30 until 10 April 2010 due to the weather forecast for Friday and Saturday in Richmond VA.
:{< Andy
|
-
Introduction
Back in the day (when years began with "1"), I was an electronics instructor at ECPI for a while. I absolutely loved this job! You can learn a lot of logic when you study electronics. And one of the fascinating facts about logic is: There are four states to two-state logic.
"What?"
I had the same response. So let's back up a minute and think about it.
What is Two-State Logic?
Two-state - or binary, or Boolean - logic is the stuff of 1's and 0's. Hence the name "two-state." Depending on how you wish to express them, the two states are:
-
1, On, High, Hi, H
-
0, Off, Low, Lo, L
"Yeah Yeah, We Get It. The Other Two States?"
The other two states are Don't Know and Don't Care. Don't Know is usually represented with a question mark: "?"; Don't Care, with an "X". Where would you use these?
Don't Care
Don't Care is the easiest to explain so let's start there.
Binary logic can be used to represent higher base-number systems such as hexadecimal (base-16) and decimal (base-10). BCD (Binary-Coded Decimal) represents base-10 numbers using binary (base-2) logic. How does BCD work?
BCD
(Base-10) |
Binary
(Base-2) |
| 0 |
0000 |
| 1 |
0001 |
| 2 |
0010 |
| 3 |
0011 |
| 4 |
0100 |
| 5 |
0101 |
| 6 |
0110 |
| 7 |
0111 |
| 8 |
1000 |
| 9 |
1001 |
With these 10 representations, we've covered the numerals in base-10. What about the remaining combinations of Binary numbers? What about 1010, 1011, 1100, 1101, 1110, and 1111? We Don't Care.
One way to represent this in a diagram is:
BCD
(Base-10) |
Binary
(Base-2) |
| 0 |
0000 |
| 1 |
0001 |
| 2 |
0010 |
| 3 |
0011 |
| 4 |
0100 |
| 5 |
0101 |
| 6 |
0110 |
| 7 |
0111 |
| 8 |
1000 |
| 9 |
1001 |
| X |
1010 |
| X |
1011 |
| X |
1100 |
| X |
1101 |
| X |
1110 |
| X |
1111 |
When designing logic, X's (Don't Care's) can be treated as either 1's or 0's. This is convenient for simplifying logic expressions through Boolean algebra, Karnaugh Maps, or even manually.
Don't Know
Don't Know is tricksy. Sometimes, Don't Know is an indication that you haven't finished the logical design; your current I/O doesn't allow enough states. Sometimes, Don't Know can be akin to NULL in a database. Unlike Don't Care, Don't Know's cannot simply be toggled at will to simplify the expression - they must either be solved (defined) or worked around.
If I find a Don't Know completely surrounded by one value or another, that's a clue. The Don't Know is probably that value.
Conclusion
There really are four states to two-state logic (I can't make this stuff up!).
:{> Andy
|
-
Introduction
This post is the seventh part of a ramble-rant about the software business. The current posts in this series are:
A Workplace Hierarchy
I borrow heavily from a Maslow-vian (is this a word?) approach. Maslow's Hierarchy of Human Needs has been applied (and mis-applied) before. Someone has probably already made this connection for teams in the workplace. If so, cool! I haven't seen it - this my pass at applying it to teams.
The way the hierarchy works is: The lower stuff are basic necessities. In the Human Needs version, this tier is reserved for Physiological needs. The second tier of the Human Needs version is Safety. Each tier is dependent on the tier beneath it. In 1943, Maslow proposed that a human being is motivated by these needs in this order. If your physiological needs are unmet, you will instinctively concentrate on this and ignore all else. If all physiological needs are met and you are unsafe (or feel unsafe), you will concentrate on becoming safe. And so it goes, up the Human Needs pyramid from Physiological, through Safety, Love / Belonging, Esteem, and Sefl-actualization.
I correlate the five tiers of Maslow's Hierarchy of Human Needs to five tiers of the workplace for a team:
- Physiological --> Compensation
- Safety --> Job Security
- Love / Belonging --> Esprit de Corps
- Esteem --> Organizational Respect
- Self-Actualization --> A Kick-Butt Team
Let's drill into these a little deeper...
Compensation
At the bottom of the employee pyramid is compensation. When I’m talking to people above the Director level, I throw in “This means money. In their paycheck. Regularly.” Some incentive plans can backfire with people who use exotic math (and by exotic, I mean long division): “I get paid $42.50/hour for each hour in a 40-hour week. I do 100 hours above that, and I got $2.50 for each of those 100 hours.” Mind you, it’s something – and that beats nothing, especially when there’s no 401k matching or raises.
Some people will argue compensation is not all it's cracked up to be. They're right, to a point. If you have a Crappy Job, no amount (well, no reasonable amount) of money is really worth it. But money is like other things - oxygen, for example: It's not really a problem until you're not getting enough. Be wary of applying business school logic to geeks (more on this later).
Job Security
Over money there’s job security. This is more than "Can the company survive without me?" If you're relying on that kind of job security, I have some bad news: The company can survive without you. It may cost them money and time, and the company may even rue the day they let you walk out the door, but they will survive. Other stuff plays into this: “Does what I do matter?” Does your work count? More than that; is your manager letting you know how your work matters?
Esprit de Corps
Next up is cohesion within the team. Do we share a sense of mission? Is there a vision? Goal? End date? “Are we all rowing together?” to take an example from the article: The No-Cost Way to Motivate by Patrick Lencioni. This is where esprit de corps starts. We all hang together, or we hang separately – that sort of thing.
Organizational Respect
On that, there’s the respect of other teams. Do they know what we’re doing and why? They know we’re holding them up or badgering them for answers, do they understand why? Are we being professional as a team in our interactions with other teams? Are we communicating as a unit? A lot of this derives from (and to) J. Ello’s article: (warning: ComputerWorld link. Check your popup blocker before proceeding...) The Unspoken Truth About Managing Geeks. If Job Security - and by implication, Compensation - are satisfied then monetary bonus incentives work here.
A Kick-Butt Team
Take care of all that and nature will take its course. You’re stuck with a self-actualized team that you can throw at just about any problem and watch them solve it. And they grew organically. They’re in “bring it” mode. They crave challenges and hold friendly competitions to innovate the best solutions. They laugh a lot. They’re “characters.” If we’re lucky, we have an island of Alphas (borrowing from Orwell now… I’m ripping off everyone today) that actually works.
Conclusion
There are several implications to managing in this way. One is: If team members do not perceive they're receiving adequate compensation, their priority will be to satisfy this need. Perception is reality - especially in this context. And it's the perception of the team member; not the manager.
It's easy for a traditional manager to confuse the motives of a geek based on behavior. This is a serious issue for IT managers with business school educations (MBAs). J. Ello's article is a masterpiece. It's worth battling the advernoise (I made up that word) popups at ComputerWorld.com. It describes precisely how geeks behave and why (based on my observations and experiences... but I've only been coding 35 years...). Based on those same observations and experiences, no one is teaching this in business school. And that's a shame.
Treat your team well, then watch them grow!
:{> Andy
|
-
-
Introduction
Jack Corbett (Blog - @unclebiguns) tweeted recently about recording the start time of a parent package from the child package it called. I responded and ended up writing a small demo project in SSIS 2005 that you can download here. I thought I'd share it.
Build a Project with a Couple Packages
I created a new SSIS project and renamed the default package Child.dtsx. I added a new SSIS package and named it Parent.dtsx:
I know. Creative.
Parent.dtsx
I need to demonstrate a difference in the start time of the parent and child packages. So I added a Connection Manager aimed at (local).master and then an Execute SQL Task with the following T-SQL statement:
waitfor delay '00:00:10'
Next, I added an Execute Package Task and aimed it at Child.dtsx. When I finished, Parent.dtsx looked like this:
So this package, when executed, will pause for 10 seconds and then execute the Child.dtsx package.
Child.dtsx
In Child.dtsx, I created a DateTime data type variable named ParentStartTime. I right-clicked the Control Flow and clicked Package Configurations to open the Package Configurations Organizer. I selected a Parent Package Variable Configuration Type and entered StartTime for Parent Variable Name:
On the Select Target Property window, I selected the Value property of the ParentStartTime variable (\Package.Variables[ParentStartTime].Properties[Value]):
I clicked next and named the package configuration, then closed the Package Configuration Organizer.
By Value of By Reference?
This package configuration will read the value of the StartTime variable in the Parent.dtsx package and pass the value into the value of the ParentStartTime variable in Child.dtsx. This is important: When variable values are passed like this - in any software language or platform - this is called By Value (or ByVal). It means the value from the source variable is read into the value of the destination variable. So if you change the value of the Destination variable the Source variable value is unaffected.
The other way to pass variable values is called By Reference (or ByRef). It means a pointer to the Source variable value is passed into the Destination variable. So if you change the value of the Destination variable, you're actually changing the value of the Source variable - because of the pointer.
You can pass variables between Parent and Child packages in SSIS ByVal and ByRef using the Parent-Child design pattern. I covered both in my PASS Summit 2009 presentation Applied SSIS Design Patterns.
Back to Child.dtsx...
Finally, I added a Script Task to the Child package Control Flow. I named it Display Parent and Child StartTimes; set the ReadOnlyVariables property to ParentStartTime,StartTime; and added the following code to the Script Editor:
Conclusion
Executing the Parent.dtsx package yeilds the following message box:
The parent package StartTime variable is passed into the Child package's ParentStartTime variable. I display both the start time of Parent.dtsx and Child.dtsx to demonstrate they are, in fact, different - thanks to the 10-second delay contained in the Parent package's Execute SQL Task.
:{> Andy
|
-
Introduction
After Paul Randal (Blog – @PaulRandal) tagged him in a post about the three events that brought him here, Brent Ozar (Blog - @BrentO) tagged me in his cleverly titled You may ask yourself, How did I get here?
So. How did I get here?
1. Christy
I recently read an article about how some relationships help the people in them realize their potential. There is support for each other's goals and dreams, encouragement and freedom to pursue them. There is evidence that this support enables partners in such a relationship to achieve more than they would have without the relationship. (If someone can find this, please comment!)
When I read that I tweeted "This happened to me!" Christy supports me like that. Christy rescued me. She has faithfully supported and encouraged me, and I'm so in love with her I can't breathe without her. She's my other self.
Christy is my best friend. If I have a question about a thought or plan, I can (and do) talk to her about and get sound advice. She's a fantastic wife, mother, cook, blogger, and everything else.
2. My friend John.
When I was 10, my folks bought 3 acres of land between Blackstone and Amelia Virginia on which they placed a three-bedroom mobile home. Our neighbors were aging and one of their sons, John, retired from the US Air Force and moved back home to take care of his parents.
John was an electronics technician in the Air Force. When he came home, John bought and built a Southwest Technical Products M6800 computer kit. Although I cannot find an image of it, John first built a Motorola 6800-based trainer. For those unfamiliar with the term, a trainer is a microprocessor with bare-bones I/O. In this case, toggle switches for input and LEDs for output.
John saw I had an interest in what he was doing. He was a natural mentor and asked my parents if he could teach me about computers. They agreed and in May 1975 I began learning Motorola machine code. That Fall I learned BASIC.
John changed my life.
3. Brian Knight (Blog - @BrianKnight)
Shortly before Christy and I were married, I moved to Jacksonville Florida. After we married she joined me and we lived there for three and a half years. Stevie Ray and Emma Grace were born in Jax, and we still have good friends in the area.
While in Jacksonville I held three positions. The last was DBA manager at Allstate, where I worked for Brian Knight. I met Brian via email when I signed up for the Jacksonville SQL Server Users Group. Brian advertised a job opening at Allstate through his mailing list and I applied. I did not get the job but I did a decent interview, and Brian hired me when another position opened a month later.
I read somewhere most authors receive 70 rejections before their first acceptance. When Brian was working on the Professional SQL Server 2005 Integration Services book, he needed more authors and asked me to contribute. I was honored! Participating in that book project was a lot of work, but it changed my career.
Conclusion
I'd say those are the three most influential reasons that brought me to this place in my life. And Brent, my military experience would be fourth on this list.
I tag Joe Webb, Jessica Moss, and Jorge Segarra.
:{>
|
-
Introduction
Buck Woody (Blog - @BuckWoody) recently blogged about his Database Design Process and I see Grant Fritchey has a (Blog - @GFritchey) post on the same topic. I figured I'd throw my two cents into the mix.
ADD
I often joke that I practice ADD (Andy-Driven Design... what'd you think I meant?). I'm expecting a wikipedia article on this methodology any day now... First, you need someone named Andy on your team. Next, you get Andy to drive the design...
But seriously... I like Buck's and Grant's methodologies and follow something similar when handed requirements.
I'm handed requirements about half the time these days.
That's Not A Bad Thing
"What?! How can that not be a bad thing Andy?" I use the Scrum methodology every chance I get these days. I find that Scrum works for database design too, provided you design database build scripts that are completely re-executable. Will your scripts build the database from scratch? Will the same scripts only apply changes to bring the database up to the latest version? If not, your scripting technique may not support agile development.
I discuss using SqlCmd to write re-executable T-SQL scripts that provide deployment artifacts in An Example of Test-Driven Development, Part 4 and in a presentation I've been delivering entitled "Database Design for Developers".
Scrum - Not Rugby
Scrum isn't a silver bullet. And it makes for some "interesting" database development.
I encourage database professionals (database developers and DBAs) to join the application and web developer teams early in the development process. Why early? That's when we can make a difference. It will also (brace yourself) give the database professional a glimpse into the topsy-turvy world of web and application development.
I hear you thinking "I used to be a developer Andy."
Me too. And we're not anymore. And things have changed since we were - unless you've left the development game in the last 18 months. "Why 18 months Andy?" Because things change every 1.5 years for application and web devs. "Things change for us too!" Yes, but not that often.
"So, Your Design Process?"
Oh. Yeah, that! :)
-
Using whatever documentation I have available - which may be written down, or dictated by a developer or customer, or scrawled on a cocktail beer napkin - identify the entities. I iterate a process remarkably similar to that described by Buck Woody (which makes me feel good, but which should worry Buck...).
-
Write the re-executable Create Database statement:
If Not Exists(Select name
From master.sys.databases
Where name = 'MyDatabase')
begin
print 'Creating MyDatabase'
Create Database MyDatabase
print 'MyDatabase created.'
Else
print 'MyDatabase already exists.'
-
Script the tables in T-SQL. Yep, I still type it old school. I like to include my default, check, and key constraints in-line with the row definition. My preference really, I just think they look pretty there.
-
Deploy! I want a shared sandbox development database out there for the app/web developers to play with as soon as possible.
-
Respond! Some of the app/web developers are going to change the schema. A subset of them will inform me of this fact. I keep RedGate SQLCompare running and minimized while in a sprint. When the app/web developers check in new code, I compare the shared sandbox development version of the database to my pristine copy. And then I update my scripts to match their version. And then I version-control my scripts along with the app/web code.
-
As table design stabilizes, I wrap a DPI (Database Programmers Interface) around the CRUD in the form of stored procedures.
-
Rinse, repeat.
Conclusion
This won't work everywhere and for everyone, but it works well for me. Treat it like a buffet - if you see something that might help, grab that and ignore the rest.
:{> Andy
|
-
Introduction
This post is the sixth part of a ramble-rant about the software business. The current posts in this series are:
Out There
If you read this blog you already know I share a lot from my life. I think that's a cool part of blogging and I praise folks for being transparent. Everyone has a different tolerance for transparency. It's like a sweet tooth: most people like sweets some of the time, some like sweets way too much, and some can't stand sweets.
Some folks can't stand transparency, others share too much information, and most find themselves in the middle somewhere. I try to strike a balance online and as a team leader.
How Do You Know You're Doing It Right?
Heck I don't know! What works for me works for me. It may not work for you. If I'm getting requests for more information and requests to share less, I feel like I'm in the middle of my target audience; that target being people who are comfortable with the amount of information I share.
I don't share everything. I don't even share everything technical. Some of the things I don't share are business-related - things like personal projects I'm tinkering with that may have business value in the future. I don't share proprietary Unisys information at all. In addition, I don't share everything that's going on personally. I draw my own line and it's in a different place than some, although it leans to the transparent side.
Applied To Leadership
Ask the folks on my team and they'll tell you I'm like this at work too. Most of my team know a lot about what's happening in my personal life. They know when I'm going to take a road trip and where I'm going. They know my kids - mainly because I work from home and my kids can (and do) occassionally, though not often, pop into my office when I'm in the middle of a conference call.
What does this transparency at work do for me? Well, it keeps life simple, for one thing. You get the same Andy in the community that you get at work. In the community, I Am Here To Help™. At work, I Am Here To Help™ too. (Note: I wish I'd thought of the ™ symbols on my own, but I didn't. My boss - whom I'm trying to talk into blogging about the software business - started applying ™ to several phrases he repeats to his team often. I thought it was cool enough to steal the idea!)
I find transparency is contagious. It also breeds trust, respect, and loyalty. I've learned the best way to encourage loyalty is to engender it. In other words, be loyal to folks if you want their loyalty.
"Big Words Andy, But How Do You Pull It Off?"
Another excellent question! I find lots of opportunities to engender loyalty by observing others. A few others know how to inspire loyalty, but this minority is far outweighed by those who know how to squelch loyalty in its tracks.
An example: Once a project is complete and running in Production, managers will be lining up to pat the development team on the back, buy them lunches, and tell them what a great job they did. There is nothing wrong with this and it's perfectly normal. The opportunity lies in the fact that while the work is in progress, these same managers are composing nasty emails and making threatening phone calls and, in general, not being very polite. What those managers do not realize is: The work they will later be patting the developer on the back for doing - the very developer they're currently threatening - is being done at the very moment the manager is behaving badly. As I mentioned in IT Coaching - Software Well Done, Part 1, the manager is simply "punching the developer in the brain" with this behavior. And make no mistake, this slows down development; and consequently, delivery.
The opportunity here is to praise the developers "mid-stream." Let them know - while the project is still under development, and especially if things aren't looking good - that you have the utmost confidence in their ability. The effect is astounding.
One important note: Don't lie. Don't tell the developers you have confidence in them if you don't. They'll figure it out as soon as you lose your cool after an onerous meeting with the client and come yell at them... they're smart like that, those wily developers.
Conclusion
You can help your team deliver more and effectively and sooner if you inspire them. Transparency helps, as does support during the "winter months" of a project's development cycle.
:{> Andy
|
|
|
|
|
|