Biml, Book Reviews, and Metadata-Driven Frameworks

I occasionally (rarely) read reviews at Amazon of books I’ve written. If I learn of a complaint regarding the book I often try to help. If a reader experiences difficulty with demos, I often offer to help, and sometimes I meet with readers to work through some difficulty related to the book (as I offered here). About half the time, there’s a problem with the way the book explains an example or the sample code; the other half the time the reader does not understand what is written.

I own both cases. As a writer it’s my job to provide good examples that are as easy to understand as possible. Sometimes I fail.

In very rare instances, I feel the review misrepresents the contents of a book –  enough to justify clarification. This review afforded one such opportunity. None of what I share below is new to regular readers of my blog. I chose to respond in a direct manner because I know and respect the author of the review, and believe he will receive my feedback in the manner in which it was intended – a manner (helpful feedback) very similar to the manner in which I believe his review was intended (also helpful feedback).

Enjoy.

My Reply to This Review of The Biml Book:

Thank you for sharing your thoughts in this review.

I maintain successful technology solutions are a combination of three factors:

  1. The problem we are trying to solve;
  2. The technology used to solve the problem; and
  3. The developer attempting to use a technology to solve the problem.

I believe any technologist, given enough time and what my mother refers to as “gumption” (a bias for action combined with a will – and the stubbornness, er… tenacity – to succeed), can solve any problem with any technology.

I find your statement, “It doesn’t really teach BIML but rather teaches a specific optional framework for those who want to do everything with BIML rather than increase productivity for repetitive patterns” inaccurate. Did you read the entire book? I ask that question because I most often encounter readers who state the precise opposite of the opinion expressed in this review (some of your fellow reviewers express the opposite opinion here, even). I disagree with your statement, but I understand your opinion in light of other opinions expressed to me by readers during my past decade+ of writing several books. I share one example in this blog post. The short version: we often get more – or different – things from reading than we realize.

There is a section in The Biml Book – made up of 3 of the 20 chapters and appendices – that proposes a basic metadata-driven Biml framework which is the basis of a metadata-driven Biml framework in production in several large enterprises. I wrote those 3 chapters and the basic metadata-driven Biml framework in question. Varigence has also produced a metadata-driven Biml framework called BimlFlex – based upon similar principles – which has been deployed at myriad enterprises. The enterprise architects at these organizations have been able to improve code quality and increase productivity, all while decreasing the amount of time required to bring data-related solutions to market. They do not share your opinion, although they share at least some of the problems (you mentioned ETL) you are trying to solve.

Am I saying Biml – or the framework about which I wrote or even BimlFlex – is the end-all-be-all for every SSIS development effort? Goodness no! In fact, you will find disclaimers included in my writings on Biml and SSIS frameworks. I know because I wrote the disclaimers.

Misalignment on any of the three factors for successful technology solutions – the problem, the technology, and/or the developer – can lead to impedance mismatches in application and implementation. For example, Biml is not a good solution for some classes of ETL or data integration (points 1 and 2). And learning Biml takes about 40 hours of tenacious commitment (which goes to point 3). This is all coupled with a simple fact: data integration is hard. SSIS does a good job as a generic, provider-driven solution – but most find SSIS challenging to learn and non-intuitive (I did when I first started using it). Does that mean SSIS is not worth the effort to learn? Goodness, no! It does mean complaints about simplifying the learning process are to be expected and somewhat rhetorical.

Architects disagree. We have varying amounts of experience. We have different kinds of experience. Some architects have worked only as lone-wolf consultants or as members of single-person teams. Others have worked only as leaders of small teams of ETL developers. Rarer still are enterprise architects who are cross-disciplined and experienced as both lone-wolf consultants and managers of large teams in independent consulting firms and large enterprises. Less-experienced architects sometimes believe they have solved “all the things” when they have merely solved “one of the things.” Does this make them bad people? Goodness, no. It makes them less-experienced, though, and helps identify them as such. Did the “one thing” need solving? Goodness, yes. But enterprise architecture is part science and part art. Understanding the value of a solution one does not prefer – or the value of a solution that does not apply to the problem one is trying to solve – lands squarely in the art portion of the gig.

