THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server Integration Services Design Patterns and Managing Geeks - A Journey of Leading by Doing, and author of the Stairway to Integration Services.

  • Presenting at CodeStock 2015!

    I’m honored to present two sessions Friday 10 Jul 2015 at CodeStock 2015! At 10:15 AM, right after the keynote by THE Scott Hanselman, I’m presenting Designing an SSIS Framework. At 2:40, I’m presenting SSIS 2014 Data Flow Tuning Tips and Tricks.

    I hope to see you there!


    Learn more: 
    Stairway to Biml
    Linchpin People Blog: SSIS
    Stairway to Integration Services

    SSIS Design Patterns

  • Presenting SSIS Data Flow Performance Patterns at Charlotte BI Group 7 Jul!

    I’m honored to present “SSIS Data Flow Performance Patterns” at the Charlotte BI Group 7 Jul 2015! In this session, I discuss Data Flow Task internals and patterns that improve SSIS 2014 Data Flow performance in your data integration enterprise: Incremental Loads, Blob Pyramid, and Type 2 New + Updated Rows. Plus, I tell funny stories (well, I think they’re funny stories) about data integration development using SSIS.

    Register here!

    If you’ll be in the Charlotte area next week and would like to learn about SSIS Data Flow Task performance, I invite you to stop by and introduce yourself. I’m the fat guy with the long beard. I hope to see you there!


    Learn more: 
    Stairway to Biml
    Linchpin People Blog: SSIS
    Stairway to Integration Services

    SSIS Design Patterns

  • So Long, and Thanks for All the Scripts!

    With mixed emotions, I just read The End of an Era – SQLFool scripts are now open-sourced. After two book projects together, I admire Michelle (New Blog | @SQLFool) immensely. More than that, I consider her a friend.

    It’s exciting to (try to) keep up with all the cool stuff Michelle’s working on, and I am very happy for her.

    Thanks for all the cool code, ma’am!


    Learn more:


  • 701


    It’s your turn. You start blogging. You cannot start in July 2007 like I did – even if you have a Delorean. But you can start in July 2015.

    Here’s the thing: In 2023, eight more years will have passed. Will you have posted 700 blog posts by then? You can. How do I know? It’s possible.

    “What Do I Blog About, Andy?”

    • What was the last trouble ticket at work?
    • How did you solve the last problem you encountered?
    • What was the topic of that email you got last week about some new thing that needed to be implemented?
    • Do you have older systems you need to keep running? How are you doing that? What are your plans for keeping them going into the future?
    • In short what did you do last week?

    “But, Andy,” you say, “I found the answer on your blog.” Cool. Start there:

    The other day I ran into this issue. I searched for the error code and found a link to Andy’s blog. His post didn’t (or did) solve the problem for me. But I learned about _____. From there I found _____. And then I did _____.

    That’s a blog post. “That’s not going to help anyone, Andy.”

    Yes it is.

    You’re going to discover things implementing the solution to the problem you are trying to solve – things I did not encounter. You are going to solve those issues in your way. And you will learn stuff. A bunch of people already know the answer to the issue you are writing about. But way more people do not. Some of them are not even doing database work in 2015. How do I know? Not everyone reading this blog post was working with databases when I started blogging here 2007.

    The next eight years are going to pass whether you write anything or not. What are you going to do? Wait? Or get started?

    I triple-dog-dare you to start blogging.


  • 700


    Adam Machanic (Blog | @AdamMachanic) emailed me way back in July 2007 and asked if I’d be interested in joining the awesome crew blogging at I was honored to be asked and loved the idea of joining the bloggers here (“A group of really smart SQL Server bloggers… plus me”).

    And wow – this is my 700th post at SQLBlog!

    Thank you, everyone who reads this blog! I believe I get more out of writing these posts than readers get from reading them, but I regularly hear from readers – via email and the comments – who share their feedback and appreciation.. There’s no greater compliment for a blogger than to learn something they wrote helped someone else.

    My first post titled SSIS Design Pattern - Incremental Loads went live 9 Jul 2007, almost eight years ago. That post has been viewed 191,535 times. I find that overwhelming, but that’s not the most-read post over the past seven years. That distinction belongs to This Isn’t Hard: Allow Spouses to Attend Conferences with 472,217 reads.

    Here’s to the next eight years and posts 701-1400!


  • Want to Learn More About SSIS and Biml? Upcoming Training Opportunities!

    Here’s a list of upcoming training opportunities for people wanting to learn more about SQL Server Integration Services (SSIS) and Business Intelligence Markup Language (Biml):

    27 May, Join Tim Mitchell (Blog | @Tim_Mitchell) and I, as well as Linchpins Kevin Hazzard and Kent Bradshaw, for Office Hours: Is Biml Right for You as we answer YOUR questions about SSIS development with Business Intelligence Markup Language (Biml). It’s free!

    I’ll be attending SQL Saturday #409 – Rheinland in Germany 13 Jun 2015 and presenting a day-long PASS Essential Event titled Advanced SSIS Design Patterns and Automation with Biml in Bad Homburg (near Frankfurt) on Monday, 15 Jun 2015.

    I return to London to work with my friends at Technitrain and deliver SQL Server Integration Services Design Patterns 7-10 Sep. The target audience for this course is intermediate SQL Server Integration Services developers (or quick learners) who wish to learn best practices and design patterns, and those who wish upgrade their existing SSIS skills to 2012 or 2014.

    Tim Mitchell and I have two deliveries of Advanced SSIS Training planned for the remainder of 2015! Each training is four days of SSIS data flow internals, performance design patterns, fault tolerance and error handling, security, deployment, data quality, metadata management, Biml, SSIS limitations (plus workarounds), and ETL edge cases. 28 Sep – 1 Oct we’re in Alpharetta, Georgia; and 7-10 Dec we’re in Reston, Virginia.

    I hope to see you at one of these events!


    Learn more: 
    Stairway to Biml
    Linchpin People Blog: SSIS
    Stairway to Integration Services


  • Sometimes, You Need to Tune Your Guitar Differently


    Years ago (decades, actually), I was part of a Christian alternative music band called Now eye See Why. We performed mostly original music at coffeehouses, music festivals, and in bars in the Richmond Virginia Fan district. We made a couple recordings and were signed to a small label for a time. I sang backup (mostly) and played guitar, keyboards, and (rarely) alto sax. On a related note, I can’t hear very well nowadays.

    That’s NeSW in the picture above: Mark, me, and Dexter from left to right. I think this picture is about 23 years old. Look at that hair!

    I learned to play piano some when I was tall enough to see the keys (not over them) – around the age of four. Mom played piano – she still plays and I still love to hear her play. Although we both play “by ear,” we play completely differently and prefer different keys. I enjoy playing the guitar, which I learned at age 16. Learning guitar was easier after years of piano because the keyboard is a visual representation of a music scale. A keyboard lays out all the notes linearly, which also greatly simplifies their relationship: higher notes are to the right, lower notes are to the left. That’s not how guitars work, however.

    The guitar I play has six strings. The way I play – and there are other ways to play a six-string guitar – the lowest note is the open sixth string, the topmost string, traditionally tuned to an E. The other strings are tuned at intervals of fourths with one exception, the second string is tuned at an interval of a major-third above the third string. This results in a pattern from sixth to first string: E-A-D-G-B-E.

    But there are other ways to tune a six-string guitar.

    I won’t go into all the different ways to tune a guitar here. You can click the Wikipedia link above for more information or search YouTube to learn more. Guitar-tuning isn’t really my point in this post. My point is…

    Producing Results by Alternative Means

    I’m beginning a coaching engagement with a talented data warehouse team. They came to Linchpin People because they have tried to build a data warehouse and not succeeded, and they wanted to know if we can help. We can, and this is going to be a cool engagement because we will be using Business Intelligence Markup Language (Biml) to respond to some tricksy requirements.

    Preparing for this gig reminded me of the orchestration involved in performing with the guitar. You see, sometimes – especially when you’re learning guitar – you need to teach the muscles in your fingers to do things they’ve never done before. To “get it right,” you bend yourself to the instrument and the work at hand. It’s an important part of learning, doing things the way the piece of music and instrument requires.

    But it’s not the only way to perform.

    Changing the Guitar

    Once a student has learned how to perform guitar pieces with standard guitar tuning, they may venture into performing with alternative tuning schemes. The most common alternative tuning I use is called “dropped tuning,” where I lower the sixth string from its (already low) E to a D. If you’re playing an electric guitar with distortion, that low D – especially through a Mesa Boogie or Peavey amp with Black Widow speakers – will reach out and rattle your soul! But I digress…

    Alternate tunings change the conditions – the chord fingerings and pitch – available to the guitarist. Alternate tunings allow the guitar to produce combinations of sounds that are difficult-to-impossible with standard tuning, producing a combination of ranges that are unique enough to define a song.

    Applied to Software…

    How does this apply to delivering software solutions?

    Using Biml is like retuning the guitar on a massive scale. It allows an SSIS developer to achieve phenomenal results – results that define a project. How?

    Biml Speeds Up SSIS Development

    If you find you need to produce multiple SSIS packages built to extract, transform, and load data in the same way; Biml is an awesome solution. Rather than copy and paste, Biml provides BimlScript which allows you to create “template-ized” code that will build multiple SSIS packages based on any pattern you spin up. I cover using Biml and BimlScript to produce SSIS packages that use a basic Incremental Load pattern in the Stairway to Biml Levels 2, 3, and 4 at SQL Server Central. You can build several, dozens, or even hundreds of SSIS packages in a fraction of the time it would take to code them manually.

    Biml Improves Code Quality

    Because Biml and BimlScript rely on patterns to automate SSIS package generation, the packages are not subject to copy and paste errors, or errors of human omission once a robust pattern is realized. If one package works, they all work.

    Changing the way we build SSIS solutions with Biml is like using an alternate tuning on the guitar. SSIS developers are able to produce SSIS solutions at ludicrous speed with improved quality!


    Learn more: 
    Stairway to Biml
    Linchpin People Blog: SSIS
    Stairway to Integration Services


  • Office Hours Webinar: Is Biml Right For You?

    Join my friend and colleague, Tim Mitchell (blog | @Tim_Mitchell) and me 27 May at 12:00 PM EDT for a Linchpin People Office Hours Webinar: Is Biml Right For You? 

    Business Intelligence Markup Language (Biml) is a complex topic, but well worth the time to learn. Linchpin People has been using Biml for years, and we have real-world experience delivering solutions based on Biml. We know where Biml saves time and, perhaps more importantly, where Biml will not help.

    The event is a Q & A format and we’re taking questions now via email. We will also be answering questions posed by attendees.

    Join us 27 May! We look forward to speaking with you.


  • Great Scott! Linchpin People is Going… Back to SQL Saturday Atlanta!

    SQL Saturday #392 is happening THIS SATURDAY! I’m looking forward to returning to Atlanta, where almost everyone speaks without an accent.

    The schedule looks awesome!

    I’m excited that several Linchpins were selected to present because this means we’ll get to hang out in person. I’m also excited to see so many friends from #SQLFamily, too, including (Great) Scott Currie, who will be presenting SSIS Unit and Integration Testing with the Open Source BEST (Biml Enabled SSIS Test) project.

    Linchpin People’s co-founder, Brian Moran, is delivering a half-day precon Friday 15 May titled Secrets of Independent Consulting. It’s a steal at $50. I’m delivering Using Biml as an SSIS Design Patterns Engine.

    I hope to see you there!


    Learn more: 
    Stairway to Biml
    Linchpin People Blog: SSIS
    Stairway to Integration Services


  • Advanced SSIS Design Patterns and Automation with Biml PASS Essential Deutschland–15 Jun 2015!

    I am honored to deliver a full-day PASS Essential in Germany 15 Jun 2015! I’ll be sharing:

    • Advanced SSIS Design Patterns and Automation with BIML
    • Advanced SSIS Design Patterns for performance, support, and maintain-ability
    • Data Flow performance patterns
    • SSIS Catalog-integrated Execution Frameworks
      • Connections and parameters management using Catalog Environments BIML
      • Metadata-driven SSIS pattern selection and mapping
      • Catalog-integrated Framework metadata automation with BIML

    The cost for PASS Deutschland Members is € 299 (incl. VAT.). the cost for Non-members of PASS Deutschland Members is € 475 (incl. VAT.). There are 12 seats available, so email today if you’re interested in attending.

    To register, please email registrierung [at] sqlpass [punkt] de.

    Ich hoffe, Sie dort zu sehen! (I hope to see you there!)


  • Database Design: 3-State Bits

    I can hear you thinking, “Andy, you’re off your old rocker. There are only two states for bit values!” And you are correct. Almost.

    What if I’m storing a truly binary value – a value that possesses only two possible states – but there’s the possibility of a third state to indicate that I do not know which state applies. Consider this single-column example table:

    Don’t Know or Don’t Care

    The two discrete states are High and Low. The 3rd state can be labeled “unknown.” Can I represent these three states using a bit data type?


    I can do it with a NULL:


    NULL means “the data is missing.” But in this context, I can define NULL to mean “unknown.” One caveat is that I cannot define to NULL to mean both “missing” and “unknown.” I have to pick one and only one meaning for NULL.


  • Andy-Frickin-Leonard

    A few years ago at a conference, a young man approached me and asked if I was ready for my presentation. I squared with him (for emphasis) and replied, “No, sir. In fact, I’m worried about it.” He looked a little stunned and said, “Why?” “I’ve never done this presentation before, I don’t like the flow of the material yet, and I’m concerned it’s going to fall flat when I deliver it.” Looking aghast, he said, “But… you’re Andy-frickin-Leonard.” “I’ve been trapped in here with me for several decades and I am not impressed,” was my reply.

    I’m always nervous before presenting, but that’s not what I want to write about this fine morning. I want to write about...


    I’ve been dealing with my pride for a while now. I didn’t see it as that big of a problem until recently, though. Like yeast working its way through the entire lump of dough, a little pride never remains little for long.

    Two months ago I wrote Social Media and Me. As with every story, there’s more to that post than I’ve currently shared. I’m not going to share all of it here, and I may never share all of the story. Suffice it to say that the story began some months before that post, and that it continues after this post.

    I like learning stuff. Why? I’m not entirely sure of all the reasons – at least not now. But I can tell you part of the reason is that I like to understand how things really work. It’s a quest for truth for me, and one of the reasons I’ve started referring to myself as a Data Philosopher (I’m not smart enough to be called a Scientist). I’ve recently discovered another part of the reason is that I like being right. That doesn’t mean I hate being wrong – I see being wrong as necessary to learning what’s right. Mistakes and failures are part of life and engineering and philosophy, so I promise I never hated being wrong.

    I really enjoy engineering because it provides a framework (the scientific method) for learning what’s right. One can still make mistakes applying the scientific method – like asserting a premise – but, the scientific method is a good way to discover more accuracy. I believe accuracy is underrated but that’s another post…

    Empirical vs. Imperial

    My decrease in social media participation was driven by a realization that I didn’t care what others thought about what I wrote. That’s ok when I’m writing about engineering because (hopefully) I have evidence to back up any premise I assert. It’s not ok when writing about politics, however, because people have reasons for believing what they believe. I have no convincing evidence that I’m right and they’re wrong. But to help, I was spending social capital gained from sharing experience in the pursuit of knowledge in some wild attempt to prove the unprove-able (without the lens of objective history and hindsight). What was I trying to accomplish? At the time of this writing, I cannot honestly answer that question.

    I’m thankful some friends helped me see what I was doing. Am I done yet? Am I better? I am not done. Not by a longshot. I am maybe a little better. I’m definitely more aware of my pride and its role in my past behavior.

    A New Beginning

    One aspect of my faith (Christianity) is the concept of new beginnings. Lamentations 3:23 states: “The steadfast love of the Lord never ceases; his mercies never come to an end; they are new every morning; great is your faithfulness.” An interesting thought, especially in a book titled Lamentations.

    In an effort to address my pride, I promised to never again comment on political posts on social media. Do I have political opinions? Yes. Do my opinions align with the worldview of most? Nope. Is that going to change? I don’t expect it will. Will it change because I wrote something on Facebook? Definitely not. If anything, Facebook entrenches opposing opinion, it doesn’t change it. “I read your comment / post and decided you’re right and I’ve been wrong all this time,” wrote no one. Ever.

    So I’ve stopped posting on politics.

    Not So New

    Having a few months perspective on this decision provides the insight that this really isn’t such a new direction. The past few years, I’ve been led steadily and unswervingly away from doing stuff that doesn’t produce change to doing stuff that does. I had a pithy and intentionally-offensive term I used to describe non-productive behavior that merely feels good. It applies to my previous behavior but I won’t repeat it here. I will simply state, “Guilty,” and move forward.


    This book, Unoffendable, helped me a lot. It’s a book written from a Christian worldview perspective. It doesn’t even try to address change outside of the perspective of Christian faith. Ironically, that may offend some.

    I already knew I didn’t have a right to judge others. I did not realize I do not have the right to be angry. I knew pride is a killer. I did not realize how my pride was feeding my right-to-my-rights.

    What Am I Doing?

    One thing I’m doing that will help is serving people in Honduras. I’m looking forward to another opportunity to help. I’m thankful for the opportunity and the ability – neither originates with me; both are a gift. You can help, too. That link will take you to a GoFundMe page. All the money we collect will be used to send our team from Farmville to Tegucigalpa. Any money raised beyond that amount will be left in Honduras to serve those in need.


    I don’t think so. While I am humble about what I’ve learned and share regarding technology, I was anything but humble about my political beliefs. I was doing social media wrong.

    I still believe in doing business personally (and disagree with those who say, “It’s not personal, it’s business.”). That means I’ll continue to mix my faith and business, and I’ll continue to believe that’s a good thing in any field – but especially in the field of data where integrity is important.

    And the young man who said that to me? He knows better now. I’m not anything special – with technology or anything. I make mistakes, I learn stuff every day, and I’m growing right along with everyone else. I have such a long way to go.


  • On Kindness

    Do you remember that time kindness backfired? Do you remember kindness letting you down? Me neither.

    Kindness never fails.

    I can hear you thinking, “Yeah, Andy? Well there was this time I was kind and…” The thing you’re going to finish that sentence with, the thing that didn’t happen? That wasn’t going to happen anyway. But here’s what did happen. Because you were kind, the person to whom you were speaking was left with nothing but your request to think about as they later reflected on the conversation.

    What if you’d been unkind? Then, upon reflection, the person to whom you were speaking will reflect on your unkindness. How do I know? I’ve been unkind. I’ve experienced unkindness from others. Kindness may improve the odds that your request will be granted. Kindness always improves the odds of you being heard. Unkindness produces the opposite in effect and in being heard.

    Some will misinterpret your kindness as weakness. That’s simply inaccurate. Many kind people are meek, but meekness is not the same as weakness (even though they rhyme). One trait of the people I consider wisest is: they are meek. In Receptive Human Virtues (2011), E. A. Cochran writes, “Meekness has been contrasted with humility as referring to behaviour towards others, where humbleness refers to an attitude towards oneself.”

    Meek in Action

    Have you ever looked at the work of someone else and said, “They did this wrong.”? Or, “They didn’t know what they were doing”? or “Who wrote this crap!”? I say that last one a lot… when reviewing my older code, but I digress… When speaking to an authority or client who doesn’t understand our craft, it’s easy to make ourselves look and sound knowledgeable and important by denigrating the work of others.

    There’s risk here, though.

    If you’re operating in this fashion – especially as a consultant – you’re conditioning your client to accept the latest word from the latest “expert” when that word is critical. Are you the only person who operates in this way? Nope, you are not. If you want to grab the money and run, poo-pooing the work of others is effective.

    “But what if the work is crappy, Andy?” Find a better way to say it. “I would not have designed this solution this way.” “There are updated patterns for solving this issue.” “I found an error.” Are any of those statements derogatory towards the original developer? Nope. Does the client walk away thinking, “I have someone who knows how to solve my business problem!”? Yep. And, at no extra charge, you’ve insulated yourself from the next cut-and-run “expert” who looks at your code with the client. You’ve built a new impression in the mind of your client: Real experts are kind.


    Why am I blogging about this? For the same reason I blog about many things: I’ve failed and learned from my mistake. My hope is that someone will learn from my mistake and not fail, and that our community will be the better for it.


    Learn more:


  • Real World SSIS: A Survival Guide, 8 May, Baltimore

    My friend and fellow Linchpin, Tim Mitchell (blog | @Tim_Mitchell) will deliver a day-long seminar titled Real World SSIS: A Survival Guide the day before SQL Saturday – Baltimore (9 May). Attend and learn more about:

    • Handling warnings, errors, and other bad stuff
    • Data cleansing using SSIS, T-SQL, and DQS
    • More than just a green box: validating the results
    • Managing variables, parameters, expressions, and scripts
    • Identifying and resolving performance bottlenecks
    • Evaluating the new features of SSIS 2012-2014
    • Choosing and using the right package deployment model
    • Automating SSIS development with Biml
    • When SSIS might *not* be the best choice

    Tim Mitchell is a friend and co-author of both editions of the SSIS Design Patterns books. Plus, he’s an awesome instructor! I encourage anyone interested in learning more about SSIS to attend Tim’s seminar.


    Learn more: 
    Stairway to Biml
    Linchpin People Blog: SSIS
    Stairway to Integration Services


  • Software Economics and Testing

    There are two types of developers: those who test their software and those who will.” – Andy, circa 2015

    It’s April Fool’s Day in the US, but I’m going to act like it’s Halloween. Software testing is no joke, and not testing should scare you.

    In 1996 (yes kids, years used to begin with a “1”), in the sixth issue of Fast Company magazine, Charles Fishman wrote They Write the Right Stuff – an article about Lockheed Martin’s On-Board Shuttle Group and the work they did writing and maintaining software for NASA’s Space Shuttle program. Some interesting “nummers” from the article:

    • 420,000 lines of code.
    • 1 error in each of the previous (at the time of writing) versions.
    • The previous 11 versions of the software contained a total of 17 errors.
    • $35,000,000 / year budget.

    I did the math: maintaining each line of code was $83.33/year. Plus 1/3rd of a penny. In 1996 money. According to the US Inflation Calculator, that’s equivalent to $124.12 per line-of-code per year today.

    I mention the economics because I’m a consultant. I know how much I charge for my time. I have a pretty good idea what others charge for their time. I co-own Linchpin People, and we subcontract software developers for ourselves and other companies. I know what we pay software developers and how much we charge others for their services. At the risk of disillusioning those who aspire to co-own their own technical consulting firm, we have precisely 0 clients paying us $35,000,000 per year – even in 2015 money ($35 million in 1996 would be north of $52 million in 2015).

    Why not? Because that’s a lot of money to pay for software. When lives, safety, and the pride of a nation are on the line, you’re paying for more than “just software.” The value of maintaining the Space Shuttle software was worth those costs. The cost/benefit analysis was sound.

    What’s the value of your software?

    Some Important Questions

    As you ponder the “nummers,” you are likely thinking about the software in your enterprise. Or maybe just the programming-for-fun project you’re working on in your spare time. It may be prudent for you to spend some time thinking about the costs and benefits of your software. Here are some questions to get you started:

    • How important is your software?
    • What’s at stake if your software fails?
    • What are the risks?
    • Can your enterprise tolerate your software being offline for some period of time?
      • If so, for how long?
      • Are some times worse – riskier, higher stakes – than other times?
    • What’s your backup plan if your software dies and cannot be brought back?
      • What happens if you lose Production data?
        • Even all of it?

    You may read that list and think, “Andy, you’re just trying to scare me.”


    You durned right I’m trying to scare you. If fear is what it takes to wake you up to the realities of your situation, I’m not above scaring you. (In my mind, I just wrote, “I am an engineer.” But I digress…)


    If we were an agricultural society, it would be prudent to educate you about pests, soil care, and crop rotation. If we were manufacturers (and please understand, software is not manufactured…), it would be good to advise you to maintain a safe and healthy work environment for those who keep the machines running and keep your machinery in working order. But we make software.

    What are the corollaries? One good way to mitigate risk is to possess and practice a process.

    Before I go too far in this discussion about process, I want to reiterate my belief that people build processes to help people, processes are living and subject to maturity and change, therefore, people should always trump process. If you find a process harming a person’s life, liberty, or pursuit of happiness; you should re-examine the process. Processes should serve people, not the other way around. That’s ground rule #1 and it’s non-negotiable.

    The Lockheed Martin team practiced a process. It is enumerated in the article (did you read the article yet? You should. Right now, if you haven’t already. It’ll only take a few minutes…):

    1. The product is only as good as the plan for the product.
    2. The best teamwork is a healthy rivalry.
    3. The database is the software base.
    4. Don't just fix the mistakes — fix whatever permitted the mistake in the first place.

    This list is rich. But you’ve read a lot already so I’m going to bring this post home by unpacking #4.

    Mistakes Are Normal

    Even at $124 per line of code per year, mistakes happen. If you believe you can pay enough people enough money to eliminate errors in software, you are mistaken (see what I did there?). And if one of the risks you identified in the Some Important Questions section above is, “People could get hurt,” you need to do all the engineering you can to see that people do not get hurt. But even if you do everything humanly possible to prevent and mitigate mistakes, you will never eliminate mistakes. So the very first step is to realize – and act like you realize – mistakes are going to happen.

    Want to manufacture stress? Create a culture that does not tolerate mistakes. How? Rant, rave, yell, reprimand, and fire people when they fail.

    Want to deliver great software? Create a culture that tolerates mistakes. Even better, create a culture where failing fast is celebrated. Why? People learn from mistakes. People who make more mistakes learn more. People who fail faster learn faster. People who learn faster make great software.

    Mitigate the Negative Effects of Mistakes

    Failing safely is the best way to mitigate the negative effects of mistakes, that’s why martial arts students first learn how to fall. Why? Because they’re going to fall! So are you. Identifying software errors quickly (failing fast) is a profitable practice. Testing software is the best way to identify software errors. There are some rules to software testing and the rules are important:

    1. Test in a safe environment.
    2. Test realistically.
    3. Do not allow developers to test their own code.

    Test in a Safe Environment

    Set up a virtual machine. Something. Anything – except the Production server. There are conditions that need to be tested on the Production server. But, please, do not let “we need to test this in Production” be your first thought. Exhaust every other option first. Please.

    Test Realistically

    The reason you sometimes need to test software in Production is that there simply isn’t another server or environment in the enterprise that looks and acts like Production. There can be sound business and economic and timing reasons for such a condition. If you cannot test realistically in a safe environment, test as realistically as you can in a safe environment before testing in Production.

    Do Not Allow Developers to Test Their Own Code

    Do you want to read some stories of heartache? Some rants? Some helpful advice? Search for “Developers test their own code.” It will bum you out. And it may also help. Let me state up front that I develop software (SSIS is software even though contains “SQL Server” in its name). I miss things when I test my own code. Some of the links from the search above will contain stories about how and why this happens. Trust me. It happens.

    Get someone other than the developer to test the code. Prepare a test plan – even if the plan is “run this script on this test server.” That’s a test plan. It’s good enough for someone who understands what the code is supposed to do, or for anyone capable of interpreting a green/red indicator.

    Developers should conduct unit tests and functional tests. They should execute the code in a development environment to make sure it runs, does what they think it should do, and returns the expected results. Then someone else should run their code somewhere else to make sure all those things happen over there – in some location other than the environment where the software was built.


    Remember: All software is tested; some, intentionally. What does that mean? That means that untested code is going to be tested in Production. Sometimes, the people testing your software in Production are your soon-to-be former largest customer. Think about it. Please. If this scares you, then good: I’ve accomplished what I set out to do.


    Learn more: 
    Stairway to Biml 
    Linchpin People Blog: SSIS 
    Stairway to Integration Services 


This Blog



Friend of Red Gate

My Company

Blog Roll

Check out the Linchpin People Blog...
Linchpin People Blog

Contact Me


Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement