Performance, baby

I'm going to start this entry with a story.

In the early 1990s, I worked on an project that paired third-level students from Northern Ireland - most attending university - with colleges and universities in the United States. Funding came in part from the Training and Employment Agency in Northern Ireland and in part from associations of religiously-affiliated colleges and universities in the US, such as the Association of Presbyterian Colleges and Universities.

The project was an interesting one on a number of levels. Though the Troubles weren't in the news on a nearly daily basis, this was before Stormont, and even before the cease-fire. The participants were both Catholic and Protestant, so there was a lot of discussion and work around matching participants and US schools...and it was very interesting to learn in a newspaper years later the degree to which various politicians (including POTUS) were (supposedly) involved.

One of the challenges we faced early and consistently in the project was communication. As the old saying goes, we were two groups separated by a common language. Each conversation had to be decompiled from its native language (either US English or NI English) and recompiled into the language of the audience. After a few calls, our US-English/NI-English transpiler ran (almost) flawlessly and pretty quickly.

There's the rub though...it ran almost flawlessly and pretty quickly.

In a conversation between people, a small gap of a few seconds is easily overlooked, especially when each side experiences the other as listening and engaged because we measure performance differently than we do in other environments.

How does this apply to you, dear reader?

If you're a UI engineer, building web interfaces, you're dealing with one of those other environments - one where fractions of seconds matter. In that environment, here's the thing you must keep in mind...transpilers always decrease performance...always.

Yes, ES6 is cool. No, ES6 does not have enough browser support to justify writing public-facing apps that use it. Yes, you can add a transpiler (like Babel) to your code to fix it. No, this is not a good thing to do. Why? Transpilers always decrease performance.

As we know, performance is a multifaceted problem. So far I've only talked about transpilers affecting performance in execution, but if that's all we see, we haven't really looked at how they affect performance, because any discussion about performance must also include a discussion about how performance is affected by increasing page weight.

I sense a disturbance in the Force, as if millions of voices suddenly cried out in terror as people say "why are you worried about page weight when we all have LTE on mobile, and broadband to our desktops?". That thinking focuses only US urban centers. Rural areas - those areas that one might argue are prime targets for online services - might not have broadband and while they might have LTE, they might not have unlimited data on their mobile plan.

It doesn't end there, of course. We also must consider the probability of writing "bad code".

Robert's Rule #33

The probability of writing bad code is proportional to the complexity of the tool(s) used to write it.

There are many ways in which you could be killing your performance, and if you're not testing on a throttled connection (to simulate less than 4G/LTE) and on low-power devices, you'll never know. Testing in excellent conditions - simulating only a 4G with a high-powered device - gives a false impression. Much like our experience after several months of conversations between the US and NI groups in which our 'transpilers' were fully functional, your testing is under nearly optimal conditions.

How much does bad performance cost? That's a difficult question to answer. On a large site - one the size of etsy or eBay, for example - performance will typically be measured in fractions of a second and a 500ms delay can cost millions of dollars in lost revenue. On a smaller site it's typically more difficult to quantify because of the relative lack of volume of traffic. All sites - both large and small - can be adversely affected by significant performance problems that result in poor brand image and lost visits and sales.

Performance, baby. Performance matters, and you could be killing yours without even knowing it, but you can change that, even if it means your developers work a little harder.

Happy coding.

The Party's Over

On the way in to the office today I was listening to the radio. No, not "internet radio", real radio - with a real DJ and everything. There was an interview with Paul McCartney, who was asked, in light of his upcoming appearance at Candlestick Park, why the Beatles stopped performing...his response was "it wasn't fun anymore". Something about the culture of money, fame, and ostensibly doing what they loved changed and it wasn't fun anymore, and that was enough to make them walk away.

I know that the Beatles, individually, were famous and talented enough that they were able to enjoy 'solo' careers, and that even if they never toured or recorded again, they could probably have survived quite comfortably, and that's no small comfort (for them)...but still - walking away from millions of dollars and instant recognition with no guarantees that you will be able to do what you love again...it's nearly mind-blowing.

You might find yourself asking "why is this important, why is he bringing this up" - and with good reason. After all, my most recent posts on this blog have been at least somewhat technical...and there haven't even been any of those for a significant span of time (at least in blog years). So, your curiosity is understandable...and I'll get to the why of the timing eventually.

Back to the original train - "it wasn't fun anymore". When I heard this come over the airwaves, it reminded me of something I'd read in April of this year - Brian Chesky Note 1 relating the advice of Peter Thiel Note 2 when he funded Airbnb.

Don't fuck up the culture.

