Erik on Software

Counterpoint: "Trojan Horse Consultants"

 

My first counterpoint blog post here, on a recent article entitled "A doctor's note for virulent consultants", provided a point-by-point rebuttle of why the author's arguments fall flat in the face of reality. In the words of the author, consultants are like viruses because viruses cannot exist alone, viruses can mutate into different strains, viruses multiply, all living things are susceptible to viruses, and viruses endure.

In demonstrating why these arguments fall flat, I actually used his words against him, and argued that consultants may be like viruses, but not for the reasons he mentioned. And now this cartoon appears with a single sentence in its caption. And a thousand words in the form of a graphic. Where are most of these additional words to be found? The fortress or the wooden horse?

In an essay on the virtues of consulting, one might say that these additional words are to be found in the fortress, concentrating on faulty clients. In contrast, one might say that consultancies are not needed, and pose hazards to organizational health. And so these additional words might be found in the wooden horse. But perhaps the unspoken might be found in the backdrop environment of both the fortress and the wooden horse.

And who pulled the rope affixed to the wooden horse? Was it someone who has since departed? Was it someone who has since hidden in the wooden horse? Or was it someone inside the fortress? And will the door to the fortress actually fit the wooden horse? Or will the inhabitants of the fortress need to accomodate for its size?

Asking questions that lead to results is part of my job as a consultant. An inadequate amount of good questions is what tends to quickly lead to inaccurate assumptions. Of course, in this case I am asking rhetorical questions because this blog post is not a two-way dialogue unless readers post comments. One of the questions that remains in this discussion is "Why is negativity seemingly directed at consultants?" Or asked in a different way, "Is the negativity on display really directed at consultants?"

The assumption here is that the message being communicated is negative because of the reluctancy implied by the castle guard. And of course, the Trojan Horse was the avenue by which the Greeks entered the uninviting city of Troy. By his statement, the castle guard is seemingly familiar with this story, with the contents of the wooden horse at the gate a known unknown.

In the context of business, however, the castle guard can represent any within a host of corporate individuals, and the fact that they are wary implies that they have had past, negative experiences with consultants. Unfortunately, such experiences can happen. Even if these are far between, isolated incidents can obviously have an enduring effect on the part of an executive or individual contributor.

There are various reasons for such negative experiences, and I would like to think that the vast majority of experiences my clients have had with me as a consultant have been positive. The Sixth Law of Pricing in Gerald M. Weinberg's "The Secrets of Consulting: A Guide to Giving & Getting Advice Successfully" says "If they don't like your work, don't take their money", and even though I have not been at liberty to make such a call, the philosophy is compelling.

Most of the unsuccessful consulting engagement scenarios I have witnessed were the result of strong human elements. There is a reason why the cartoon included here includes only human elements, and not the actual problem to be solved. It has been rare when technology was at issue, even though technology tends to continually come up in conversation surrounding these issues. Human factors involve both consultants and clients, and even though the industry tends to focus on communication between these two elements, it can be common within each of these elements as well.

One individual at a client with whom I engaged a couple years ago expressed that expectations of client management had changed once the presence of my colleagues and I had arrived. Essentially, what they had communicated was that they felt management had taken an about-face and that regardless of what they had been asked to do in the past, they saw the new direction being taken as some type of discipline they had to endure.

Of course, this was not the case at all. While I have certainly witnessed consultants who do not know what they are doing, the history of consulting demonstrates that the industry has evolved over time to the point where consulting firms are the knowledge bearers that travel between clients to help solve business problems using best practices that they have assembled over time for which clients are sometimes not equipped.

Unbeknownst to many, modern organizational structure itself is a product of consulting firms. So if viewed from a system perspective, the 80% that research has shown is needed for maintenance of a system is just as important as the 20% of resources dedicated to its initial construction. Client firms run their businesses, and the intended purpose of consulting firms is to step in along the way. But if your firm has a castle guard such as the one depicted in this cartoon, do not simply ignore their hesitation. A corporation is a team, and all input is important.

---

Counterpoint: "A doctor's note for virulent consultants"