Regarding the science portion of the gig: engineers are qualified to qualitatively pronounce any solution is “over-engineered.” Non-engineers are not qualified to make any such determination, in my opinion.

By way of example: I recently returned from the PASS Summit. Although I did not attend the session, I know an SSIS architect delivered a session in which he made dismissing statements regarding any and all metadata-driven frameworks related to ETL with SSIS. If I didn’t attend his session, how do I know about the content of the presentation? A number of people in attendance approached me after the session to share their opinion that the architect, though he shared some useful information, does not appreciate the problems faced by most enterprise architects – especially enterprise architects who lead teams of ETL developers.

My advice to all enterprise architects and would-be enterprise architects is: Don’t be that guy.

Instead, be the enterprise architect who continues to examine a solution until underlying constraints and drivers and reasons the solution was designed the way it was designed are understood. Realize and recognize the difference between “That’s wrong,” “I disagree,” and “I prefer a different solution.” One size does not fit all.

Finally, some of the demos and Biml platforms were not working at the time you wrote this review. Many have been addressed since that time. In the future, updates to SSIS, Biml, and ETL best practices will invalidate what this team of authors wrote during the first half of 2017. As such, the statements, “And much of the online information is outdated and no longer works. It’s a shame someone hasn’t found a way to simplify the learning process.” is a tautology that defines progress. Learning is part of the job of a technologist. I encourage us all – myself most of all – to continue learning.

Peace.

Leadership and Failure

How Do People Learn?

There’s ample debate about whether people learn from mistakes. Don’t believe me? Search and see for yourself. There are compelling arguments for  both learning from our mistakes and not learning from them.

In engineering and software, I think we learn from our mistakes. I can hear you thinking, “Why do you think that, Andy?” I’m glad you asked.

I think we learn from our mistakes because most of what we attempt fails. We live and breathe in a profession where failure is normal. As we grow and mature and improve as technologists, many come to divorce negative emotions from failure. That’s one trait I look for in enterprise architects – a question I seek to ascertain: Have they separated failure from negative emotions about failure? Here’s something I’ve learned:

Good architects not only don’t feel bad when they fail, they embrace failure.

“That’s crazy talk, Andy!”

Perhaps. It’s also accurate. Why in the world would anyone embrace failure? If one believes failure is a necessary step on the path to success, one embraces failure.

Communicating Failure

In a universe that embraces S.M.A.R.T. goals, recording and reporting failure can be tricksy. I’ve written before about a very successful day of software development, but recording it against my performance metric of “lines of code written” backfired when the answer was -1,800.

In software, I believe we simply must learn from our mistakes. Failing fast is virtuous, and failing often is normal. If what we are doing is normal and virtuous, why then should we feel bad about it? The answer is:

We shouldn’t feel bad about failure.

Classification of Failures

What I am advocating is divorcing emotion from technical failures which are a certain class of failures.

I wrote earlier about offending people. We should feel bad about failing by offending people most of the time (I included one exception there at the end of my long, rambling post…).

So I will modify my earlier statement:

We shouldn’t feel bad about technical failures.

Conclusion

See what I did there?

I failed to communicate clearly and effectively.
I tried again, adding clarification.

Do I feel bad about that? Nope.
Neither should you.

Peace.

Bad Presentations

In just a few short weeks I am attending the PASS Summit 2018 in Seattle. Whenever I attend an event like the Summit or SQL Saturday I attempt to attend presentations of interest to me. I love learning new stuff!

Good and Less-Good

Most of the presentations I attend are good. Some are really good. They are delivered by talented technologists who are also gifted orators. This is an important distinction because:

Technology and communication are entirely different skills.

I’ve watched gifted presenters misrepresent the facts about technology.
I’ve watched gifted technologists fumble demos and stumble over words.

If I have to choose one over the other, I choose great technologists over great presenters. I do so without reservation or hesitation. Is it good to have both? Goodness yes! But – this is important – we don’t always get what we want.

