Showing posts with label innovation management. Show all posts
Showing posts with label innovation management. Show all posts

Saturday, June 30, 2018

Why you should never code for new browsers

A quick, very short post today.

First, I should preface this by saying that I've been writing human/computer interfaces for a very long time...and for a good part of that time - it's been more than two decades now, I've been writing for these crazy user-agents we call browsers. The Mosaic Wars are a little fuzzy, but I remember the First Browser War vividly.

Every great once in a while, I see a question along the lines of "is x compatible with some-really-old-browser" and there's always a response along the lines of "no one uses that browser anymore, if you're coding for anything older than n - 1, then you're wasting money".

I can say with 100 percent certainty, that if you're coding for specific browsers - be they old or new - then you're wasting money.

Browsers are released very frequently - for Chrome and Firefox, it's typically about every 6 weeks. The specs they claim to support are release much less frequently...for example, a new HTML spec was release every 1 or 2 years between 1995 and 1999 when HTML 4.01 came out, but the next spec - HTML5 - didn't come out for 14 years. CSS first came out in 1996 and was updated about every 2 years until CSS 3 came out (in 1999). 

What's that I hear? A host of voices singing the popular refrain "but we use JavaScript"? JavaScript is finally to the point where it is currently being updated annually - which makes it the fastest changing language of front-end development and still much slower than 6 to 8 times a year.

Add into this mix of rapidly updating browsers the mix of assistive technology (with its own specifications), and we begin to get a picture of extremely volatile user-agents and very stable specifications.

If there was one thing we should have learned from the First Browser War, it's that we should be not be coding according features that are available in one browser that we then try to port to another browser with extra work. Determine what your needs (and wants) are, code to the specification, and let the browsers catch up. Browsers update much faster and are very likely to render your code as you want it to look within the year without additional work from you. Also, this approach is as backwardly-compatible as possible (what in the accessibility world we call being robust)...and if you're not attempting to deliver a product to every end user, regardless of the user-agent they use, then you really are wasting money.

Happy coding.

Wednesday, June 12, 2013

Rockstars and Innovation: Stairway to Heaven

A friend recently posted a link to an article[1] by Francois Marchand of The Vancouver Sun that covered a portion of the Kennedy Center Honors - specifically the tribute concert for Led Zepplin[2]. Being a big fan of the Kennedy Center Honors, I watched this particular celebration when it aired on my local CBS affiliate, but the article brought something back to mind that I had temporarily forgotten - a question I had nearly every year when I watched the program - do stars realize they are creating something epic when they are creating it?

We know a lot about stars (divo or diva, if you will), especially in the US where we're constantly fed minutiae, from what they wear and eat to the foibles of their children and the sins that will be visited upon them - we even know about their demanding, uncompromising fits of rage and a little about how their attitude might be handled[3]. It would be dishonest to imply that all the stars are thespians and musicians, after all, we in the technology industry have our share of stars (some of which, Steve Jobs for instance, have notable rants). However, we might say that all the stars consider themselves artists. It's with this area bordering aesthetics[4] that I'm particularly interested.

First, I would posit that people, stars in particular, never realize the true nature of their creation - they may have visions of a possible future, but never fully grasp the import. Even some of the (arguably) most brilliant of minds do not realize the most minor consequences of their actions until they see the first glimpse of their creation come to life[5]. One reason for this is that we simply cannot foresee the future. We cannot anticipate the many ways in which our creation will be re-arranged, re-interpreted, or re-worked.

A more important reason for this disconnect between the recognition of the impact a creation has and the birth of the creation, however, is in the very act of creation itself. The two events - the birth and the post-birth impact are bound to different understandings of time. Where the birth is held by kairos[6], the impact - whether or not something is epic - is held in chronos[7].

Some artists are entirely comfortable with this difference, willingly surrendering the telling of the story or the composing of the song to the moment and leaving the remainder to time and even going so far to say that they are driven only to create - storytellers have stories that they feel must be told, or in some cases, tell themselves, and musicians have songs they feel must be sung. It is the purity of this brief moment - a brief moment in which things are possible - that births what is epic, and even though we strive for perfection, we cannot intentionally create anything truly epic, for all of our planning and working - logos - is bound to chronos.

What does this say about pleas for organizational leadership for 'innovation' then? As we've begun to see, innovative has suddenly come to mean not only 'changed' but also carries the connotation of the change being epic as well. Innovative is revolutionary, evolutionary is passe.

There are only two directions in which we can move from this false understanding of innovation - recognize that striving for 'innovation' is irrational and therefore counterproductive, or move to the original understanding of 'innovation'.

Given that epic creations are rare and cannot be crafted through striving, strive instead to innovate in the true sense - change things, especially through small, non-fundamental (evolutionary) changes - changes like adding a choir to your arrangement of an iconic song. Not only does this approach involve less risk than major or fundamental changes, it can just as easily give birth to something epic - something that even the creator didn't imagine[8].

