Where Does Your Allegiance Lie?
In addition to being passionate about software development, I’m interested in, among other things, world politics, as well as economic affairs. When I recently came across Dealing with China: An Insider Unmasks the New Economic Superpower by Henry “Hank” Merritt Paulson, Jr., a former CEO of Goldman Sachs and later U.S. Treasury Secretary, I bought it on a whim and started reading it immediately.
I have found it reasonably insightful and engaging (as of this writing, I haven’t finished it), but I don’t intend to attempt to sell it to you here, nor do I want to review it. I’m bringing it up because of one specific episode in it, a relatively insignificant one (for the overall narrative), that made me think about situations that software developers (as well as other professionals) face, perhaps not on a daily basis, but still relatively frequently.
Note: I would like to assure all those with strong opinions on Mr. Paulson as a politician and businessman, whether negative or positive, that I really want this article to remain completely apolitical. The book is a memoir written by a man with a lot of experience, both as a senior executive of one of the world’s largest investment banks and later a high-ranking United States politician, and, as such, it sparked my interest, irrespective of what I or anyone else may think of the author. The truth is that my view of Mr. Paulson is completely neutral.
When you know your client is wrong…
China first started opening up its economy to the outside world in the late 1970s under the leadership of Deng Xiaoping, but they really put the pedal to the metal in the mid-to-late 1990s, around the time of “the Handover”, the transfer of sovereignty over Hong Kong from the United Kingdom. As a senior representative of Goldman Sachs, Mr. Paulson had the opportunity to do a lot of business with and in the country back then.
Apart from many other activities, the investment banking company underwrote the initial public offerings of several Chinese state-owned enterprises. One of them was Bank of China (Hong Kong), which is where we finally get to the situation I mention above. (See pages 147-153 in the book.)
To make a long story short, the gist of the dilemma consisted in the fact that Mr. Paulson thought the listing (of the bank’s stock) should be made both on the Hong Kong Stock Exchange and the New York Stock Exchange, whereas the Chinese officials wanted to, initially, do it in Hong Kong only. He believed it was his professional responsibility to insist on what he considered the best solution, even if his client opposed him. However, being adamant posed a serious risk of losing the business…
Is it just me, or is this reminiscent of situations that many professionals, including software developers, face on a regular basis? Has your client or boss ever pushed you to do something you knew wasn’t right? Did it, by any chance, make you feel like you were stuck between the devil and the deep blue sea? Doing what you were told meant abandoning your professional standards, but not doing it could involve getting fired or some other undesirable consequences.
So what did Brian Boi… I mean, Mr. Paulson do? Stay tuned…
Unhealthy health care
In episode 934 of .NET Rocks, Carl Franklin, Richard Campbell, and Uncle Bob Martin discuss the debacle that was the development of the HealthCare.gov website. (The site was basically unusable for the first couple of weeks after its launch in October 2013.) They conclude that although systemic problems were to blame to a great extent, some senior software person should definitely have “blown the whistle” when they knew that an unfinished (and inferior) product was about to be launched. In other words, the developers who worked on the system, in their view, share a big chunk of responsibility for the failure.
They go on to talk about professional ethics, regulation and self-regulation, as well as what they believe it would take for our field to become a more mature, “real” profession. The one point they all seem to agree on in the end is that, as professionals, we are responsible to our industry first and our clients second.
I’ll take the liberty here to speculate a little, and I’ll claim that if they were to give guidance to Mr. Paulson, they would advise him to stand his ground and insist on doing it “the right way”… or so it would seem at first glance, at least…
Don’t you dare call yourself an engineer!
I have my own little story to share. Several years ago, I worked on a relatively complex project that involved the development of a software solution to ensure the synchronization of data in a number of other applications. The business set a deadline by which everything had to “go live”, without consulting any of the developers. In my view, this deadline was completely arbitrary, and I could see that we needed a few extra weeks. As the informal team lead, I decided to try to negotiate this with the managers.
The conversations I had were… interesting, to say the least. One of the most senior IT people in the company essentially kept repeating that my points had been considered, and that the business had decided to launch regardless. He also claimed I had to understand that this was “a business decision”.
At that point, I countered that in any “normal” profession, you wouldn’t just allow management alone to decide. You don’t let vehicles start crossing a bridge, if the engineer says it’s not finished. You don’t make a pilot take off, if the maintenance team refuses to declare your aircraft airworthy. You don’t force a surgeon to operate on you against their best judgement, simply because you’re footing the bill.
I found it ironic and somewhat amusing, as I recalled a conversation I had with this manager and some other members of the team a couple of weeks prior to this, in which he talked about an article he’d read that slammed software developers as sloppy and concluded that we had no right to call ourselves engineers. I never did call myself an engineer, but now I felt like in this case it wasn’t exactly my choice to be neglectful.
In the end, the business decided to heed my advice, possibly acknowledging that the deadline had existed for no good reason in the first place, they gave us a couple of extra weeks, and the project turned out very successful. (Hey, don’t you ever like to brag?) Looking back, however, I can’t help but wonder what I would have done had they not exhibited this level of sensibility. Would I have refused to cooperate? Would I have quit over this? What other options were there for me to consider?
Time to jump off the cliff
Let’s revisit the cliffhanger I introduced earlier. How did Mr. Paulson resolve his dilemma? In a nutshell, he chose pragmatism. He came to believe that if he refused to compromise, the Chinese wouldn’t award the contract to Goldman Sachs. Although some may find this disappointing, I think his reasoning is very interesting. This is what he had to say (see pages 150-151; by the way, we could spend hours debating whether the author has a genuine point, or whether he’s just rationalizing a bad decision; I’d rather leave this to him and his conscience):
…I’d stand on principle all day if that meant opposing something that was immoral, illegal, bad for investors, or not right for the client. But that wasn’t the case here. The judgment we had to make was this: Are the Chinese going to make this a successful deal? Is it basically a clean company? Are they honorable people?
I’m 100% behind the idea of being “responsible to our industry first and our clients second”. However, I also believe that different circumstances may warrant vastly different manifestations of this principle. When facing professional ethics dilemmas, I believe you can start by asking some questions. For example: If the suboptimal solution is adopted, will… (The list obviously isn’t exhaustive.)
- …someone’s life and/or safety be in jeopardy?
- …third party property be at risk of being damaged and/or destroyed?
- …your client’s customers suffer financially or otherwise?
- …your client’s investors incur losses?
- …your client’s employees lose their jobs?
- …the project fail?
- …the project succeed, but not realize its full potential?
Mr. Paulson believed his clients would still be able to “make a successful deal”, albeit less successful than they would if they adopted his solution. (Or so he claims, and, for the sake of argument, at least, let’s give him the benefit of the doubt, shall we?) I think I would agree with his decision. He did the right thing by explaining to his customers, in no ambiguous terms, what he considered the best course of action. I also believe he did not “sell out” or do anything immoral by choosing not to be obstinate at all cost.
My situation was a little bit more complicated. I actually thought the project would fail. However, no one’s life was certainly at stake, no one would, to the best of my knowledge, lose their job, and my client was a privately held company with one owner: She alone would incur losses. In light of these facts, I probably would have tried to escalate my concerns as “high” as possible, but, honestly, I most likely would have left it at that.
To get back to the “responsibility to the industry first” idea: If you’re dealing with a life-critical system, you should definitely do whatever it takes to prevent your client from launching an inferior product. If your client’s money is the only thing at stake, expressing your opinion very vocally may be all you have to do to honor the principle. You will need to exercise judgement.
Beyond ethics
The latter point – about having to exercise judgement – is important, and it transcends the ethics debate; it applies, in my opinion, to “professionalism” in general. I love best practices, for example. However, I don’t believe they’re all equally useful in all circumstances. We have to pick and choose. In addition, their implementations may vary significantly from situation to situation, context to context. There really is no way around the “consultant’s answer”: It depends.
I feel that, at times, some arguably exceptional software developers become so passionate about an idea, practice, or technique that they don’t see its potential limitations. For instance, Eric Smith, a developer with 8th Light, writes in one of his blog posts:
We practice Test Driven Development and it’s not negotiable. If you want to “save time” by eliminating this, you’ll get a straightforward answer. No.
Although the article is part of 8th Light’s “We Are Principled” series, I don’t find this attitude of “nonnegotiable” insistence on the unconditional use of one specific technique particularly professional. In fact, I think someone may have slightly misunderstood the meaning of the word ‘principle’ here :-)
As software developers, we’re being paid to think. Think is what we should do.