Some Examples of Less-Good

There are categories of bad presentations and bad presenters. Three leap to mind:

  1. Someone who does not know the topic
  2. Someone who is not a good presenter
  3. Someone who is offensive

Presenters Who Do Not Know What They Are Talking About

I wrote recently about a complaint I see leveled at myself and others from time to time: “You do not know what you are doing.” I confess, sometimes that’s a valid complaint about me. While you might find the previous statement an example of humility (or false humility), I prefer to be in the state of not knowing what I am doing. Why? Because it’s an opportunity to learn and I love to learn.

That said, there’s a time and place for everything – including learning. When presenting a class or at a conference for which attendees or their employers paid good money, I strive to share what I have already learned, not what I am learning. Attendees of a free event, even, are paying with their time. So again, I strive for excellence in presentations at free events.

My lovely bride, Christy, attends on average one of my presentations per year. Early on she shared this advice, “Andy, no one likes to watch you troubleshoot.” As an engineer I didn’t even think about it. If something was broken, it needed to be fixed. Period. Pronto. If that meant dropping everything else – in front of a paying audience, even – so be it. Christy’s advice helped me become a better presenter.

I redesigned my talks to be demo-fault-tolerant. I changed my thinking about my presentations so that I am now more mentally prepared for demos to fail. I had something to say, always; I am aware not only that demos will fail. I am prepared for them to fail.

This preparation served me well when, in March 2018 at SQL Saturday Chicago, a drive on my laptop failed just before delivering a presentation that is 90% demos. What did I do? I talked through the demos. A friend approached me afterwards and said, “You looked ready for that!” I was ready for it. Nonetheless I responded (truthfully), “Thank you. I’m going to go sit down for an hour.” Even though I was prepared, it was exhausting.

Good Engineers

I can hear you thinking, “Wait, Andy. Your second item above is ‘Someone who is not a good presenter.’ You titled this corresponding section ‘Good Engineers.’ What gives?” I’m glad you asked.

I am an engineer. If you’ve read my bio you see the word “engineer” there.

I consider this a warning.

Are all good engineers bad communicators? Nope. Many – perhaps most – are, though. Take that last sentence. If English is not your first language I owe you an apology. If English is your first language, I owe you two apologies. It makes perfect sense to me, but any editor who saw that sentence in a manuscript would be compelled to add a comment; correct the sentence; or print the document, take it out back, and physically burn that sentence off the page.

Technology – or engineering – is a skill.
Communication is a skill.
Technology and communication are different skills.

As I stated earlier, I don’t care if the presenter is a bad communicator. There is at least one exception to this rule that I will cover next. But for the most part, I can learn from good technologists who stink at communication. I can learn from good technologists who are brilliant communicators but are having a bad day. How do I know I can learn from these people? Because I have, and do, almost every week.

And so do you.

You may not like the presenter.
You may not enjoy the presentation.
But do you learn? Yep. You do.

An Aside: I Hate Abstract-Writing Contests

I’ve organized community events in the past. I don’t do very much work on community events these days, although I serve as a mascot on a couple leadership committees because of my past adventures in similar endeavors. Occasionally – rarely, I would say – I offer some tidbit that helps. My role these days is mostly to encourage leaders who are on the verge of burnout.

Selecting speakers is an engine of loss. It’s bad when there are more submissions than slots. The effects are amplified if the event is popular. Speaker selection is a fantastic mechanism to irritate and isolate people. For years, in some cases. Everyone who submits believes their submission should be accepted. Otherwise, why submit in the first place? No one likes to hear, “No.” Everyone likes to hear, “Yes.”

I am the same as every other speaker in this regard.
I may be worse than most, even.

Peeves make lousy pets. Knowing this doesn’t stop me from nurturing a handful of pet peeves. One of my pet peeves is speaker selection based solely on the marketing value of the written abstract. I label this practice an “abstract-writing contest” and I believe it is one bane of a successful technical conference.