Counterpoint: Defining Big Data

Counterpoint: "20 Questions to Detect Fake Data Scientists"

New Book Review: "Team Geek"

New book review forTeam Geek: A Software Developer's Guide to Working Well with Others, by Brian W. Fitzpatrick and Ben Collins-Sussman, O'Reilly, 2012, reposted here:

Arguably the best text on the software development process that focuses on the individual contributor within the context of a team. When I initially discovered this text, I was wary whether it would have anything to offer, and if so, whether it would cater to new development staff or seasoned professionals, but after a reading I am convinced that Fitzpatrick and Collins-Sussman have something to offer regardless of technical career stage, and even offer significant insights to managers who are willing to learn.

After discussing the myth of the genius software developer, the authors present their thoughts on a healthy team culture, followed by discussions on effective team leadership, working with difficult people, using organizational manipulation to get things done effectively, and user engagement. At first glance, the discussion on user engagement might seem out of place, but my consulting experience has shown that this aspect of the software development process is important, and the authors tie it in very well.

The best part of this text is that Fitzpatrick and Collins-Sussman, both at Google at the time of writing this book (they have worked with each other at three jobs, and also written three books together), simply tell it like it is, and offer no fluff. Some of the topics that the authors touch are not really found anywhere else to any significant degree, and I hope that a signficant portion of the software development profession has a chance to read what they have to offer at some point in the near future.

Judging by the number and distribution of dog ears resultant from my reading of this text, the strength of the content is consistent throughout, unlike many other texts in this genre which tend to offer good content up-front, but then taper off over the course of the second half. While the reward for this quality will result in this book sitting alongside the best of the best on my bookshelf, it also adds difficulty to the review process, because I do not have the space for a "The New Yorker" magazine review here, so I offer a few quotes that will hopefully increase potential reader interest.

In Chapter 1 ("The Myth of the Genius Programmer"), the authors recount their speaking engagements over the past six years, and point out the distinctive trend in the types of requests they were getting for Google's open source Project Hosting service, which revolved around hiding specific code branches, hiding new open source projects until they are ready to be seen, and deleting code version history.

"The key motif here is insecurity. People are afraid of others seeing and judging their work in progress. In one sense, it's just a part of human nature - nobody likes to be criticized, especially for things that aren't finished. This attitude tipped us off to a trend within software development. Insecurity is actually the symptom of a larger problem." The resultant discussion then leads to their presentation on the foundation that all healthy interaction and collaboration is based (humility, respect, and trust), and point out the following important maxim: "Don't equate your self-worth with your code quality."

In Chapter 2 ("Building an Awesome Team Culture"), the authors discuss an important aspect that is all too often ignored in books of this genre: team culture. "Calm, easygoing cultures built on respect are more vulnerable to disruption by aggressive people than aggressive cultures are vulnerable to disruption from more easygoing people. Easygoing cultures need to be aware of this and not let the aggressive newcomer take over, typically by refusing to engage this person in an aggressive tone. In some cases, one or more of the more senior team members may have to meet the aggressive newcomer head-on to prevent her from harming an easygoing team culture."

In their discussion of the team leader in Chapter 3 ("Every Boat Needs a Captain"), the authors address risk in their presentation of team leader as catalyst. "Risk is a fascinating thing - most humans are terrible at evaluating risk, and most companies try to avoid risk at all costs. As a result of this, the usual modus operandi is to work conservatively and focus on smaller successes even when taking a bigger risk might mean exponentially greater success."

"One thing we often say at Google is that if you try to achieve an impossible goal, there's a good chance you'll fail, but if you fail trying to achive the impossible, you'll most likely accomplish way more than you would have accomplished had you merely attempted something you knew you could complete. A good way to build a culture where risk taking is accepted is to let your team know it's OK to fail."

Chapter 5 ("The Art of Organizational Manipulation") contains one of the many important take-aways from this book. "As an engineer, try to focus your energies on launching products over just about everything else. Shipping things gives you credibility, reputation, and political capital more than just about anything else in a company. Launching your product is a high-visibility event that shows you've accomplished something."

"As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled."