A reactor is known as a “breeder” if it produces more fissionable material than it consumes

During a recent round of interviews we asked candidates to point out the problem with the following code snippet

for($i = 0; $i < 10; ++$i)
  if ($i = 0)
    print "yes";

This was intended as a simple, spot-the-typo, exercise. The problem is if ($i = 0), should read if ($i == 0)! As is, it's an infinite loop, and the follow up question is to ask if it's infinitely printing "yes" or not.

Relatively easy and straightforward. What happened in the actual interviews was anything but straightforward. Without fail, candidates kept pointing out the pre-increment ++$i. My first thought was to put them back on track, because "no, that has nothing to do with it." Instead I decided to explore.

"Wait, tell me why the pre-increment would be a problem?" I asked curiously.

Every candidate seemed to have a different explanation for why a pre-increment wouldn't work. I would then ask them to walk through the execution of the loop. And this was the mistake that each candidate shared, they didn't know how a standard three-expression for loop worked.

Stubbornly, many would insist that the pre-increment would be run first, before the assignment statement. I would ask, "so the execution order of the three expressions is dependent on the third expression?", hoping they would see the absurdity in such a claim. "Yes," was the confident reply. sigh

"No," I would explain (feeling a little defeated), "the first expression is always executed first and only once, the third expression is only executed after a loop iteration."

I would go on to explain that the pre-increment works perfectly fine. In fact, there is some argument that it is more efficient since it is not creating temporary variables (a post-increment will create a temporary variable to hold the original value that is returned from the statement). Either way, in the context of a three-expression for loop it makes no difference; whichever method lends itself to better readability in your code should be used.

None of the candidates who missed this question were considered for a position.

And what did I learn? That we should use foreach with Iterator objects, and I'm switching to Python!

I was reading about Dual-coding Theory, which states that visual and verbal information is processed on distinct and different cognitive channels. The verbal cues refer to symbolic codes; in other words, arbitrary representations of something (such as reading or listening to a speech). The visual cues are perceptual, that is, a direct representation of what you are seeing.

Dual-coding refers to utilizing both visual and verbal, that is, symbolic as well as perceptual codes. Memory seems to favor the visual channel, and this is known as the picture superiority effect.

Think of watching the presidential debates. The information is symbolic (through words) as well as visual. What we remember tends to favor the visual, which can then act as a voluntary trigger to retrieve the words.

This is an interesting concept, and taken further leads to synesthesia– a rare phenomenon where one cognitive pathway triggers another involuntarily. For example, someone with synesthesia may see numbers in different colors; or see musical notes. And not a voluntary association, but a completely involuntary reaction. The advantages should be obvious, such as encoding symbolic information into long-term memory as easily as a visual information.

I wonder, if with the right training, we could develop in ourselves something like synesthesia; associating visual/perceptual codes to symbolic codes — allowing perceptual representations of abstract concepts.

We tend to do this naturally with metaphoric associations, such as an emotional reaction to an image or sound. I suspect we can take this much further, where we directly leverage perceptual codes to involuntarily trigger any number of symbolic/abstract information (whether emotional, or intellectual, or artistic)

One of the most interesting and oft-cited cognitive heuristics is the Anchoring and Adjustment heuristic. A fascinating example is the mock auction biased by the last two digits of the participants Social Security number:

Dan Ariely, professor of management science at MIT Sloan School of Management, conducted a mock auction with his MBA students. He asked students to write down the last two digits of their Social Security numbers, and then submit bids on such items as bottles of wine and chocolate. The half of the group with higher two-digit numbers bid “between 60 percent and 120 percent more” on the items, says Ariely. [1]

A similar heuristic is the Affect heuristic. An “affect” in this case is a feeling of “good” or “bad”, a simple emotional response to any stimulus. An interesting examples of an Affect heuristic is the positive correlation between New York City weather and major stock indexes. [2] In other words, the affect of the weather on investors effects asset prices. A not so subtle reminder of how irrational our rational minds behave.

Much has been written about overcoming and compensating these types of cognitive biases. I would like to propose something radically different. Embrace these biases, use them to your advantage! The beauty of these mental heuristics is that even when we are aware of them, we are still victims to these biases. I’ll write more on our bias blindspot in a future essay.

Everything you do, whether you like it or not, is already anchored. Various inputs, including the weather, create an anchored affect and biases every judgment throughout your day. It’s self-centered and lazy to go through life at the whims of the weather, and everyone else’s mood.