If you read that last paragraph and began composing a comment that includes a paraphrase of, “Then what would you have us do, Andy? Pick lousy abstracts?!” I feel for you. But I cannot quite reach you. </RedneckSnark>

My response is, “No. I would have you consider more than merely the abstract. And specifically more than its perceived ‘Marketing value.'” Mix things up a bit. Add some variety. Consider the popularity of the speaker’s blog or previous presentations, maybe. Again, there are exceptions (one of which I will address shortly). But here’s my point in a nutshell:

All good presenters deliver good presentations.
Not all good presenters write good abstracts.

Something must take precedence, some attribute must win. If you are organizing an event and / or selecting speakers, you probably don’t have the option of selecting great presenters who will deliver great sessions and who are awesome at writing persuasive marketing abstracts.

Should all presenters strive to write better abstracts? Goodness yes. But unless you’re planning MSIgnite or Build or ReInvent or a TedX, you’re probably not going to be in the position to choose among the great presenters with great abstract-writing skills. Even if this is so, you’re not always going to get it right. They don’t! I’ve been to enough global conferences and seen enough bad presentations to know.

So presenters, strive to write better abstracts.
And selectors, select some presenters who submit poorly-written abstracts. For goodness’ sake: If spelling errors bug you, correct the spelling before you publish anything. That’s not even hard.

</SoapBox>

Regarding Offense

I am of two minds as I begin this section. Here’s why:

  1. There are things I find offensive that, for me, go beyond the pale, crossing the border between acceptable and unacceptable in a public forum meant to convey knowledge to attendees.
  2. There are things I find offensive that I will tolerate in order to gain the knowledge I seek.

Stepping into a conference session, I sometimes do not know what to expect. I may be unfamiliar with the speaker. Perhaps their speaking style is abrasive, or abrasive in my opinion.

Perhaps the speaker uses excessive profanity. I can hear you thinking, “Who gets to define excessive, Andy?” The attendees get to define excessive. As an attendee, I get to define excessive.

I read about a presentation a few years ago where the speaker created a pornographic demonstration. Many in attendance found the presentation offensive, most found it unprofessional. I hope the speaker – obviously a talented technologist – learned from this mistake.

These are examples of the first type of offense, those I believe are unacceptable.

Perhaps the speaker mentions politics in jest and I disagree with their politics, so I feel belittled when those surrounding me in the room laugh at the joke. I may feel they’re laughing at me. They are certainly laughing at people like me.

Perhaps the speaker jokes about the less-sophisticated in our culture. I’ve heard the term “hick” and “redneck” bandied about, for example – terms with which I personally identify. I have people in Appalachia, from whence my family comes. “Trailer trash” was a term I heard years ago in a presentation. My teenage years were spent living in a mobile home. In a trailer.

Do these references offend me?
They do.

Do I tolerate these offenses?
I do.

You may read that last section and think something along the lines of, “Well, they must not offend you that much if you tolerate them, Andy.” To which I respond, “That’s not your call.” You do not get to make such an assertion. You lack the ability to see inside my mind and inside my heart, so you cannot accurately render judgment as to what goes on there. Further, you do not dictate how I think or choose to respond, publicly or privately. You do not have that right of imposition; not over me.

These are examples of the second type of offense; those I choose to tolerate.

Waxing Philosophical…

How should we then live?” is a question posed by theologian, philosopher, and pastor Francis A. Schaeffer – it’s the title of one of his books. It’s a fair question – especially in an age that considers outrage a virtue. here are, I believe, some truths:

Offense can be intended.
Offense can be unintended.
Regardless of the motive of the offender, offense must be taken in order for the offended to be, well, offended.

I believe motive counts.

Does motive excuse the offender then? Not completely, in my opinion. That said, unintended offense deserves a more mitigated response than intended offense – again, in my humble opinion.

i write this as someone who has offended others unintentionally.
I write this as someone who has been offended intentionally and unintentionally.

When I have offended others, I most often apologized. I’ve learned the earlier the apology is offered, the better. I’ve failed – sometimes for years – to apologize for some offenses I’ve caused. This is partially due to ignorance on my part – me not realizing until later that I owed someone an apology. Sometimes I’ve just been stubborn (a virtue for an engineer… which is one reason I warn people that I am an engineer…).

