My Pen Is My Tongue

A few days back I sent out a series of tweets about "self-documenting code". Self-documenting code is an idea that's been around for many years, like stories about the wee folk...and like the wee folk, no one has seen self-documenting code.

The short version of the tweet series is that if you're writing code, you should be writing documentation as well - it's really too important to skip. This post, however, is not really about self-documenting code, but rather about how to write documentation, and more specifically a certain piece of documentation that you should never neglect.

---

I entered the whole techno-geek world at a time when computer labs were a real thing. Punchcards and shelves full of binders stuffed with documentation were commonplace. Documentation isn't like that anymore. When Java came along, I was almost enthused to use JavaDoc because of the level of clarity it added when writing the documentation. Now that nearly all code written by large, technologically advanced firms is either in Java or JavaScript (or ECMAScript), JavaDoc and JsDoc are - or should be - the de facto standard.

There is seldom serious argument against using one of these two tools anymore. There is disagreement about how the tools should be used, however. In the JsDoc community, one of the points of contention is the @author tag. To be clear, the JsDoc tool authors have stopped using the author tag and no 'contributor' tag has been added. It might seem, from their use (or non-use) that these tags are unimportant, and in fact, that is a common perception, especially in light of the advances in source code management, or what we used to call "version control".

However, not only should you use the authorship tag(s), you should be encouraging everyone else to use them as well.

It would come as a surprise to no one if I reminded you that we write code to solve problems. Not only are we writing code to solve problems, we're writing code to solve complex problems. For example, no one would write code to add two numbers...doing simple calculations on large data sets, perhaps, but there is a "complexity bar", below which we wouldn't dream of using code to address a problem. The first step of writing code is understanding the problem you're trying to solve.

As a hypothetical example, let's assume you've inherited a project. You've read the documentation that describes the solution to the problem the code offers, but after getting a small understanding of the problem combined with the solution being used, you have a list of questions. Why was this particular solution chosen over other solutions, for example. You can make some assumptions, but wouldn't it be nice to be able to contact the author to ask for their insight? Code, even well-documented code, is only a partial story. Just like every fan of a book turned into a motion picture knows, even faithful adaptations leave out bits that someone thought important. The first reason to include authorship information in your documentation, then, is the abundance of information it can point you to.

The common response to this concept is that the authorship information is not needed in the documentation because source control software, like git (my personal favorite), can track that information and expose it through tools like blame.

This response, however, misses the purpose of such tools. Version control is tied to a specific change...in git parlance, a commit. Yes, you can look at a particular line and see the last change of that line - the author of that change - but that is qualitatively different information than the author of a solution...and that information is generally only the last change. In order to get authorship information you must follow changes to a specific line back through history, and if at any point history was squashed or rewritten, that information is gone. Version control tools are excellent at solving the problem the author intended them to solve, as the author understood the problem; do not expect another author's code to solve a problem as you understand it.

Another reason authorship is important is we, as an industry...and really we as the human race...have difficult acknowledging the contributions of women and persons of color. The list of women who have significantly contributed in STEM fields without attribution is long...far too long. Not including attribution participates in that system of oppression by reinforcing the status quo. If we want to have any hope of disrupting patterns of discrimination, patterns that have existed for millennia, we must combat it at every turn.

A while ago I wrote a post called Visibility and Obscurity that described a situation in which attribution was changed on work I had done. In academia this is typically called plagiarism, and in most instances it's a punishable offense. Even outside academia, claiming to have done something you have not done can have serious consequences - Scott Thompson's resume scandal is evidence of that.

We should be writing code we can release with pride. Build things you're proud of and put your name on it...and give that same consideration to others. Amplify voices that are too often silenced or ignored - it does not diminish your contribution and it makes a difference. If it only makes a difference to the woman or person of color who finally has their contribution recognized - that's enough. If the only people who see an authorship reference are your employees, your colleagues, that's enough - they are important too.

Happy coding.

The Right Answer