Peter Thiel, 2012

There have been a lot of people considering Thiel's advice - there are around 31,000 document matches when searching for Thiel's exact words - and now here is my journey down that particular rabbit hole.

When I was at university in the Metaphysics course, a question intended to highlight the division between essentialists and existentialists arose, framed not as a question about people but objects. Consider that we're rebuilding a sailing ship and we tear it down to the keel and replace all of the boards. When our work is complete, is it the same ship? If we think of it in terms of automobiles, it would not fit the definition of being the same car, because the identifier for the car - the VIN Note 3 - no longer accurately represents information about the vehicle. So, is it a question of how much we change something or what we change that makes the determination? Are organization analogous to objects? How does this apply to organisms?

Corporations are not people, but they are organisms, with values and personality that govern their actions, for good or evil. If we go back to the question of 'how much change' or 'what kind of change' makes something no longer identifiable as itself, we can think of situations in which we've thought, even though we may not have formally defined it, that some person we know has changed in some way and now they are not the same person - we may even readily claim this using this exact phrase. We should consider corporations subject to these same rules of behavior and personality. In fact, we can most likely each think of an organization - such as a business or philanthropic organization - that after an unsettling experience left us with the thought "they would have never done that it the past" or "they sure have changed."

Thiel most likely has seen organizations that have damaged their culture time and time again in organizations that have come to him for venture funding. He certainly sees it not only as a possible problem, but one that is likely as well. This, too, stands to reason as the common thinking is that as an organization grows, the culture changes as efficiency of scale is achieved in various areas.

The problem that I imagine Thiel sees - and yes, I am putting words in his mouth to an extent - is that when the culture changes, people leave - a situation that is also accepted as not only survivable, but normal. However, in reality, the turnover caused by culture changes are dangerous for an organization - it's like having an illness that has not yet been diagnosed - one with symptoms that you decide you can live with but that just might kill you. Part of the reasoning here is that culture changes are generally a self-reinforcing loop - the sort of loop that once it's started is not only difficult to stop, but also difficult to control or in some cases to even recognize.

Given the semi-private nature of an organization's culture, the earliest greatest impact of damage to an organization's culture will be to those within the organization. Why is this important? People are generally not motivated by money - culture is what motivates people - and it motivates people to do amazing things - like work 80 hours a week for several weeks at a time even though they're only compensated for 40, meet ridiculous deadlines, or nearly violate the laws of physics to deliver a high-quality, low-cost product quickly - whereas incentive programs generally don't work. Note 4 Because of the tight coupling between culture and other areas - like motivation and productivity, changes to culture can have a dramatic effect on the organization as a whole.

At this point, we might be tempted, after seeing people violate Thiel's advice, to think the culture of the organization is permanently damaged any time that it is changed dramatically. There certainly are people who have departed any number of organizations thinking just this thought. A brief review of companies on a site like glassdoor gives insight into the number of people working for a company who believe "changed" is equivalent to "damaged". However, here we have to stop and notice that Thiel's advice wasn't "don't have a damaged culture", his advice was "don't damage the culture". The linguistic difference between those two messages is less significant than it should be, because they are drastically different concepts.

In one version, culture is in a damaged state and in the other it's different than what it was. We need look no further than our own history of romantic relationships to see the truth of the premise that these are different, regardless of our willingness to admit it in the pain and grief that comes immediately after the recognition of how we, or the other, have changed. Just because someone or something you love - be it a person or an organization - changes and you find they are now intolerable (to you) that does not mean that they are therefore befouled or damaged - they can be a perfectly nice, good person (or organization) and still not be your cup of tea. Changes are significant, however, because once you've changed the culture, people no longer have the company they love, and people not only lose motivation, people start leaving - whether they're customers or employees - and that's seldom a good thing. Note 5

When the people most invested in the success of an organization - like employees - leave because the culture has been damaged, there are likely to be repercussions that ripple out in ever-widening circles, like those created when a pebble is dropped into a pond. If the damage to the organization's culture is significant enough, it's just a matter of time before that trend carries outward as far as customers. Whether the organization can repair the damage and weather depends on a variety of factors that are outside the scope of this brief essay, but in every case, the nature of the business will be profoundly changed. Whether that change is for good or ill is something only time can tell. If your organization survives by knowing their customers (or users), such turbulence can be exceedingly dangerous, and it is unwise to assume that it is not.

Now, to address the question of why this post, now.

Recently there has been a lot of interest in why I left a position I held for nearly a decade. Here is the best brief explanation I can offer - I left for the same reason the Beatles stopped touring - it wasn't fun anymore. Unfortunately, that explanation has frequently proven inadequate and I have developed a longer, but still brief, explanation.