I will likely offend people in the future. Offending people is not my goal and certainly not my intention.

I will most likely offend when trying to make a joke – as others have offended me while trying to make a joke. This has happened to me in the past. It’s cost me relationships, both professionally and personally.

In these cases, I bear the loss and I am profoundly sorry.

Please read and understand this: There are principles – and a Person – in which (and in Whom) I believe. I value my faith more than I eschew offense. My weak, flawed, and hypocritical following of Christ will offend a handful of people, some of whom also follow Christ. Knowing this does not deter, defer, or lessen my beliefs or my commitment thereto. If this offends you, you will have to decide how you respond. If my faith offends you, I believe you will have to also respond at least once more in the future. So if my faith offends you, I pray (and I never say or write the words “I pray” without actually praying) that you take care in your current response.

I share more about my faith in the Personal section of the About Andy page.

Peace.

“You Do Not Know What You Are Doing”

Peeves make lousy pets.

Knowing this doesn’t help; I still keep a few pet peeves. One of my pet peeves is this statement, “You don’t know what you are doing.” Why is this a pet peeve? It denies the obvious fact that everyone one of us, everywhere, is still learning.

“My Name is Andy and I Own and Operate a Consulting Company.”

“But Andy, you don’t know how to own or operate a consulting company.” That may or may not be a true statement. What is a truer statement? I may not know everything there is to know about owning and operating a consulting company, but I can learn.

“My Name is Andy and I Built a Software Product.”

“But Andy, you don’t know how to build a software product.” That may or may not be a true statement. What is a truer statement? I may not know everything there is to know about building a software product, but I can learn.

Interesting sidebar: SSIS Catalog Compare is not only the first product I’ve ever written, it’s the first complete application I’ve written in C#.

“My Name is Andy and I Co-Host a Successful Podcast”

“But Andy, you don’t know how to co-host a successful podcast.” That may or may not be a true statement. What is a truer statement? I may not know everything there is to know about co-hosting a successful podcast, but I can learn.

I Can Learn

I know I can learn because I have demonstrated this fact many times over. I proved it last month (at the time of this writing – April 2018 thereafter) when I completed the Microsoft Professional Program for Big Data. I proved it by learning enough C# to write Catalog Compare, Catalog Browser, and Framework Browser.

I promise I am learning more every day about owning and operating Enterprise Data & Analytics and building and managing the software solutions and products that make up the DILM Suite – including  products like SSIS Catalog Compare and the SSIS Framework – and co-hosting Data Driven, with Frank La Vigne (@Tableteer).

“I couldn’t so you shouldn’t.”

What I Know

What is someone truly saying – what do they truly mean – when they say or write someone doesn’t know what they’re doing?

They’re making this statement about themselves: “I couldn’t so you shouldn’t.”

No one brings this point home better than Grant Cardone in his book (get the audio book – you are welcome), Be Obsessed or Be Average, or #BOBA. The followup to his (awesome) book, The 10X Rule, Be Obsessed or Be Average complements and completes Cardone’s thoughts on the hard work and time required to achieve success.

“What is the Point, Andy?”

When people make statements like “You don’t know what you are doing,” they are saying, “I gave up so you should give up, too,” or, “I didn’t get what I wanted so you don’t deserve what you want, either.”

This is very fair thinking.

When I write the word “fair” I shudder at what “fair” has come to mean and how it’s been used to justify junk and the crap it’s been used to rationalize.

Conclusion

I am not going to quit learning.
I will continue to try to make old things work better.
I will continue to try new things.
I will fail more often than I succeed (this is how I learn).
I will not stop until I go home.

My advice, encouragement, exhortation:

  • Don’t quit.
  • Make the problems give up before you do.
  • Listen to people who have succeeded (or are succeeding).
  • Do not listen to people who have given up.

I have more to learn and I know that.

Peace,
Andy

Experience Matters