Several years ago – in the late 1980s – I was in a graduate MIS class and the professor posed a question to which he made clear there were multiple answers. After a class discussion the professor brought up the answer he considered to be the right answer. (If you haven't read the problem and answer in the sidebar, do so now.) As I've recalled this event, I've been reminded of a few things, and I've tried to determine what the greater lesson has been over the years.

Problem: You have hired a worker who is to be paid 1 inch of gold each day. You have a single bar of gold that is 6 inches and can only cut it twice. Where do you make the cuts to pay the worker exactly the amount they have earned each day - what size are the three resulting bars?

Answer: Cut the bar at 1 inch from one end and 3 inches from the other end, resulting in 3 bars that are 1 inch, 2 inches, and 3 inches. Pay is as follows: Day 1 - the 1" bar; Day 2 - the 2" bar and receive the 1" bar back; Day 3 - the 3" bar and receive the 2" bar back; Day 4 - the 1" bar; Day 5 - the 2" bar and receive the 1" bar back; Day 6 - the 1" bar.

One of the most important lessons I learned in that experience is that there are typically several answers to a problem and they have varying degrees of difficulty, precision, and accuracy. Sometimes choosing the answer is easy – other times it would seem it is not. For example, if we're choosing which compression algorithm to use, we can relatively easily make the determination based upon whether we want to prioritize speed or the compression ratio; however, if we're trying to balance time-to-market, performance, quality, and user experience the answers are not so easily reached. In real-world scenarios, we may suggest to our hypothetical employer that they fold the gold bar 5 times and make the two cuts at the ends – that answer maintains time-to-market and improves the user experience (the worker has immediate full use of everything they receive), but is that the right answer?

Any time we find ourselves asking if an answer is the right answer, we must look beyond the surface of any potential decisions and ask what we would actually be doing – in language terms, what is the connotation of this conversation rather than just what is the denotation. Phrased another way – what are the patterns we are introducing intentionally and what patterns are we introducing unintentionally? Are we just doing what is good for our organization or are we promoting a greater good or are our customers (or users) seeing the benefit?

In the world of software development, managers and business leaders have been toying with the development triangle for years, trying to squeeze out the best solutions, and just because we're now dealing with web-based applications instead of desktop-based applications makes little difference. Granted, trying to keep the three legs of the development triangle balanced is difficult – and it's harder for some teams than others (but that discussion will have to wait for another post). It's made still more difficult by the fact that none of us like to have the scope of our project constrained by the balance of these three legs. Unfortunately, what many organizations do is prioritize their wants and needs over the needs of their customer. There certainly are times when this is appropriate – the customer simply cannot always be right – but this happens far too often to be valid, especially among Internet companies where development speed – enhanced by bloated code like bootstrap and jQuery or (even worse) user-agent dependent languages like Angularjs – is prioritized over a user experience that people argue simply must have all the bells and whistles. Leadership in these cases is somewhat like the obstetricians who argue that they must have the machine that goes ping, except in the real-world these cases are not intentionally comedic. As a result, many leaders who have prioritized development over user experience or have tried in vain to balance all the legs of the development triangle and not constrict scope, believe the use of various frameworks are a solution they can leverage, and many have attempted just that – going down the Angular.js rabbit hole, for example – but is that the right answer?

No, it's not the right answer. Is there a better answer? Yes. In fact, I would posit that there is a right answer for web-based development – one that prioritizes users over development – but it's one that few developers like or want to admit, because it's not, as we say, cool. The right answer is Progressive Enhancement. Simply put, Progressive Enhancement starts with HTML, and it should be semantic HTML which must include using the appropriate tags as well as ARIA attributes that make it as readable as possible by both humans and machines (I'm looking you, developers who use <i> instead of <em>, <b> instead of <strong>, and never use ARIA states and properties). After the document is created, it is styled using CSS – again paying attention to accessibility (e.g., using clip instead of display or height to hide content) – and finally, layering unobtrusive JavaScript on top of all the rest in a way that pays attention to performance.

