As a consultant, I get calls to complete projects started by someone else or extend projects completed by someone else. When I look at someone else’s work it’s sometimes tempting to say, "Wow – they did that wrong." But I don’t. Instead I say, "I’m not sure why they built it this way." That may sound back-handed but I make sure it’s not by asking follow-up questions. Which questions? My favorite is, "What was the problem they were trying to solve?" It’s entirely possible my predecessor delivered precisely what he was asked to deliver. Plus software projects evolve (especially elegant software projects). If software solves a problem it’s common for "new" problems to come into focus.
We speak about this in terms like "long pole," the subject of this article by Raymond Chen, gifted thinker and author of The Old New Thing (which, I am embarrassed to admit, just found it’s way onto my Kindle). If I’m taking down a tent, I may decide to take down the tallest (longest) pole first. That makes the tent noticeably shorter and provides clear evidence to onlookers that I’m doing my job (aka “highly visible”). But then, *another* pole becomes the long pole. And the cycle repeats.
Some things to keep in mind before criticizing:
-
Delivering software is a collaboration between the service provider and the customer. It’s never 50/50%. There’s always imbalance even if it’s as little as 49/51% – and this applies to success as well as failure. If you criticize – especially early-on – you may be speaking to the person on the 51% side of a failure. You may be unwittingly feeding the beast with all new criticisms, which leads to my next consideration…
-
If I criticize the work of others, I am priming my customer to criticize the next bit of work she sees. Who’s on deck? Me and my work.
-
“But what if the person before me did something truly horrible, Andy?” That’s a fair question and I have a question for you, “Are you aware of 100% of the factors that went into the decisions made by your predecessor?” I’m certain the answer is “no.” Are you aware of 50%? Again, no. At best, you’re speaking to one side of an incomplete project. You will most likely have no opportunity to speak with your predecessor and the person with whom you are speaking is not going to tell you all of their side. You’re not going to get even half of the story! Now, your predecessor could have delivered something dangerous, illegal, insecure, of poor quality, not up to modern standards and best practices, or merely a solution of which you do not approve. They could well and truly be 100% to blame. Your customer may indicate that they want you to disparage the work of your predecessor. I advise you to resist the temptation to do so. Again, my advice is to fall back to “I don’t understand why they built it this way,” or (perhaps), “Based on what I’ve heard today, I would have designed this differently,” or, “I would have delivered the solution so that ______.” Why? Because you don’t know the other side of the story.
Maybe I’m wrong about this. Maybe you’ve built a reputation as an expert by disparaging the work of others thinking that you will get all of the work and everyone will think you’re a rock star. Maybe. Or maybe John Nash and I are right about coopetition, and there’s more work out there than you can handle alone and that you have, unwittingly, introduced errors into your deliverables and primed your customers to criticize the mistakes of consultants. (Even you.)
Time will tell.
Peace.
:{>
Learn More:
SSIS Design Patterns and Biml: A Day of Intelligent Data Integration – Boston SQL Saturday precon, 24 Feb 2017
Save Time and Improve SSIS Quality with Biml
An Example of Data Integration Lifecycle Management with SSIS, Part 4
The Recordings for SSIS Academy: Using the SSIS Catalog are Available
SSIS Catalog Compare v2.0 Launch Event 7 Mar 2017!
Related Training:
IESSIS1: Immersion Event on Learning SQL Server Integration Services – April 2017, Chicago
IESSIS2: Immersion Event on Advanced Integration Services – Oct 2017, Chicago
From Zero to Biml – 19-22 Jun 2017, London
What about this instead of “I’m not sure…” To avoid what some may take as a backhanded comment:
“I need context to understand what they’ve built,” before continuing with, “What problem were they trying to solve?”
That’s a good tactic, too, Mr. Kelley.
:{>