This is a picture of Kent Bradshaw, Microsoft Certified Data Scientist. Kent and I work together at Enterprise Data & Analytics delivering data engineering, business intelligence, and data-based solutions that help businesses turn their data into actionable information. We do not do this alone, we are surrounded by an excellent team that holds diverse skills, perspectives, and work and life experience.

In this post I want to focus on experience because I believe experience is the most valuable component a consultant brings to a customer.

When Experience Hurts

Experience can hurt if we allow it. We can become locked into that’s-the-way-it’s-done syndrome. There are new frameworks and methodologies introduced every day (literally). It’s too much for any one person to keep up with the latest and greatest and most shiny new stuff.

This is why a team delivers value to customers.

A diverse team – like the team at Enterprise Data & Analytics – is incredibly valuable. We’re not just a bunch of old guys, we are also Millennials. Our younger team members are constantly learning about new technologies and methodologies and bringing them the attention of our older team members. The energy our younger team members bring to our projects is inspiring and amazing, and…

One of the most rewarding parts of my job as Chief Data Engineer is watching our younger folks thrive, grow, and succeed.

I love how our team works together! I love it when we all pile on WebEx to solve a problem for a customer or design part of a data warehouse solution. It’s thrilling! I’m proud beyond words of our team.

Although we haven’t advertised it much, the team at Enterprise Data & Analytics has grown – nearly doubling in 2018 (so far).

Diversity in backgrounds, experiences, and levels of experience helps us overcome the downsides of experience.

When Experience Helps

Kent and I (and others on the Enterprise Data & Analytics team) have delivered many data-related solutions. I like to joke and say, “when we started working with data we had to carve our own chips out of wood!” That’s not entirely accurate, but I learned Motorola 6800 machine code in 1975 (I was 11) and Kent started when punch cards were the norm.

Having lots of experience gives Kent and me perspective. We understand the maturity cycles of technological, corporate-cultural, and even projects. Why? We’ve experienced a number of said cycles. When the inevitable “bumps in the road” occur, we don’t panic or lose perspective. We’ve likely experienced something very similar in the past, made mistakes attempting to recover, and learned the best way forward from those mistakes.

Do we still make mistakes? Yep. But fewer, and we have a deeper, richer well from which to draw experience-based, time-tested solutions. Perhaps most important to our customers, we have the confidence that only comes from recovering from a mistake (or several).

Plus, our more experienced team members have the privilege and honor of sharing our experience with our younger team members. Together, we learn from each other. I love that!

Our more experienced team members bring leadership and management experience to bear on each and every Enterprise Data & Analytics project. My experience leading a team of 40 ETL developers at Unisys gives me a deeper appreciation for the total cost of ownership of any solution (which can dwarf the cost of development – especially short-sighted development).

Snapping It Together

With our diverse backgrounds, experiences, and levels of experience, Enterprise Data & Analytics is able to deliver the best solutions, period.

How may our team serve you? We offer:

  • Data Warehouse Rescue – is your data warehouse project stalled? We can help.
  • SQL Server and MySQL database performance tuning, development, and support – both on-premises and in the cloud (AWS and Azure).
  • SSIS (SQL Server Integration Services) coaching, development, performance tuning, and training.
  • Biml (Business Intelligence Markup Language) coaching, development, and training.
    • Coaching is my favorite! We navigate and you fly.
  • Data science to help you visualize your data, and data engineering to prepare your data for data science and business intelligence.
  • Automation solutions including SSIS Catalog Compare, Catalog Browser, SSIS Framework Community Edition, the BimlExpress Metadata Framework, and more!
  • Our team writes the books others read to learn SSIS.

Contact us today for more information.