Developing in this manner ensures that users will always be able to access your content – be it informational or commercial – regardless of whether or not someone's user-agent supports CSS3 or whether or not the user-agent supports JavaScript or whether or not anyone is doing something like pushing code live without having tested it and introducing an error as a result or blocking JavaScript (either intentionally or unintentionally – and yes, it has happened when a "parental filter" operated by an ISP in the UK blocked access to jQuery via CDN) or whether or not you're running third-party code that is not up to par.

Of course, one of the arguments that I've heard repeated is that there aren't that many users with JavaScript disabled and Progressive Enhancement takes too long, both to write and when rendering (because JavaScript-based rendering is much faster). So, let me just address those arguments – and let me say that this reasoning is not based on some ephemeral justice-based ideology but on solid experience building web pages. (If you're really curious about my work experience, read "A machine-readable resume", where there is both an image of a portion of my CV and a link to the full version.)

While the actual percentage of users browsing the Internet with JavaScript disabled is low (the number is arguably around 1%), that number does not count all the users affected by stuff that is broken by error-infested, untested code, nor does it count users affected by not having access to specific libraries because their ISP decided those libraries were potentially dangerous.

Neither of those groups take into account people who are using accessibility software for whom an otherwise acceptable web page offers a broken user experience. Granted, most accessibility software works acceptably with JavaScript, but without paying special attention to making your JavaScript-enhanced page accessible, e.g., by using aria-live or shifting focus to updated content, users with accessibility issues are still left with a broken experience. Because of the way in which accessibility software works with user-agents, the user-agents are not technically, potentially JavaScript-disabled in general, but the user experience is.

Yes, the number of users with user-agents that recognize a SCRIPT tag is around 1% – and 1% of nearly 3 billion is still a lot – but there is a significant difference between something potentially running JavaScript and something actually running JavaScript – a difference any philosopher should immediately recognize.

As for pages built using Progressive Enhancement not rendering as fast as those built using client-side rendering, I'm going to just come out and say that cannot possibly be true in anything other than a test that is non-analogous to real-life. I suppose client-side rendering might be faster if you were delivering a page with a lot of duplicated content, but in practice delivering a template, a client-side rendering library, and JSON data is not a much smaller payload because most content isn't duplicated. What we've really done with this approach is break up the content – the most important piece – into separate documents. To add insult to injury, there are issues of network latency for each of those three requests (for content), and potentially disastrous re-flow issues, not associated with CSS, as containers are loaded with HTML.

If you coerce a multiple-page application into a single page by delivering partial in-document updates – the way it was done in PayPal checkout products for example – you may see some actual performance improvements and users may perceive some performance improvements – though neither is guaranteed. However, in the case of in-context updates you have to take special care to make sure your page/app is still playing well with accessibility software or you're not only shutting out users you may be violating the law.

As an aside, adding all the accessibility hooks and building out any inadequacies in the various libraries and then testing all the extra code certainly has the potential to destroy any improvement you may gain by avoiding Progressive Enhancement.

Yes, saying you're improving the development experience (or your engineers' lives) is seen as sexy and cool by the engineers building your products and prioritizing time to market is sexy to those who have invested in your business, but as anyone who has pursued event the earliest steps in an Economics program knows, those words don't necessarily what you think they do – it's what your users think, and on the web it's a mistake to not prioritize the user experience over other things.

Our users may not always be right, but when we're trying to solve their problem, more often than not they have the right answer.

Note: if you'd like to read another's thoughts on a similar topic, Nicolas Bevacqua has a few thoughts, and has prompted a few comments as well.

You will be assimilated

Freedom is irrelevant. Self-determination is irrelevant. You must comply.

Borg Collective

You will be assimilated. Resistance is futile.

Hugh

In "Conversion and Acquisition", I wrote about the inverse relationship between conversion and acquisition, possible causes of the inverse relationship and how it might be fixed. In this (much shorter) post, we're going to look at this same issue from another angle.

Let's assume that you have not implemented a forced acquisition method and you ask yourself "what do I know about my customers" and then ask the same question after you implement a forced acquisition method - will your answer be the same? Unlikely. The motivation and values of repeat customers are likely different than the motivation and values of people who are occasional users. Let's consider the simplest of these differences - repeat customers are have a vested interest, to at least some degree, in your continued operation whereas those who intend to be a single-use visitor are not invested in your business to any degree.