Before you go into an important meeting or negotiation, be prepared with an anchor. And not just to anchor other people you are talking to, but anchor yourself! And it’s easy– the anchor need not have any relevance. A positive anchor is anything that makes you happy and provides a “good” affect, and a negative anchor is anything that provides a “bad” effect. This could be a picture you carry, a song in your head, a vivid memory, anything. It doesn’t even need to be in your conscious awareness, so perhaps carefully selected background music might be appropriate while you are working.

The key is to recognize when to employ a positive affect and when to employ a negative. A positive affect is likely not a wise choice if you are negotiating for a low price or trying to assess risk in a project. Likewise a negative affect could be devastating if you are trying to sell an idea or discover something new.

References

1. http://www.cfo.com/article.cfm/3014027
2. http://heuristics.behaviouralfinance.net/affect/Saun93.pdf

The Autism Research Centre at the University of Cambridge recently released a fascinating paper on LEGO therapy. You read that correctly: LEGO therapy! Awesome! The study involved 6-11 year olds with either high functioning autism and/or Asperger Syndrome. [1]

I am suddenly reminded of my own awkward social skills as a child and how amazing it would have been to actually receive therapy involving LEGOs rather than punishment for not paying attention to anything except LEGOs.

LEGOs are like crack if you have Aspergers. On one hand it can be an amazing tool to motivate social interactions and develop spatial reasoning. On the other hand, it’s kind of a cruel joke taking an obsessive detail-oriented ‘perger and putting them in front of LEGOs– a narrow area of interest to focus on without any required speaking or physical dexterity. To this day I continually resist the urge to quit my job and focus full-time on LEGOs.

I never considered the social implications of LEGOs; 90% of my LEGO experience was solitary and became a coping mechanism to deal with the depression from not having any friends. There were however several friends I made who shared my passion for LEGOs — it’s possible that those were crucial moments helping me to overcome my social anxieties.

References

1. http://www.ncbi.nlm.nih.gov/pubmed/18566882

One of my coworkers likes to ask people to write 63 in binary when he interviews them.

Some of you might be thinking “that’s stupidly easy”, and many of you may be thinking “I have no idea and I hope I’m never asked that!”

There are many amusing answers to this request. Chief among them is to claim that they (in a computer or IT related field) have no need to know how to write a number in binary. That is the wrong answer. And shame on you for even considering such a thing — change professions immediately! If this question doesn’t appeal to you, then everything in Computer Science and Mathematics will seem like confusing magic and you’ll likely embarrass yourself on a daily basis. This is true for Project Managers, which is likely why so many PMs embarrass themselves all too often.

The correct answer, of course, is not to blurt out the binary string without even thinking, that would appear arrogant at best and cheating at worst. The correct answer is to either write or visibly start plotting out successive powers of 2, and upon reaching 64 (1000000) quickly slap your head at the realization that 63 is, in binary, 1 minus 1000000 therefor 0111111. You get partial credit for knowing, but demonstrating that you realized it was a silly question will get you full credit.

Now here is where the interview can get interesting. Why would a number like this be useful? What would happen if I bit-shift left or right? Suddenly a basic understanding of Boolean logic and Computer Science are uncovered! And at that point it becomes clear who is storing IP addresses as varchars and who is storing them as integers.

As I was cleaning up old files on my server I came across several old college projects. One of them contained several Java applets for fractal visualization — circa 2002. While I cringed slightly at the writing I was impressed with the mathematics that I have since forgotten! Like, what the hell is IFS and why am I calling it non-deterministic? Apparently, it’s a random iteration algorithm where I assign probabilities to each function in an IFS (Iterative Function System). An IFS is a set of affine transformations, and in this case each transformation is assigned a probability– Obviously!

There’s also some classic Mandelbrot and Julia Sets. Since several years have passed since this was all created, I’m interested in doing similar visualizations and not using Java. Java never really did catch on for client-side web applications. Although I do like the idea of doing the number crunching on the client side :) Maybe I’ll try it in Flash…

If interested, here is what is left of the old fractal page:

No one seems surprised to hear that most IT projects fail. One would think that the increasing number of delayed and over-budgeted projects would illicit some kind of existential crisis on the part of IT professionals. Many projects sustain on life support missing nearly every milestone, either to eventually die or find some inkling of success (albeit at a cost that no one would have agreed to at the start of the project). Repeating the same mistake over and over it points back to one thing: requirements. What the hell is this thing suppose to do?