:{>

Why I Love PB

Why do I love personal best? It’s the best kind of competing, competition with past-Andy.

I want present-Andy to do more and be better every day. A mentor once described this as, “Strive to suck less each day.” I can identify with that sentiment! I prefer the positive motivation I get from measuring things like weight, steps, diet, exercise, and other health parameters (blood sugar, for me) with SMART goals applied.

I measure things like days-in-a-row I didn’t cheat on my diet. While this is particularly depressing when the number drops to 0, building that number back up to the previous personal best is powerful motivation to not cheat. This kind of goal provides both negative and positive reinforcement.

I can measure the results of remaining on my diet in other ways, too:

  • My blood sugar returns to normal.
  • I lose weight.
  • I feel better.
  • And – surprise benefit from the keto diet – I’m less tired.

There are things beyond my control and SMART goals help me recognize this fact of life. For example, I cannot change the fact that I am aging at a rate of 1 s/s (1 second per second). But I can change what I do with each second. I don’t always get it right. But that’s a key part of a philosophy of personal best: It’s no longer about a Boolean outcome, right (achieving a single metric) or wrong (missing that metric in any of a thousand different ways), it’s simply about improving over the past personal best. Does a single metric goal exist? Heck yeah! But that goal is now seen as a milestone on a trek of never-ending personal bests.

Each personal best is a win. Each personal best is cause for celebration. You can achieve a personal best today, I know you can!

Do it.

:{>

I Want a Pony

Years ago, I emailed the Microsoft SSIS Developer Team with a request. It’s a long story. The short version is: there’s a bug in the way the SSIS runtime applies package configurations and this bug violates a principle of computing (the command line always wins). I should blog about it…

In the email, I included a request for a pony. Matt Masson (Twitter) replied with this image attached to his email and a note stating, “You cannot have a pony.”

Funny guy, that Matt.

We All Want a Pony

At one time or another I believe we all want a pony – especially when it comes to software projects. What do I mean? Well, it requires some background:

The Expectations Gap

Andy’s First Rule of Projects is:

In every project, be it internal or hired out to consultants or sent offshore; gaps exist in the expectations of the customer, the end-users, and the developers.

Andy’s First Rule of Projects (A1RP) is addressed by one and only one remedy: communication.

There is no way, in my humble opinion, to eliminate the A1RP gap. The best we can hope and strive for is to minimize the A1RP gap by communicating more and more effectively.

Communicating more is pretty easy to figure out.

Communicating more effectively, though? That’s hard and best described with an anti-pattern. I can hear you thinking, “What’s one anti-pattern of effective communications, Andy?” I’m glad you asked!

In It To Win It

We all like to win. As I type this, the 2018 Winter Olympics is happening in PyeongChang, South Korea. Athletes from all around the world have gathered after training for years. You better believe they want to win! In sports competitions, winning is the goal.

Sports contests are short term activities. As I wrote in Coopetition:

The idea is to do “whatever it takes to win” the contest. Rules exist to be stretched and circumvented. Vote early and often. Coerce the panel. Stack the deck. Winning is the most important thing.

Don’t believe me? Ask the Russian Olympic team.

In business this thinking manifests in negotiators who do not feel they’ve “won” unless the other side “loses.” I’ve been working in this field now for decades. I’ve been a manager in a large company. I’ve been a contractor. I’ve been a consultant. I’ve hired and fired, and been hired and fired. I’ve been on projects that were spectacular successes and projects that failed. I am here to testify:

I’ve never seen this kind of “winner” “win.”

Not even by their own standards. It. Just. Never. Happens. Without exception, I see these “winners” move on. They blame anyone and everyone for the failure of the project. They wag their tongues, spin the facts, and toss hard-working folks under the bus.

Not only do they not win – no one wins.

Thousands – millions, sometimes – is written off as a sunk cost. It’s a tragedy. It’s wasteful. And it’s a durn shame.

People and companies compete in business. What’s the best way to compete? Effective software projects require longer-term thinking and planning, and should strive to meet longer-term goals. Instead of fighting to win, we should…

Fight Well

Instead of doing whatever it takes to win, act according to principles.

“What’s the difference between fighting to win and fighting well, Andy?” I’m glad you asked. It’s pretty simple: Instead of doing whatever it takes to win, act according to principles. Many act according to preferences instead of principles today. We see it frequently in politics. A politician will give a speech against some behavior or political activity today and tomorrow the same politician will advocate for the same behavior or activity. We call that hypocrisy for good reason; it is hypocritical.

Fighting well means maintaining your integrity.

It is the lie of situational ethics – most often expressed as “for the greater good.” Situational ethics aren’t fighting well, they’re fighting to win. Ethics – sans “situational” – are fighting well. Here’s a good test of whether you’re fighting well or to win:

In a given situation, if your opponent lacks some information that would strengthen their position or argument – information which you posses, which may or may not weaken your position or argument – do you share that information or withhold it?

If you withhold such information I will not call you a liar (although I believe omitting the truth is lying). I will also not call you a truth-teller or refer to you as “a person of integrity.”

Fighting well means I sometimes lose.
Fighting well means I never lose my integrity.

Fighting well means maintaining your integrity. Some business examples may help:

  • If I hire a subcontractor and agree to pay them for 20 hours of labor on a deliverable I know will consume 200 hours or their time, I am not being a person of integrity.
  • If I overbid a contract, I am not being a person of integrity.
  • If my demonstrated goal is anything other than delivering maximum value to my client, I am not being a person of integrity.

Fighting well means I sometimes lose.
Fighting well means I never lose my integrity.

Conclusion

Ponies are expensive and require support and maintenance and care and feeding.

As someone procuring business intelligence consulting or training services, I recommend you buy products and services rather than be sold products and services. One way to tell the difference? A vendor fighting well, protecting everyone’s best interests, whose goal is wins all around, will sometimes demolish your expectations by telling you, “No pony for you.”

Dashing your expectations, based upon their experience and expertise, is the consultant delivering free consulting to you, which makes said consulting of infinite value.

The Second-Best Time

I recently returned from the PASS Summit 2017 where I had an awesome time hanging out with members of the SQL Server Community, learning, and presenting. Attending a conference inspires a bunch of ideas. If you’re like me,  you might kick yourself and think, “Why didn’t I think of that sooner?!”

If I had a time machine, I’d go back and share some thoughts with Younger Andy (lots of thoughts!). Alas, I don’t have a time machine. But I’ve learned this advice from others and I find it to be true:

The best time to do something may have been years ago. The second-best time is right now.

My Advice

I follow a two-step process:

  1. Take notes at conferences. Email yourself or write stuff down. Whatever works for you.
  2. Complete those items when you return home.

That’s it. When you realize something needs to be done, record it for posterity. Then do it. Get it done. Ship. Results, not excuses.

A question to consider: What are you doing, right now?

:{>

Lessons Learned About Community Leadership

It’s been an honor and a privilege to serve in technical community leadership at the local (Richmond Virginia) and regional level. It’s not the same as managing geeks, but there are similarities.

I’ve considered serving on a national level but not taken that plunge. Over the years I’ve learned some lessons that I thought I’d share. I believe some of this stuff applies to everyone at all times, not just leaders when they are leading. In no particular order I offer the following:

  1. Serve the people you lead. As often as possible, do the non-glamorous parts of the job. Show up early. Stay late. Clean up. Take out the trash. Strive to help. Always.
  2. Love the people you serve.
  3. Engage in Active Humility. Respond to compliments by reminding folks you’re part of a team. Mean that when you say it. Be an example of service and love. Never believe your publicity or trust in popularity.
  4. Listen to the Community. Prove you’re listening by implementing some of their suggestions. Give credit to those who made the suggestions.
  5. Own your mistakes. Apologize when you’re wrong. Apologize when you’re right but you offended someone. There’s no statute of limitations on apologies because there is no statute of limitations on hurt feelings. I was reminded of this when I apologized for something I did years ago. The first response was, “Well that was a long time ago,” which was accurate. But then this person shared details… it turns out it wasn’t too long ago after all. I share this not as criticism but as proof. It stinks to get hurt. It stinks more to not receive an apology.
  6. Empower and enable others. Leaders multiply leaders. Community leadership takes a village. Assume a team with members leaving and joining is the norm because, well, it is.
  7. Cherish the opportunity to lead. Like all things, this too shall pass. You will miss leading when you’re done.

:{>