Why is this important? Every day we make assumptions and decisions based on what we know about our users. If our representative sample changes, those assumptions and decisions must also change. There may be simple assumptions about the design of a web page that are incorrect - assumptions that we can address by A/B testing, but what if there are assumptions associated with the risk of a transaction or possible fraud - those are considerably more difficult to test and correct.

In short, the more you rely on knowing your users the more contraindicated a forced acquisition method is.

Oh yeah, it's a bloody evil thing to do, too...just look at the Borg.

Conversion and Acquisition

In the world of ecommerce, there are two terms - conversion¹ and acquisition² - that, in general, are bandied about with little regard for what they mean. Of course, part of the problem is that their meaning is partly contextual, but even so, words have meaning and when you're getting paid to think, part of that is thinking about what we mean and how we're communicating.

"Why", you may ask, "is this discussion important" - and here's the reason. The two terms have very different meanings and without understanding them you cannot be as successful as you would otherwise, because in most cases the two measures have an inverse relationship.

Wait...I sense a great disturbance. It's almost as if the universe cried out "that cannot be so".

When people are buying online - not shopping, but buying - interrupting them will negatively affect whether or not they complete the process, and there are times that even selling will interfere with a purchase. People who have been in the ecommerce game for a while should already recognize this³ but not all do, as is evidenced by the number of sites cross-sell or up-sell or that require a customer to create an account before (or during) paying for their purchase - sites that don't appear match the priorities of the business.

There are a number of reasons that you, as a merchant, may want a customer's information - most of them legitimate; for example, you will need billing information to complete payment and shipping information to fulfill the order (in most cases). Your general need for information, however, ends there - aside from perhaps slightly more information regarding the individual(s) purchasing and receiving the goods to verify that the transaction conforms to laws those which those individuals are subject.

I do not question whether or not it will be in the customer's best interest to create an account with you - you can store billing information as well as shipping information and purchase history - all of which is, clearly, a benefit to the customer. However, the data is clear - forcing a potential customer to create an account will lower your conversion rate - and if you are using a payment gateway⁴, if they force your customer to create an account - even if you do not - it will lower your conversion rate.

So, how do you 'fix' this problem - after all, you want satisfied, repeat customers - that's the greatest return on your marketing investment, right? The answer is really quite simple. Make the value proposition when the user is not distracted by purchasing. Ask for their email address during checkout by offering to keep them updated on the status of their purchase (if it's a purchase that needs to be fulfilled) or offering to check to make sure they're satisfied with their purchase. Of course the trick here is to actually follow up - not doing so will be counter-productive at best.

An email follow-up approach has the additional benefit of reduced cost. Consider this - if the customer does not want to give you their email address they likely do not anticipate being a return customer. Their intention clears you of securing and storing personal information as well as spending marketing funds to retain or re-engage customers who will not be bringing you repeat business.

The solution is simple and effective, allowing you to focus your energies toward making your customers satisfied rather than acquired accounts...and isn't that what really drives your business - satisfied customers?

Notes: links open in a new window

1. Conversion is the measure of those potential sales that become actual sales. For example, if you have 10 customers with items in their cart and 9 buy their items and one leaves without purchasing, your conversion rate is 90% (and your abandonment rate is 1%).
2. Acquisition addresses acquiring a customer, without regard to whether the acquisition is either temporary or permanent.
3. If you sell online and don't recognize this, there is a significant chance that either you have selected the wrong indexes as KPIs or you are not performing A/B testing and are not measuring the impact of activities assumed to be beneficial or at least benign.
4. A payment gateway is a service provider that authorizes payments, typically by acting as an intermediary between the merchant and a credit card issuer. Learn more about payment gateways at http://en.wikipedia.org/wiki/Payment_gateway.