Arguably, there are technical issues, people issues, and various reasons IT projects fail. There are however, necessary components to success (conversely, guaranteed failure) and all of them start with requirements. And I don’t mean the kind of vague nonsense requirements espoused by analysts (e.g., “make it work with Siebel”), I mean the rigorously defined requirements that most of todays analysts and IT consultants couldn’t write to save their lives.

Requirements

I have been apart of enough projects to have seen the failures and successes that are common in this industry. Examining the failures there is a common theme: lack of good requirements. Not lack of documentation, not lack of specifications or attempts at requirements. Attempts were made at requirements in almost all cases, but failures persisted in every situation where the requirements were vague, ill-defined, or unrelated to the business needs.

I have worked on such gems as “build an end-to-end data architecture”, or “add live flash streaming”, or “integrate at&t”. These type of things always missed their deadlines and expectations. It’s surprisingly difficult to meet expectations where none were set; in the IT world anything delivered in that situation will be wrong and likely your fault. Worse, if the management is poor then the lack of requirements slides downhill onto the engineers who didn’t think it was their problem.

The problems can be seen a mile away. The difference between the professional software engineer and most of the developers occupying IT roles these days is that the professional engineer will not commit to any deadline without clear well-defined requirements. Any amateur can promise an “end-to-end data architecture”; but the professional will make no promises without requirements that he or she can work from.

In many cases, just the exercise of defining requirements would lead to the realization that the project isn’t feasible and in some cases doesn’t even need to exist. Better to know up front that your project will fail than wait months or years later, right? Not if you want to keep your job, but yes, if you want to work on successful projects.

Having well defined requirements will not ensure success, but it avoids a guaranteed failure.

Managing Success and Failure

Most IT projects like to track risks, but where is the failure tracking? Perhaps it’s too negative to go around tracking how a project could fail. Call it Success Tracking so as not to offend ‘the law of attraction’, but a clear definition of success and a scientific approach to understanding how the project could fail would save most doomed IT projects.

Without well-defined requirements this exercise is difficult if not impossible. How do you define success or failure if the requirements are not rigorously defined? Without an understanding of success your left only with failure.

Quality Assurance

Yet another tried and tested method for killing a project is a weak or non-existent QA process. There is no panacea to software development woes, but a QA process is a necessary component to success. Further, QA is impossible without well-defined requirements. Yet in many IT organizations there are QA teams working tirelessly to assure the quality of products without any clear requirements. What kind of quality are they assuring? What does it mean to pass QA without a requirement? It’s like a scientist doing a test without a theory…

Any amateur can toy with software to assure that it works the way the developer told them it works. A professional QA engineer follows the same guidance as the professional software engineer: they will not commit to assuring the quality of a product that lacks a well-defined requirement.

Required

IT projects require well-defined requirements. IT professional wishing to avoid the same repeated mistakes will formulate requirements before committing to dates. As an engineer, I am happy to work on R&D in the absence of clear requirements and with the understanding that there is no date and no committed deliverables in that phase. In most organizations this can seem an impossible feat, but this is where we separate professionals from amateurs.

REFERENCES

http://www.pbs.org/cringely/pulpit/2008/pulpit_20080418_004737.html
http://www.computerworld.com/managementtopics/management/project/story/0,10801,84266,00.html
http://www.onlamp.com/pub/a/onlamp/2006/06/20/why-do-projects-fail.html
http://www.spectrum.ieee.org/sep05/1685

Aloha –
Welcome, greetings, farewell, goodbye, love, mercy, … (Hawaiian)

Akamai –
Smart, clever, expert, skill, witt, … (Hawaiian)

I started a new job with Akamai Technologies. They have a small San Diego office and from what I can tell, it’s a very bright and motivated team with technical aptitude to match their creativity. A positive group with complex challenges that I’m excited to dive in to!

Buddhism has a concept of “right thought”, of freeing your mind of lust, ill-will, and cruelty. I’ve been thinking a lot about this lately. We surround ourselves with people that often reflect our own dispositions of thought. The environment we find ourselves in, for better or worse, is of our own doing. In many ways, this phase of my career represents a welcome “right thought” and I realize that “right work” is a necessary path to that state of mind.

And to my friends and family who have never heard of Akamai; you use their services all of the time without even knowing it. Primarily known for their content delivery network, which is a grid of compute and data resources covering multiple Internet backbones optimized to deliver content, to you, the end user. In other words, when you’re watching some cool video on myspace or previewing film trailers on apple.com, the content you’re watching is being managed by Akamai.