Notes:
  1. Heart plays Led Zeppelin’s Stairway To Heaven, makes Robert Plant cry, The Vancouver Sun, 27 December 2012.
  2. Heart - Stairway to Heaven Led Zeppelin - Kennedy Center Honors
  3. Robert's Rule #6: when working with rock stars, get your M&Ms ready
  4. The branch of philosophy dealing with the creation, appreciation, and nature of art, beauty, and taste.
  5. Oppenheimer, in recalling reaction to the first test of the creation produced by the Manhattan Project, said that he, and his fellow scientists realized the world would never be the same, and called to memory a line from the Bhagavad Gita, "now I am become death". [Video]
  6. In mythology, Kairos (opportunity), was the youngest son of Zeus. He is described as running swiftly, balancing on the razor's edge, unclothed and with only a forelock - so that if you grasp him from the front, you might be able to hold him, but once he has moved on not even Zeus himself can pull him back. Because of this tie to mythology, kairos is the brief moment in which things are possible, and is a qualitative measure of time.
  7. In mythology, Chronos is the personification of time and the serpentine consort of Ananke (inevitability) who co-creates the cosmos. He is not unending time (represented by Aion), but is the one turning the wheel of time and is, therefore, not a brief moment, but a quantitative measure of time.
  8. Make note of the reaction of both Plant and Page throughout the video of Heart's rendition (see note 2).

Monday, April 22, 2013

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.1

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

Tuesday, April 2, 2013

The Disadvantage of Agnostic Development

There has been a trend in technology for agnostic development. In fact, if you google agnostic development, you'll likely be given the choices to be "platform agnostic", "device agnostic", "browser agnostic", "design agnostic", "os agnostic", and more - but what does it all mean?

According to one website, "agnostic, in an information technology (IT) context, refers to something that is generalized so that it is interoperable among various systems. The term can refer not only to software and hardware, but also to business processes or practices."1 The website goes on to say how agnostic is a compound word from a ·• gnosis (which it says means without knowledge). This, unfortunately, is a misunderstanding that we must first address.

Let us assume that the common understanding of the etymology is correct and look first at the word gnosis (γνώσις).

The word gnosis can most certainly be translated knowledge, however, it is not simply knowledge, but a certain kind of knowledge. It is typically used to identify experiential knowledge and is contrasted against episteme (επιστήμη), or theoretical knowledge. In this understanding, then, we can see how a ·• gnosis matches the context quite well - we are developing something that has no experiential knowledge of something.

Permit me another tangential comment - or if not, skip this paragraph. Classical Greek thought was all about the experience and their language reflected that understanding. For instance, we can see the experiential bias in this example and in the companion words chronos and kairos.

As we know, the language of Plato was very precise, and because of this precision and the observation that much of classical thought is based on one's experience, and because gnosis doesn't seem to fit the word agnostic, I would put forward that the common understanding of the etymology of agnostic is incorrect. Rather than the stem gnosis, I propose that the stem should actually be gnostikos (γνωστικοσ), and that our understanding of agnostic should be not be simply without knowledge but rather something that cannot be known.

With this new understanding of agnostic, let's look at a few examples of typical agnostic development. For instance, we may have "platform agnostic" software that runs on any combination of OS and processor architecture, "device agnostic" software that operates on multiple devices, or even "protocol agnostic" software that negotiates communication with peers rather than being bound to a single protocol.

In each of these examples, and the many more examples we can think of, the term agnostic doesn't really apply. I would put forward the idea that even if we take the original etymological understanding of the term, the term is still imprecise enough to cause confusion. In all of these cases we can, and in fact do, know the technology (OS, device, or protocol) being used - it is rather that the software doesn't care which technology is used. The correct term, then, is apathetic.

Why is this a problem? As we have experienced numerous times, the amount of coding necessary to develop a truly apathetic system is significantly more. More coding means more complexity, more complexity means more testing and more defects, more testing and defects means more time and money are invested, and on and on - more, more, more.

Yes, apathetic development means more, more, more...except where it typically counts the most, because it also means less - less optimization. Less optimization means a poorer user experience, often due to under-utilized resources, and a poorer user experience typically results in no one getting what they truly want....and that's why I always try to keep in mind that the key to failure is trying to adapt to everyone. (Robert's Rule #31)

Notes:
  1. What is agnostic?

Friday, March 29, 2013

Mobile First

Mobile first has become the new mantra of technology companies, but as with anything, we must think about what we're doing, not just do it because we can.1

Any time we're building a new product there are things that must be built into the requirements - especially those items that without which our product would be defective. Security and performance are two good examples of this, and neither can easily be 'tacked on' at the end any more than it would be easy to transform a minivan into a race car.2 However, contrary to the assumptions about security and performance, we ought determine, before going down the 'mobile first' road, whether or not it makes sense to travel that path.

What I am going to say next will probably surprise you, but...mobile is not for everyone...at least not in the US market. Now, granted, I'm for creating products that handle globalization well - in fact it's been one of the most forceful lessons I've learned over the last several years - but if we're just looking at the US market we have to evaluate the data. After all, we are getting paid to think.