Several years ago, I started what I believed could potentially be my last job in the industry. The work was challenging and interesting, the people were, as they say, "wicked smart" and immensely talented, the product was an economic product geared toward serving under-served populations, and the general corporate culture was based on four basic values that resonated with me. It was, in a lot of ways - very nearly every way in fact - the perfect fit. Over the course of the next several years, things changed - as things do. The work became mundane as my skills were under-utilized, the vast majority of people moved on, and the product and culture changed significantly. The organization was not the same organization with which I had fallen in love, and I finally came to recognize that all the perks and incentive programs were metaphorical chains that bound me in place.

As a result of changes that transformed the organization from something I loved into something that I didn't, I left - and yes, it was before finding another gig - because I'm a firm believer that when you see it's time to go, you put your affairs in order, raise your sails, and go. Now, three months past my departure, I still have a sense of what I've lost, and yet there are times that, like the song says, I'm "too relieved to grieve" Note 6  because, in the end golden chains are still chains (Robert's Rule #33).

Notes and references

Links in the notes and references list open in a new window

1. Brian Chesky is the founder and CEO of Airbnb. You can learn more about him on wikipedia.
2. You can learn more about Peter Thiel, an outspoken entrepreneur and venture capitalist, on wikipedia. 
3. The Vehicle Identification Number is an alphanumeric sequence used to uniquely identify a vehicle.
4. A summary of a journal article in the Harvard Business Review says it clearer than I've seen it said before - "according to numerous studies in laboratories, workplaces, classrooms, and other settings, rewards typically undermine the very processes they are intended to enhance."
5. There are a number of reasons it's not good when people leave an organization - brain drain and the ills associated with turnover - hiring costs, overtime costs, low morale, and low productivity to name just a few - are just two of the big reasons.
6. "Let It Go" (Kristen Anderson-Lopez and Robert Lopez) as performed by Demi Lovato.

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/

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."¹ 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?

Success is built on better than "good enough" (Robert's Rule #30)

One of the great things to have been developed for user interface engineers (or web developers, if you prefer) are JavaScript libraries. As someone who's been writing web pages and creating sites since the mid-1990s, I can say that JavaScript is pretty cool, and not needing to remember which parts work in which browsers - something that the libraries get right - can be pretty awesome.The downside to the advent of the libraries though, is that they have, at times, made development too easy and we have become complacent at best, and often lazy (there, I said it).

I've written other posts about the benefits of striving against constraints, even those that are artificially created, and I've not been quiet about my disdain for code that performs poorly either. While quality and performance are good topics in themselves, they are not directly the focus of this post...even though I will use a conversation with colleagues regarding performance.

When critiquing a portion of code, I have been approached by those who argue, and with some cause, that if a particular block of code executes in less than 1ms its performance is "good enough".

This concept of "good enough" is dangerous. While I'll agree that such code may perform better than other approaches an engineer may have used - it may even have better than average performance - what are we really saying when we say it's "good enough"?

Perhaps it will help to mention that I tend to think of my code, not so much in terms of "good enough" but rather in a stable evolutionary stage - primarily because "good enough" implies if it does not evolve further, that would perfectly acceptable. "Good enough" implies that we can get better [insert your property here] if we kept working, but we're not going to keep working because it's acceptable.

While I'm familiar with the Law of Diminishing Returns and the 80/20 Rule, frankly, as someone who's been developing software for more than two decades, one of the biggest problems I've seen in the industry is this very idea of "good enough". Even if I were to ignore thought around exploring outliers to improve our code, in my experience "good enough" tends to be what we say when something other than the customer is given priority.

Enough theory...let's have a real world example and see if we can tell the difference between "good enough" and "best". (Note: for this example, I'm going to use one of those JavaScript libraries I mentioned earlier - specifically, the YAHOO! YUI library - because it will help show how we tend to become complacent.)

How the "good enough" code (very nearly) lives in the wild:

MyObject = {
  element: document.getElementById("mylabel"),

  highlight: function() {
    YAHOO.util.Dom.removeClass(MyObject.element, "mask");
    YAHOO.util.Dom.addClass(MyObject.element, "hilite");
  }
};

...and how better code might live in the wild...

MyObject = {
  element: document.getElementById("mylabel"),

  highlight: function() {
    this.element.className = this.element.className.replace(/\bmask\b/, " hilite ");
  }
};

Of course this snippet, while faster also makes the potential errors apparent. While it's also "good enough" we can do better...