http://www.akamai.com
http://en.wikipedia.org/wiki/Akamai_Technologies
http://money.cnn.com/magazines/fortune/fortunefastestgrowing/2007/snapshots/48.html

We all hear about and we all love it: the Rugby-inspired software development methodology known as Scrum. It’s fast becoming an industry buzz-word and causing many project managers to question their Gantt charts. For all the hype, what is the reality of Scrum?

Scrum is an agile-based software development methodology for project management. It is characterized by a prioritized product backlog that lists new features. Work is completed and delivered in time-boxed iterations known as sprints (e.g., two week iterations). Scrum teams are cross-functional and typically number 3-7 people each. Iterations begin with an iteration planning meeting and end with a retrospective to review what worked and what didn’t.

During a sprint each scrum team gathers for a daily stand up, which is a short meeting where each person describes what they did since the previous meeting, what they’re planning to do now, and any impediments. The team is self-organizing leveraging our instinctive behavior to work in small groups. The Scrum process is facilitated by a Scrum Master. That title is a bit of a misnomer since the Scrum Master carries no authority and is instead responsible for blocking any distracting influences that could disrupt the teams progress.

The principles of Scrum are well defined in the wikipedia article as well as in the book Agile Project Management with Scrum by Ken Schwaber. You can also shell out ten grand for an in-person experience with Ken. There is nothing like an expert talking about the work that you should be doing. As some of my friends and co-workers like to hear me say: Get back to work!

What’s so Good about Scrum?

Delivering working software. Working software is where Scrum really shines. It’s proving to be an excellent implementation of Agile Software Development with core values such as customer satisfaction and individual interaction.

There are four core values to the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These are all valid principles that are easy to ignore and have proven to be hard learned lessons despite how obvious they may seem. Projects typically fail when they ignore these principles. Good documentation has never compensated for crap software. Try telling the upset customers that you gave them exactly what they contractually signed in the Service Level Agreement. The principles of the Agile Manifesto should be held as software engineering law.

Scrum provides a very effective methodology that ensures these principles through an empirical approach to software development that embraces and encourages change.

If it’s so great, what’s the Bad news?

No one likes to admit this, especially not Scrum advocates like myself, but Scrum fundamentally conflicts with traditional PMO. It’s an interesting round of cognitive dissonance to watch a PMI-certified project manager attempt to rationalize Scrum. There are of course several ways to deal effectively with this dissonance but understand: these are fundamental differences which are not philosophically compatible.

Scrum will go far in delivering working software, but what about managing roadmaps? Better yet, what about resource allocation and God-forbid budget forecasts that are needed before a project starts? We need money and people to start a project and we’d like to know roughly how much something will cost before we agree to invest. In a perfect world we would know these answers and we wouldn’t need Scrum. But Scrum exists out of necessity from the failures of so many software development projects and reminds us that the entire enterprise of software engineering is often times more like scientific discovery than building construction (which is where PMI originated, and rightfully so).

The Ugly

Scrum delivers working software in chaotic environments. At the same time Scrum is a symptom of a larger problem in software engineering such that many software projects cannot be managed like construction projects else they face increasing technical debt, unhappy customers, declining quality, going over budget, and missing deadlines.

Migrating to a Scrum methodology typically has an effect of providing early visibility to problems. The wisdom being that it’s better to know that you’re failing one or two months into a project rather than years. While this makes sense and this transparency is a very valuable aspect of Scrum the reality is very ugly.

Transparency to critical problems often times stems from the fundamental conflict of traditional PMO and Scrum. These are problems that are unfortunately outside of the realm of Scrum or software engineering. In this situation it is easy to attack the symptom (Scrum) than it is to address the underlying issue, which is unifying project management (roadmaps, budgets, resource allocation) with the software development.

Visibility? Be careful what you ask for! If a project is going to fail, maybe it’s better to let it fail naturally than to induce ulcers in the Scrum Masters and the development staff. Remember: a good Scrum Master will be a burned out Scrum Master in most environments.

This isn’t an easy problem to solve, but done wrong Scrum can create an emergent failure. Take the following anecdotal quote from Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

On the other hand: Scrum, done right, has the potential for an emergent success given iterative and continuous improvement. A potential method for solving the real problem is to exploit the emergent behavior of a system.

Emergent behaviors are difficult to track, but analyze the existing software, processes, and development and determine whether or not they are evolving appropriately. A successful development process should continually improve the same way the code itself should continually improve. The process itself should be agile, responding to change to better produce working software.

Better yet, the individuals and interactions should be agile. It is the people that must respond to change.