Data now shows that while there has been a hefty increase in the number of people using their mobile devices for banking, those same people are reluctant to use their devices to pay at retailers and restaurants.3 While many retailers are seeing a trend in which consumers will enter their physical locations to do additional research and subsequently make a (better informed) purchase online, that does not translate into purchases using a mobile device. The global financial services giant, PayPal, announced figures at their recent Analyst's Day that also point to this trend. According to those numbers, 25% of PayPal's users are using their mobile devices (compared to 50% of US cell phone users who accessed online banking services) and mobile devices only account for 10% of their total payment volume (TPV).4 While this 10% may in fact be a disproportionate number of transactions, and likely is as people pay for mobile-specific items like ringtones and other digital goods, it still points out, in the best case, that big purchases - the kind typically made at retailers and restaurants - are not being paid for using mobile devices.

Of course the situation could change, and it's clear that eBay, PayPal, and a number of other companies are betting on it. In the meantime, why maintain the mantra "mobile first"? There are valid reasons associated with development costs that basically boil down to why develop two (or more) apps when one responsive app will suffice. That is difficult to argue against - after all, if developed well it's likely that quality assurance cycles can be shortened, time between releases can be decreased, as can the number of engineering staff necessary for maintenance and new product development. Then again, I have yet to see any reliable data that demonstrates any of these advantages, and there is still disagreement in the industry whether a responsive web application or a native mobile solution is best in any given situation. At the very least it behooves us to put more thought into our work than simply repeating a mantra that may or may not be useful.

Notes:
  1. Robert's Rule #17 (Too often 'we can' erroneously becomes 'we should' and 'we will')
  2. Look at BBC's Top Gear Series 12, Episode 3 to see how that transpires.
  3. Consumers using phones to bank, but not to buy, Wall Street Journal, March 27, 2013
  4. eBay Inc. expects to enable $300 billion of global commerce by 2015

Tuesday, August 21, 2012

Constraints and success become inversely proportional when creative energy is applied. (Robert's Rule #27)

It may be counter-intuitive, but perhaps it's time we saw constraints as a necessary condition for greatness. Take, for example, what Igor Stravinsky said: "the more constraints one imposes, the more one frees one's self...and the arbitrariness of the constraint serves only to obtain precision of execution" (Harvard lectures, 1939-1940). This sentiment is echoed in another (modern) musician, Jake White. (If you haven't yet seen it, take a minute to watch a clip, from Under Great White Northern Lights, that describes his take on this idea - seriously, do it now.)

"That's all fine for musicians", you say, "but what does that have to do with me?"

Often those of us in the tech industry think "if I had ..." and then proceed to fill in that blank with something that will lift a constraint. Over the years we have filled that blank spot with "more RAM" or "a faster drive" or "a faster bus" and so on; meanwhile, NASA's space shuttle is famous in part because of the memory constraint imposed by the technology of the time.

So, how does this relate to you, today? First, and foremost, we can easily point to the spin-off products that we use every day that were developed from NASA patents - products that were initially developed to deal with special constraints around space travel. One of those products, satellite communication, is especially applicable to our (DARPA created) web environment.

Since we're already on the communications track, perhaps we should think about mobile technologies as our next opportunity for greatness. There are several constraints, especially related to web apps, in the mobile space. The limitations of memory, processor speed, bandwidth, and battery life are all constraints that give us the opportunity to create greatness.

Look at it from this perspective - it's very likely that a great mobile web app will be a great desktop web app, because the primary influence determining whether or not people visit/use/return to your site or app (after content/functionality) is speed, and if, with all the constraints in the mobile space, your web app is fast, it should be blisteringly fast in a desktop experience.

I am certain that there are other ways in which constraints can help you achieve greatness. Look for those opportunities to, in the words of one industry leader, "make more awesome".

Wednesday, March 21, 2012

Rules are beneficial because they give constraint, but it is in stretching that we grow (Robert's Rule #21)

[Tweeted 2011-07-17]

As an engineer, you have to be familiar with rules – mathematical formulas, design rules, data normalization rules, language rules, et cetera, et cetera. We're so familiar with rules that we could not imagine living without them, and if someone breaks a rule, we have other engineers dedicated to quality to identify those instances so they can be remedied.

So, if we're always following rules, how can we innovate or invent new things? We do both by stretching. In infinite diversity in infinite combinations (IDIC) creativity gains its full strength. Creativity is the basis of both innovation and invention.

If we consider, then, that our creativity is a muscle, we can think of the rules governing our environment to be the resistance against which we exercise that muscle. Much like our physical muscle is toned and built in striving against gravity by climbing a mountain, our creative muscle is toned and increased in striving against the 'rules'. Of course this exercise requires that you be familiar with what rules you strive against as well as how those rules impact your environment, for instance, if we didn't understand how gravity worked, we would not be able to effectively exercise our physical muscles.

In this analogy, we see can that rules are beneficial because they give constraint, but it is in stretching that we grow (Robert's Rule #21). So, go and create.