Doing the impossible (with Robert's Rule #31 & #32)

This post is not going to be a 'how-to', or an example of critical thought applied to a current topic, but rather a prosaic reflection with career advice mixed in - somewhat like earlier posts.

When I was a young child, we were discussing poetry in primary school and I pulled a book of American poets off the shelf and found It Couldn't Be Done by Edgar A. Guest^[1]. I still recall the note my schoolteacher sent home saying how much the poem reminded her of me, even though I cannot find the note - of course that was quite a number of years ago.

I would not encourage anyone to be excessively optimistic (I would say pollyannaish, but I believe that unfairly associates optimism with feminism), there have been a number of credible studies that demonstrate the benefits of positive thinking^[2]. Yet,  there is something beyond even positive thinking that I feel is crucial to our survival in a corporate environment - an indomitable will. For some, an indomitable will manifests as an "incorruptible patience" or "a destructive pursuit of perfection"^[3]; for others, there are other ways - but they have this in common - they are not skill related and won't be found on the Programmer Competency Matrix^[4] - in fact, it's those times that we're faced with a situation that we know is beyond our bounds that this applies, and it's what made Bert Bell's belief that on any given Sunday any team could beat any other team in the league real. (Robert's Rule #31 - success is about more than skill - is based on that belief.)

A personal story - several years ago I was preparing to fly to California for an in-person interview for a position that I considered a dream job when I found out that my sister, who lived 2000 miles away, was critically ill, and a few hours before I was to leave for my day-long interview, I learned she had died. My grief was beyond anything I had borne before, but I also recognized that the only thing I could do at that point was request PTO and book a flight - and one more day would make little difference in the grief or support that I, or anyone else in my family, could offer.

Even though I knew a rigorous interview process was beyond my bounds in that circumstance, I went and did my best. After I returned home, I contacted my employer and booked a flight, and left the next day. After I secured the job (yes, I did get it), I discovered that some who interviewed me noticed (what they interpreted as) a lack of enthusiasm - several commented to me that interviewing in that situation was something they thought couldn't be done, yet it was done - and well enough to secure the job.

So, here's the lesson I learned that day - if you want something enough and your will is indomitable, you will likely succeed - success is not guaranteed, mind, but very likely.

There was another lesson I learned that day - one that's probably more important
that I carry with me, especially every time I interview a candidate - on any given day we see only a part of a person, and like in jazz, the important bits might be those not heard, so make allowances for what you don't see (Robert's Rule #32).

Or, in the words of Bill (in Bill & Ted's Excellent Adventure), "be excellent to each other".

Notes:

1. If you've never read this poem, do so. I recognize as a (more cynical) adult that it's a bit trite, but it's somewhat uplifting and motivational, and there are times we all need that.
2. The article How the Power of Positive Thinking Won Scientific Credibility is an interesting read regarding the evolution of thought and research in this field, and has links to a number of those studies.
3. These are two traits of a fantastic programmer from Signs that you're a good programmer.
4. http://sijinjoseph.com/programmer-competency-matrix/

Designing for Collaboration

I recently heard an executive (let's call her Ms. Foo) stress that collaboration is the key to success, and in order to collaborate effectively, a company needs to ditch the ubiquitous corporate artifact - the cubicle; therefore, (here's her hypothesis) eliminating cubicles and replacing them with an open floor plan is best for our organization. As further support for her hypothesis, Foo also has said that the cubicle is the epitome of a closed corporate culture and that high-performance companies (e.g. Apple, Facebook, Google, and Twitter) don't have cubicles.

As an exercise in critical thinking, let's quickly examine Ms. Foo's arguments - by first examining the argument for fallacies and then examining the veracity of the statements can we determine whether or not Ms. Foo makes a valid argument.

Let's first examine Ms. Foo's argument that 'collaboration is the key to success'. In its present form, this argument is clearly a sweeping generalization. Even if the statement were qualified to her own organization in the more precise 'collaboration is the key to our success' it's still arguably not precise enough and is not as precise as would be "collaboration is a key to our success". By increasing precision we can easily see that maintaining the argument in its presented form also creates a false dilemma.

Let's next examine the statement that 'the cubicle is the epitome of closed corporate culture' (and the connotation that such a culture is not what Ms. Foo wishes to represent). To better examine this, we will ignore the hyperbole and better express the argument as 'closed corporate culture promotes cubicles' - for certainly the epitome of 'closed corporate culture' would be a office door - or at the very least, something that can be physically closed. I would put forward that although Ms. Foo's original argument is a lightly veiled guilt by association, our restatement of her argument is clearly an example of such a fallacy.

Let's next take the statement that 'high-performance companies don't have cubicles'. Even if the statement is factually correct, and I am not in a position to argue that it is not, it still remains an argumentum ad populum. Perhaps what Foo intended was to present evidence that 'high-performance companies' have implemented a collaboration-promoting floor plan and found it beneficial. If this argument is intended as evidence, let's restate it so that it may more closely represent the evidence she intended - let's instead say high-performance companies have implemented an open floor plan and have seen an increase in collaboration.

Even though our more semantically precise argument doesn't fall into the argumentum ad populum, such changes in environment design are seldom executed under the strict controls normal experiments fall under and without control groups it is typically impossible to determine the veracity of the premise. Without demonstrating a causal relationship, the argument is, at best, subject to cum hoc ergo propter hoc or perhaps to post hoc ergo propter hoc.

It is clear that Foo's arguments are fallacious; however, that does not mean that the conclusion (that open floor plans are best for her organization) is necessarily false, simply that it is unproven, so let's continue the exploration.

There are additional problems with Ms. Foo's proposition; for example, it's rife with ambiguity. Perhaps by clarifying this ambiguity we can come to a restatement of the argument that is not fallacious - one for which we can examine the veracity.

First, it's not, generally speaking, as if a person chooses to either collaborate or not, but rather they choose, consciously or subconsciously, the degree to which and manner in which they collaborate; "collaboration" is not an all-or-nothing one-size-fits-all proposition. Further, Ms. Foo uses the term success without actually defining how success would be measured. Success may be defined as high productivity, as it is in many cases, or high innovation, or perhaps high engagement among the employees.

Ms. Foo's original argument might therefore be restated as collaboration in the manner I understand it is one of the keys to what I define as success for our organization; a floor plan that does not use cubicles, such as those employed by Apple, Facebook, Google, and Twitter, creates the type of collaborative environment I desire; therefore, eliminating cubicles and replacing them with an open floor plan is best for our organization. This restatement clarifies many of the points of ambiguity, yielding a much less fallacious line of reasoning; however, it also makes Ms. Foo sound a tyrant and generally undesirable boss.

I should point out at this point that I've not ever been to any of the companies classified as 'high-performance companies' and cited by Foo, nor can I say reliably that collaboration is not a key to success for her company. I can say that I have, in more than a couple of decades in the industry, worked in a variety of environments - everything from 'open floor plans' to an office with a door, and while I would avoid a hasty generalization, or other fallacy, there may be other factors Ms. Foo has not considered.

In my experience, each organization in which I have worked has had a variety of concerns that weren't related to collaboration that influenced the work space configuration decisions. The most pronounced concern has typically been security. My experience has been that the greater the need for security, the more restricted the work space is. Basically, in the work environments where security was highest, my workstation was behind a locking door and few people had access. Collaboration within environments with strict security is, undoubtedly, lower as knowledge and activity is compartmentalized; conversely, collaboration within environments with lower security is higher.

I would also say that I am generally supportive of collaboration - in fact, I would put forward that the teaching method named for one of the world's most famous philosophers is based in collaboration between student and teacher. In my opinion, it could easily qualify as a key to success in many organizations.

With those qualifications being disclosed, I'll continue, using, instead of Ms. Foo's original argument, the restated argument, and looking to the veracity and whether or not it follows from beginning to end.

First, I believe there is little room for doubt that physical environments can affect collaboration. The argument that a floor plan that does not use cubicles facilitates an open and collaborative environment may be true. However, possibility is not actuality, and I do not believe that an open floor plan is either a necessary or sufficient condition for collaboration.

There are, in my experience, a number of things that hinder collaboration. I would separate these hindrances into physical and non-physical obstacles. Non-physical obstacles typically include who can collaborate but also go beyond into how individuals are encouraged, or even allowed, to collaborate. In fact, I would posit that physical obstacles to collaboration, whether it be minor physical barriers, such as a cubicle, or more significant physical barriers, such as lacking a physical presence in a location (e.g. telecommuting), are less significant than non-physical obstacles in the face of technology, primarily because they are easily controlled. We can easily move into shared physical space in the case of cubicles or use email, phone (whether land-line or mobile), and instant messaging when lacking a shared location. In fact, organizations distributed across the globe typically use a combination of these tools and more to collaborate.

Since the non-physical barriers to collaboration - for example, a culture that does not value the contribution of specific individuals, whether that is because of their role in the organization or their position in the organizational hierarchy - are generally both more significant and more difficult to address and control, these issues should be addressed first. Seeing a physical environment as the obstacle to collaboration is a red herring, especially considering the number of methods available to work around physical environments. Further, because the features of a physical environment that affect collaboration can so easily be bypassed, we might conclude that if those features affect collaboration, and it hasn't been demonstrated that they do, that result is desired by at least one party to the collaboration. In other words, the processes for collaboration must be addressed prior to the environmental issues that may hinder collaboration, in part because it is quite possible that the very environmental issues seen as obstacles to collaboration may serve another purpose within the organization.

As an example, lets assume for a moment that one party in our 'collaboration' model has a constraint that creates an inverse relationship between a success and interpersonal interaction. If such a constraint existed, would it not follow that productivity would be improved in those situations where the amount of interaction was controlled? If physical barriers are easier to overcome - to manage - would it that factor not make it the preferred control? If we can see an affirmative answer to either of these questions, then is it not a simple matter of asking ourselves "can such a constraint exist?" The answer to that question is a definitive "yes" - AD/HD is a physical condition (and an ADA protected class in the US) that creates an inverse relationship between many measures of success and interpersonal interaction.

We've seen how this argument applies to cubicles, but how might the same general thought process apply to another collaboration-reducing environment, telecommuting? It is in this question that we will demonstrate the importance of the ambiguity of the word success as well as collaboration.

We can be certain telecommuting is a greater barrier to some forms of collaboration than cubicles, because at a very minimum the accidental interaction while moving through shared space is no longer available and intentional interaction must be attended to in greater detail. It seems after a two-month silence that perhaps this collaboration was what Marissa Mayer intended to address rather than productivity.¹

In making statement that telecommuting is a barrier to face-to-face interaction she has, to some degree, stated the obvious. However, she goes on to claim that people are more collaborative when they are together - in itself perhaps not a wild claim - and that it follows that they are more innovative. It is unclear whether this last statement is wishful thinking, a hasty generalization, an instance of post hoc ergo propter hoc, or an evidence-based claim.

Mayer clearly defines success as generating ideas (product development) rather than delivering on those ideas (productivity). By defining success, not as productivity - which has been the generally accepted measure of success - but as the generation and conglomeration of ideas, Mayer may have made a potentially workable argument for a direct relationship between what she means by collaboration and success; however, it is not a foregone conclusion.

If we define success as the generation and conglomeration of ideas, it might seem reasonable that we ought to look to increase collaboration; or at least interaction, including accidental interactions; however, we ought also recognize that the increased interaction comes at a cost. Further, we ought also recognize that the cost we pay in one area may not show a benefit in another. For example, it would be possible to decrease productivity without increasing collaboration or the generation and conglomeration of ideas.

Finally, even if the elimination of all physical barriers increases collaboration, which has not been proven by either Ms. Foo's arguments, or Marissa Mayer's, does it follow then that the increased collaboration is good for an organization?  Not necessarily, and that's where the design comes in. Without adequate design, one that balances the cost against the (real or perceived) benefits, increasing collaboration is destined to fail; otherwise, edicts intended to promote collaboration leave organizational members who have little chance to contribute to the discussion feeling disenfranchised and generally dismissed by a tyrant, and that environment is definitely not conducive to collaboration, or in fact anything other than self-protection and evasion.

Notes

1. Marissa Mayer Finally Addresses Work From Home Ban

Fear is the birth of cruelty and the death of reason, wisdom, and finally, action. (Robert's Rule #26)

Fear, as our 'leaders' have discovered, is a powerful motivator. For most people, one of the most powerful fears is of losing their job, in fact, for some people, the fear of the loss of their livelihood is even stronger than their fear of death, because it means something very significant to those who depend on them. Because of the power of this fear, employers the world over become some of the most powerful entities known. However, this fear comes at a price, for fear is the birth of cruelty.

When you, as a manager, threaten someone's job and engage this powerful motivator, your 'direct report' will likely tow-the-line. They will likely become quite complacent. They will also likely quit innovating, start protecting their assets to the detriment of the team, and start looking for a place of employment where they believe they will be respected, which means their productivity will generally plummet and they will become a drain on morale. In short, what you will have created is a negative reinforcement cycle that will likely spiral out of control.

On the other side of fear, however, the lack of fear is an equally strong motivator. The lack of fear can be the result of either having nothing more to lose or a true feeling of safety.

The lack of fear that is the result of having nothing to lose - that finds its origination in desperation - is dangerous in the extreme, as The Art of War notes. It is the recognition of this fact that has led companies to treat terminated employees as criminals as they are escorted from the building, often without even being given access to their personal effects. The creation of this type of 'enemy' is a mistake of the highest order and you should always try to maintain the appearance that even those discharged have something more to lose. Helping them move on to another position (if that is at all possible) is a good start. After all, just because they don't fit in with your organization that does not mean they would not fit in quite well somewhere else. If you can honestly, objectively review their contribution you will (nearly always) find some benefit they provided to the organization that you can leverage as they look for another position.

On the other end of the lack of fear spectrum - when a person feels safe in their job - people are more likely to take risks, stretching and growing. They are also likely to innovate, be more relaxed and positively affect team morale, in essence become a powerfully positive asset. It is the creation of these positive reinforcement cycles that we need to create. One of the most powerful effects of these positive reinforcement cycles is the energy they contribute to the team, as study after study has shown that 'winning' begets 'winning' and nothing so strongly counters winning than fear and trembling, because fear is also the death of reason, wisdom, and eventually, action.

The convenience of electronic communication shouldn't enable you to treat another's time as if it's unimportant (Robert's Rule #13)

[Tweeted 2011-05-15]

If you're like me, you get bombarded with electronic communication, often to the point that it becomes difficult to disconnect. If I'm out of the office for a day, I can easily have nearly 300 emails in my work email inbox. If I add that to the 4 personal email accounts, Twitter feed, Facebook posts, Skype messages, SMS messages, phone calls, et cetera, it quickly becomes overwhelming. It becomes such a factor, that there are times that I do not respond to attempts to communicate.

If I choose to take myself offline for a period, people sometimes react with annoyance and I remind them that I maintain my email accounts and pay my cell phone bill because I intend for those things to make my life more convenient. However, all of that is from my perspective, and others that I have talked to say the same thing (aside from the snarky bit about it being for their convenience...that's all me).

So, we all feeling the pressure, but we're doing it to each other. I don't want to feel overwhelmed by my 300 emails (plus everything else) every day, but I can't stop sending out emails, or Tweeting, or sending that SMS to someone.

So I can see that we have a volume issue to deal with, but maybe it's not just the volume. After all, reading 300 work emails feels different than 100 tweets, 100 status updates, and 10 Skype conversations. Why? Because they're important and urgent. Whatever the problem is, it (at least in the mind of the email author) needs to be addressed as soon as possible. Therein lies the larger problem. Volume is still an issue, but the other kind of volume...the volume with which the message is conveyed is also an issue, because the meta-communication is what you think is important is not as important as what I think is important, in other words, your time is not as important as mine.

Of course that's not true; everyone's time is valuable. Coming to this realization led me to another rule: the convenience of electronic communication shouldn't enable you to treat another's time as if it's unimportant (Robert's Rule #13). Think of it as a variant of what, in American culture, is called the Golden Rule and maybe, just maybe, people will enjoy talking to you a little more.