MyObject = {
  element: document.getElementById("mylabel"),

  highlight: function() {
    if (this.element) {
      this.element.className = this.element.className.replace(/\bmask\b/, " hilite ");
    }
  }
};

...and if your code is going to be used by others you should make your private members private...

MyObject = function(id) {
  var element = document.getElementById(id);

  this.highlight = function() {
    if (element) {
      element.className = element.className.replace(/\bmask\b/, " hilite ");
    }
  }
};

...and finally, if you want to actually unit test your code, return a value like this...

MyObject = function(id) {
  var element = document.getElementById(id);

  this.highlight = function() {
    var ret;
    if (element) {
      try {
        element.className = element.className.replace(/\bmask\b/, " hilite ");
        ret = (/\bhilite\b/).test(element.className);
      } catch (err) {
        ret = null;
      }
    }
    return ret;
  };
};

While our first example from the wild is "good enough", it's clearly not as good as it could be, and even worse, writing a unit test to validate it becomes onerous. On the other hand, by going further...by doing better, we can achieve not only better performance and greater reliability, but also improved quality and maintainability - all of which combine to make a better user experience, and a better user experience is what helps make our application a success.

That's why we say success is built on better than "good enough".

It's not the fall that kills you, it's the sudden stop (Robert's Rule #29)

Years ago...and I suppose I might more precisely say decades ago...I climbed rocks. Granted, they were rocks that were very large and were the sides of a gorge that was hundreds of feet deep, but they were still rocks. Anyway, one of the concerns that people often expressed went something like "aren't you afraid you'll fall" or "you could die in a fall". Being young, and convinced of my immortality because of my youth, I was not concerned about falling...after all, I was careful and, as I often replied, "falling doesn't kill you, it's the sudden stop at the end that kills you". In essence, it isn't a fall that kills you, it's the not falling.

So, how does this apply to technology, or more specifically, to application development? If we rephrase this idea, by replacing "fall" with "fail" (which doesn't really change the meaning - after all, a fall while climbing is a failure - at least to climb), then we can say that it isn't the 'failing' that kills you, it's the 'not failing'.

If it's still not clear, then let's look at a concept from extreme programming (something that was in vogue a few years ago) called "test-driven development". Here's the basic idea: write a test that you know will not pass, write the minimum amount of code that you think will make the test pass, run the test, modify the code and run the test until it passes, refactor the code to make it conform to standards. (You can find a more thorough description of test-driven development at Wikipedia.) Note: I suppose it's a bit of semantic gymnastics, but even though we generally say the test 'fails', our expectation is that the test 'fails' - so what we really mean is that if the test returns a negative result it has succeeded.

As I've mentioned in previous posts, more code is not the answer, and writing code is similar in many ways to other forms of writing - it should be clear and concise. The easiest way to develop clear and concise code is using test-driven development. Of course this also means that since you develop unit tests at the same time as your code, quality is much easier to ensure - which is important in itself.

Granted, there is much more concerning this topic that we could explore...there are rabbit holes to go into all over this landscape, and I would encourage you to follow one or two of those to see where they lead. As a practical matter, however, I am solidly behind test-driven development and have combined two widely accepted engines to facilitate test-driven development for web developers writing JavaScript. This tool (called GARDA) is free to use, and will soon be available for download so you can run it locally. So, use test-driven development to climb to the heights of your ability, remembering "don't fight stupid, make more awesome".

Try to pop the clutch on a paradigm shift. (Robert's Rule #28)

A lot is said about being a "disruptive force", especially in relation to technology. In fact, so much is said that often "disruptive force" becomes a buzzword thrown around without understanding, and when we're not talking about the next "disruptive" thing, we're calling something "revolutionary", which is equally buzz-worthy. So, let's take a look at what being disruptive or revolutionary really means.

In order for something to be revolutionary, i.e. bringing about a major/fundamental change, it must be disruptive, i.e. interrupt the normal course or unity. In philosophy terms, "disruptive" is a necessary condition for "revolutionary", and the greater the interruption, the more likely to bring about a major change.

One of the greatest factors against the degree of disruption necessary for something to become revolutionary is the inertia of prior changes. We see this in some degree in technology daily in attempts to overcome adoption of some previous (legacy) technology. In these cases, it is helpful to remember Newton's Second Law, namely F = ma (otherwise recognized as "force equals mass times acceleration").

When analogously applied to our general understanding of disruption, Newton's Second Law indicates that the force of the disruption is equal to the degree of change multiplied by the speed with which the change is introduced.

So the question becomes, as a practical matter, "how do we affect change?" The most direct answer is to see the constraints around which something was designed and change the environment in a way that those constraints no longer exist. Such change is disruptive, but it may not be enough. In answer to this, we can affect the "mass" of change by altering or removing multiple constraints, or we must adjust the speed with which change is introduced. In the early 1990s I started describing this manipulation of change as "popping the clutch on a paradigm shift" - which now seems a little dated and has lost some of the connotation it once carried considering the proliferation of automatic transmission automobiles, but I digress - a little.

Let's look at two examples of revolutionary changes. In our first example we see changes enabling broadband radio transmission, shrinking circuit board sizes, and shrinking battery size which increasing life and power - each a relatively minor, evolutionary disruption - which when combined have the "mass" necessary to affect change bringing about a revolution in communication with mobile phones. It is almost difficult to recall life before that revolution, as it didn't just introduce a new way to communicate, it allowed communication in such a way that the old way of communication no longer made sense. Gone are pay phones (previously a significant source of revenue for telecommunications companies) and landlines in several homes, and rural areas are more accessible. In our second example, if we look at the introduction of the Android OS, we can see that the speed with which it was introduced to the market really gave rise to the smartphone. Oh, there were other smartphones, but the market was relatively stable with Apple and RIM, and then the Android came along and now the smartphone market has exploded. That explosion has begun a revolution, and we are only seeing the beginning of the changes to come as a revolution in communication reshapes the world.

We, as technologists and engineers, want to be revolutionary; we want to build the better mousetrap or reinvent the wheel. Therein lies the rub - because truly revolutionary technology doesn’t just do something in a new way - it's not just disruptive - it does something in such a way that the old ways of doing it no longer make sense, so we must try to pop the clutch on a paradigm shift.

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.

A lot in life is like a Wookie (Robert's Rule #25)

A lot in life is like a Wookie: hard to understand, very hairy, and can rip off your arms and beat you to death with them. (Robert's Rule #25)

Summertime for me is generally a very busy time. It's during this time that into the work/life mix are thrown not only the daily work/life challenges like how to make sure the laundry gets done and the bathrooms get cleaned but also additional things like children being on summer break and the resulting coordination of child care and the planning, scheduling, and taking of a summer holiday (not to mention trips to see family et cetera that really are 'holidays'), and when you travel with infants or toddlers such trips are whole projects in themselves.

Of course that's just the time that work activities seriously ramp up before we head into a release moratorium for the holidays as projects that were originally estimated to take 30 developer days are crammed into 5, and, the reasoning goes, since each 30 day project is crammed into 5 days, we can do 6 such projects. Thus, as the pressure from work mounts and you attempt to maintain work/life balance, you will undoubtedly come into conflict with those above you in the corporate chain and you will likely lose.

"That's life", they say, or "at the end of the day, that's what you have to deal with" as if a cliché will somehow make it more palatable or at least easier to endure. Here's the difficulty: as engineers and scientists, we expect, at least subconsciously, that life is somewhat orderly and something of a meritocracy where people compete like ideas and the best advance according to their abilities, just as ideas advance according to how well they are proven using scientific methods. To further add insult, we're taught as children in America that this is, in some degree, the reality as we celebrate those who work hard (either at sport or academics).

While there are those who recognize the failings of our educational system (in that it reinforces idea that our democratic republic is on some level a meritocracy), there are those who refuse to believe that we can be what we want to be and do (for the most part) what we want to do. There are those who recognize that even if we sincerely want to rescue the princess and make a daring escape while being pursued by the dark lord, we cannot - not even figuratively. Thus, the honest answer, as you've no doubt learned by now, is that the idea that our society or even our employer is a meritocracy is not even close to true. Those above you most likely are not there because they deserve it more than you, they are there because they played it more than you.

So, in your career, in this little game of whispers and thrones, learn who the Wookies are and let the Wookie win (First Corollary to Robert's Rule #25), because while no one worries about upsetting droids (scientists and engineers), in the words of the immortal Han Solo, "that's 'cause droids don't pull people's arms out of their sockets when they lose".

Don’t be the one who shoots second (Robert's Rule #24)

So, who shot first, Han or Greedo? We all know that Han did, right? He may be a smuggler and a total cheat, but he's no fool...right?

Here's the thing. We hate change. All of us. We hate change so much that addressing change is even built into our religions in one form or another, whether our religion insists that the supreme being does not change or whether our religion promotes the idea that it is our response to change that is problematic. Only one thing is clear - since before Heraclitus' proclamation that no one steps into the same river twice, we have recognized that change in the human sphere is inevitable.

"What", you may ask, "does that have to do with Han and Greedo"?

Han and Greedo had met before and though Greedo had been humiliated in the past, this meeting was decidedly different. Greedo was prepared to shoot Han; however, Han also knew this meeting represented a change in behavior and shot Greedo.

We all face changes in jobs, technology, and lifestyles that affect our career. The trick is to know when to pull the trigger and do things differently. For some changes, the trigger will undoubtedly get pulled for you rather than by you, and in some cases you'll likely be on the wrong end of the blaster and be left in the cantina. Try to minimize those instances. Wait until the last moment if you must, but don't be the one who shoots second. (Robert's Rule #24)

If people aren’t getting a point, use smaller words or a louder voice - it’s patronizing but they won’t get that either (Robert's Rule #23)

Engineers are generally thinkers. There are those times, however, when we are certain we've thought a problem through and really don't want to be annoyed with the facts. In times like these, meetings where there are more than one point of view - meaning my (right) point of view and the (wrong) point of view everyone else has - can be difficult

In those meetings it's important that a few things occur in order for you to be successful. First, if people aren’t getting your point, you should use smaller words or a louder voice - it’s patronizing but they won’t get that either. Second, you must keep your composure. If you lose your composure, nothing else will matter, because most will dismiss you as emotional (as opposed to rational). Third, you must monitor the quality of any decisions you make in a heightened state of agitation.

Remember, you're facing a serious threat in these heated meetings, these are serious dangers. A misstep in this area is one of the most effective means of destroying any image you may have as a politically savvy team-player as well as a thought-leader.

I know it seems obvious, and you probably wouldn't believe the stories of meetings I've been in that have descended into shouting matches, or worse, into cold, dismissive, condescending, passive-aggressive olympic-quality events.We, as a member of a team, can only be our best when we not only are contributing but also recognizing how all of our teammates look up to us.

Ok, enough channeling Machiavelli's Prince.

There will be times when you are the big fish in a little pond and your teammates will look up to you as the expert. There will be many more times you will be the medium (or more likely, small) fish in a large pond and doing anything other than keeping your composure and working together to resolve the conflict will get you derisively labeled a 'big fish'. So, keep the rule if people aren’t getting a point, use smaller words or a louder voice - it’s patronizing but they won’t get that either (Robert's Rule #23) in mind as well as keeping in mind that the rule that is really an anti-pattern, unless you really want to be a 'big fish'.

Know when to say "that'd be worth a whoopin'" (Robert's Rule #22)

In my family history, the tale is told of one particularly mischievous child who, after considering the possible consequences of a specific action would say "I believe that'd be worth a whoopin'" (a "whoopin", for those uninformed in southern American slang, is similar to a whipping but is given with anything close at hand - a belt, a switch, kitchen utensils, et cetera).

We are faced with decisions every day.  As technologists, the decisions that we face often have consequences which reach much further than those of other decisions. As leaders, one of the most cowardly things you can do, and one of the things that will destroy the morale of your team, is to try to deflect the consequences of your decisions, a technique commonly referred to as "throwing someone under the bus".

Make no mistake, there will be times in your career when your work, and life, will laud you for visionary thinking and there will be times when work, and life will punch you in the face, hard. Whether lauded or castigated, of one thing you can be sure, there will always be consequences.

While I know that most civilized people have moved beyond corporal punishment, my ancestor's concept still holds some validity, even when the 'whoopin' is metaphorical. Consider your options and make your decision. Just know when to say "that'd be worth a whoopin'" (Robert's Rule #22).

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.

Don't play Jenga® with the code (Robert's Rule #20)

[Tweeted 2011-06-17]

Often code is developed in concert between many developers. In times like this we all hope that the code is well-documented and is written in a style that is easily readable. Unfortunately, this is not always the case, but even when it is the case there is still a danger because seldom is production code so clean or simple that every developer understands all aspects of it. A good example of this is code for web applications, especially front-end code in JavaScript.

JavaScript is deceptive for a number of reasons. First, it's similar enough to Java that engineers who work in both languages will sometimes get confused. Second, it's strengths (or weaknesses, depending on your perspective) allow poor writing. Third, while it's possible to simulate multi-threaded programming, there isn't anything that's considered thread-safe. This last point has, in my experience, been the most challenging because it has the potential to create race conditions...on steroids.

Because of its deceptive nature, to say that debugging front-end web code can be a challenge is a bit of an understatement. One approach, often used with linear programming, is to comment out code while stepping through it to see where the defect lies. Unfortunately, this plays right into the language's deception by creating the equivalent of a red herring, and with it the potential for disaster.

In those cases, it is always best to not only keep exact notes, including a time stamp, when attempting to reproduce the defect. After completing several tests, search the code to find the handlers for the actions taken while simultaneously examining the logic within the event flows. Finally, make sure that at least one person on your team is intimately familiar with each codebase so they can act as a resource. It is only by pursuing a course of action similar to this that you follow Robert's Rule #20, don't play Jenga^® with the code by pulling out pieces that you believe to be the problem only to have the application crash to the ground.

Don't be afraid to be wrong (Robert's Rule #19)

[Tweeted 2011-06-14]

I know it seems pretty obvious, but leadership is leading. You would think that this doesn't need to be said, but often it does, because apparently we forget.

You might be amazed at just how many people in the industry are unwilling, likely because of office politics, to step out on a limb. Sure, you could be wrong; but you might not be. Since this isn't really about being ill-informed, we'll assume that you're doing more than making lucky guesses, but even if you're not, if you're not making judgements and, more importantly, letting people know what those judgements are, you're not leading.

What's the worst that could happen if you express a reasoned judgement and you're wrong? It's usually not as bad as you think. (Remember, we're assuming that you're just wrong, not ill-informed and wrong, because that's another problem.) Some of the world's greatest minds were wrong; some of them were wrong frequently. So, we're (most of the time) talking about other people knowing you were wrong...and if that's the case then this may come as a surprise...everyone is wrong sometimes, and you hiding that you're wrong doesn't mean other people think you're never wrong.

On the other hand, what if you hide your judgement all the time? If you hide your judgements people won't assume you're right all the time, they'll assume that you believe you don't know enough to make a reasoned judgement or that you're too afraid to express your judgement for some other reason. Generally, neither of those are well-received in scientific or engineering communities.

So, make a reasoned judgement, learn to express the judgement in a manner that reveals your reasoning, and most importantly, don't be afraid to be wrong (Robert's Rule #19).

Trust everyone at the table, but cut the cards anyway (Robert's Rule #18)

[Tweeted 2011-06-06]

Living in an area where there are multiple casinos within a short drive or a long walk, I've learned to see some things using gaming metaphors. One of these metaphors is trust everyone at the table, but cut the cards anyway (Robert's Rule #18), and if you are an empiricist like Hume, then this rule will automatically make sense.

How does it apply to work? First, if you are not able to trust your colleagues, work (and probably life) will be miserable. Of course the reverse is also true; trusting your colleagues will go a long way in making work not be the worst part of your life. In fact, I've had some jobs I should have hated because they were such a poor fit and yet I didn't because of my colleagues.

Second, not only will the inability to trust your colleagues make life miserable, it will be very difficult to accomplish what you need to accomplish as well. The amount of time you spend countering the machinations of office politics in a hostile environment will outweigh whatever other successes you have. In addition, those times in which you don't succeed your discomfort will be worse because of the negative self-talk that comes out of the lack of trust and your assumptions about yourself.

Of course, this doesn't mean that you should just blindly trust. After all, your trust can be pretty easily misplaced, and this is your livelihood we're talking about here. You can't just go about willy-nilly assuming that everything your colleagues do and say is true, and even a series of lucky guesses ends sometime, which is a very good reason to confirm what you believe to be true.

Of course all of this is to say trust everyone at the table, but cut the cards anyway.

Too often 'we can' erroneously becomes 'we should' and 'we will' (Robert's Rule #17)

[Tweeted 2011-06-03]

Once upon a time I was in a meeting in which we discussed a web application that was scheduled for deployment in the immediate future. As we were working out the implementation details, we came upon the issue of needing to access private, restricted, highly confidential information.An additional wrinkle was the need for the database to be maintained by the system of record, which was on the internal network.

As we were discussing the options, one person (I'll call him n00b) suggested that we could easily solve the problem by joining the server to the DMZ and the internal network simultaneously. My response was an immediate "no, we can't do that". "Oh yes we can", the n00b replied. "All we need to do is install two network cards and use one for the DMZ and one for the internal network." In honesty, I was not the first one to laugh out loud, my manager was.

The n00b was insulted and said that he had used this approach for one of his clients (outside of work) and so I ended up telling him that what such a plan would do is create a bridge between the DMZ and our internal network, making not only the database server vulnerable, but the internal network as well. The n00b had a few more, equally appalling suggestions, but in the end the group, collectively, brought him to a measure of enlightenment.

Of course we had the technical ability to do what n00b suggested, just like I've had the technical ability to do hundreds of other blatantly stupid things and several more that weren't quite blatantly stupid (even if they were of equally questionable value).

Perhaps more disturbing than a n00b fighting for a bad idea is that if the n00b had been higher up on the food chain, rather than the n00b he was, the situation might have turned out differently. I've certainly been in situations where I've known what was asked was a bad idea and would even likely turn to bite me in the nether regions, and still I've had to implement the bad idea because 'the decider' made the decision.

We all face such situations; in fact, they're far from uncommon. This is why Rule #17 states that too often 'we can' erroneously becomes 'we should' and 'we will'. Robert's Rule #17 is simply a recognition of a sometimes disturbing truth we, as technologists and engineers, live with every day.

No matter how many Novices you add, they'll never equal one Expert (Robert's Rule #16)

[Tweeted 2011-06-01]

One of the typical responses to a project that is behind schedule is to add people to the project with the intent that they will be able to further subdivide the work and develop in parallel, getting the project back on track.

This, of course, is part of the problem in defining software development project timelines using straight developer days or 'man months'. Part of the difficulty lies in the idea that all tasks can be subdivided (hence the concept of the 'mythical man month'). If we apply the idea that all tasks can be subdivided to areas outside of software development, such as pregnancy, then the erroneous conclusions become obvious; after all, we all know that 9 women cannot complete a pregnancy in 1 month.

One of the other, lesser known aspects of Brooks' law is the concept of a 'surgical team' which identifies 'good' developers and 'the rest of the team'. While I won't go into all of Brooks' concepts in detail, this concept deserves special consideration, in part because Brooks estimates that 'good' developers are 5 to 10 times as productive as mediocre developers. In addition, if we factor in the effects of a higher degree of skill on quality we can easily see the error of our ways.

So, next time you're trying to get a product out the door and it's repeatedly behind, remember that not only does it matter how many people you add, no matter how many Novices you add, they'll never equal one Expert (Robert's Rule #16).

Code reuse without grasping the how is ill-advised, but code reuse without grasping the why is dangerous (Robert's Rule #15)

[Tweeted 2011-05-17]

One of the 'big ideas' in software development is code re-use. It's so big, in fact, that coding for it (called inheritance) is a cornerstone of object-oriented development.

"Wait", I hear you say, "inheritance isn't the same as code re-use", and you would be correct, mostly. Inheritance isn't strictly code re-use; however, I would argue that the reason for having a model for inheritance is to simplify and encourage code re-use. However, that discussion is really for another time, because Rule #15 is not about how inheritance and code re-use are related, in fact, it's not about inheritance at all.

One of the things that I discovered when creating JavaScript libraries is that while it's more difficult to create true public and private members, it is important if other developers are going to be using your code. The prototype model that we often use when creating JavaScript objects can have unintentional side effects, namely the risk that another developer will partially understand our code and accidentally modify a private member. Of course, when a private member is modified the risk for error greatly increases. This is really an issue in the 'how' of code re-use, because if the other developer knows how to re-use the code these errors can be avoided.

There is another, more dangerous situation, however. In this situation, the developer may know how to re-use our code, but doesn't fully grasp what the code is intended to do. In other words, they fail to grasp the why of the code (as in why is this code used solve a problem). A good (albeit simple) example of this is the difference between calling

var i = Math.floor(myfloat);

and this

var i = Math.ceil(myfloat);

function, even though both return an integer. Now, granted, this is an extremely simplified example, however, it is one in which it's easy to see the implications of reusing code without understanding why the code was written in the way it was and it's easy to see why Rule #15 is code reuse without grasping the how is ill-advised, but code reuse without grasping the why is dangerous.

If, at this point, you're wondering how this example could be dangerous, an easy answer is that it likely isn't. After all, the variance is at most one; however, if instead of these functions we were discussing encryption it would be easier to conceive of an instance in which simple reuse could prove dangerous.

So, before reusing code, be sure you understand the why and not just the how.

Just as music is sound and not-sound, so is code defined by what it does and does not do (Robert's Rule #14)

[Tweeted 2011-05-17]

One of my least favorite topics while at university was aesthetics; however, it was also probably one of the most informative. While talking about music, for instance, we discussed how music is both sound and the absence of sound; how the space between the (musical) notes is as definitive as the notes themselves.

This concept can be applied to many things in life and is such a universal principle that Alfred North Whitehead even references a similar concept in his tome on metaphysics when he talks about negative prehension. However, since in many ways writing software is similar to composing a piece of music, it is my belief that this concept applies even more directly to software development than other areas, which is why Rule #14 is just as music is sound and not-sound, so is code defined by what it does and does not do.

Therefore, when you start designing your application, set clear boundaries to establish the key and time signature in which you will compose your grand opus, and begin. Let the music fill you and listen for the spaces between the notes.