Continuing in my nerdy output of management concepts** I want to highlight an important idea about management processes.

Studs in motion

Imagine a carpenter who took the blueprints for a house, read them once and then never checked back to make sure that all the details were right.  That carpenter built the whole house and upon completion the inspector showed up to review the first phase of the work.  The inspector would require that all the drywall would need to be ripped out so that the plumbing and electrical and structural work was done properly.   In fact if the foundation wasn’t properly inspected they may make you tear the whole house down to the foundation.  The mechanisms in place to make sure that the house can be moved into are strict to make sure that people who move into a house are safe and to confirm that the home will meet the minimum requirements of building code.

Final inspection processes are the worst gating mechanisms as far as efficiency is concerned.  Gating mechanisms are used to control bad output/content/products from hitting the public or releasing into production.  This is part of quality control work, which is important.  However, often decisions are made that trump the processes and I’d like to address that idea here.

Principles are basic assumptions that lead to actions for the individual.  If a company has hired an employee who has either under-developed, compromised, or incorrect principles then the outcome will be under-developed, compromised or incorrect.  This applies to me as much as anyone else as an employee.  I’ve had bugs in software because I compromised on my principles for the sake of time or in response to perceived pressure and the outcome was compromised [read: bugs in the code].  Instead I needed to work with the discipline and conviction that were the principles I knew.  This would involve test driven development, careful use of the tools that I had, and doing things the ‘right’ way.  Software Craftsmanship principles that lead to a quality outcome over and over.

Principles lead to practices – they’re things that I do and tell other people about so that when they’re doing what they do they might consider changing their practices based on the principles I’ve informed them of.  Maybe they add test driven development to their repertoire.  Maybe they break changes down into better modules of code so as to make it more  testable.  Maybe they teach me a principle so that I can do a better job because my personal craftsmanship toolbox is added to.  In the end the principles lead to best practices that are applied and expected between myself and the community of developers (or team) that I work with.

Processes – being required/enforced by an outside party (management, C?O’s, clients) – should almost appear as an afterthought.  They should be affirmed, but they should never trigger a gating situation.  Internal processes should exist, but should not come up as tests or mechanisms that lead to surprises.  Instead the value of  the process is to confirm that the right principles and the right practices were in place.  You see if the wrong principles and practices are in place then the technicians employing their trade can either figure out a way to bypass them, or they’ll slow down the whole race to completion of work because they ignored them and the problems weren’t discovered until the end.  If processes are finding issues then the principles and practices should be addressed first because they are the location of the problem.  You don’t need more processes, you need quality in the principles and practices of your team.

I’m learning this about myself the hard way – so this isn’t something that I’ve known all along, it is what I’ve seen in myself.  More processes will just slow down the final work of your team as they reach a release.  However, if the team is not responsive to education and learning proper craftsmanship principles and embracing practices of maturing craftsmen (and craftswomen) then they’re not going to be helped by more processes.  They may be a bad fit for your company or project.

Make sure you know the blue prints.  Make sure you know the best way to do things.  And for heavens sake, don’t let the inspector find your mistakes and make you do the work again – do it right the first time.

** ignoring that a majority of my readers are family who could probably care less

One of the most important tricks an ECMAScript coder can learn is how to properly create ‘object’ with prototypes.  A second-place runner up is the use of closures.  Closures come from JavaScript’s secret roots in Scheme.  They’re a technique for letting scope ‘linger’ around for functions that are called within a function.  I looked for tutorials on closures but couldn’t find any immediately that didn’t basically alert someone’s name, which just doesn’t seem very practical to me.  Alerting your name is the boring cousin of “Hello, World.”  So let’s look at a practical problem with a need for a solution.  Let’s say that you have a prototypical object that happens to enhance HTML links that the user can interact with. Since you’re doing progressive enhancements the link will work as expected on browsers that don’t have JavaScript enabled, but for those spiffy browsers that are progressive (not a political statement), you’re going to attach an onClick event.  I’m lazy so the examples below are going to use jQuery event attachment, but longer-form addEventListener, which is wonderful and will make your life more fulfilling.

So when you click on this link you want it to be able to refer to your object so that you can work nicely with other libraries or have multiple instances of the object on the page.  The hacky ways to do this might have included adding attributes to the HTML object, doing some sort of global object lookup, or any number of other things I did when I didn’t understand closures.  But here’s what you’re going to do:

<html>
<head>
<title>Never Gonna Give You Up, Closures!</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>
function MakeItCloserWithClosures()
{
/**
Assigning a variable 'that' to have the value of 'this' creates a reference that maintains scope through closure, so sub-functions/lambdas, can reference that as a variable that is in scope to call functions withint this object
*/
var that = this;
$('.makeMeClosureFriendly').click(function(){that.rickRollTheUser();return false;});
}
MakeItCloserWithClosures.prototype.rickRollTheUser = function(){
document.location.href = 'http://www.youtube.com/watch?v=3HrSN7176XI';
};
/* use jQuery's ready function to initialize the object, which should attach it to the HTML objects. */
$(document).ready(function(){ new MakeItCloserWithClosures(); });
</script>
</head>
<body>
<a class="makeMeClosureFriendly" href="http://www.digg.com/closures-are-easy">
Closures are easy!
</a>
<body>
<html>

There are a number of possible issues with the above code as far as scope is concerned: 1) the new object is not assigned to a variable for future reference (which we’ll pretend is awesome and the best idea ever), and 2) since it isn’t assigned there’s no global variable that we could attach to inside of the click event handler (function).  Except that with closures we can use the code’s reference to ‘that’ and it will refer back to the originating object and Rick Roll the user.  Closures are the best for handling references back to an object that needs to touch code, but not be global in scope or concern itself with as much interaction with other libraries.

I like to think of closures as ‘scope tunnels’ that can linger on for some time as long as the objects that reference them still exist.  In complex web applications being able to reference back to a parent object can save lines of code, confusion and can help call functions that are aware of other variables, details, and settings that exist within a JavaScript/ECMAScript object.  Fewer lines of code to debug is a big win, and fewer lines of code to maintain is even better.  I hope this helps!

Where will you use closures today?  See the demo to get Rick Rolled.  Please leave questions in the comments.

At present JQuery, the popular library for web development, is not capable of sitting inside of a Web Worker instance.  It probably isn’t a huge deal for most folks, but there might be cases where the JQuery syntax or utility functions would have been nice.  AJAX can still be handled in the traditional ways (and all browsers supporting Web Workers can use the proper JavaScript object and not the old IE Active-X hack).  And since it’s basically a background thread you can even use synchronous AJAX

JQuery may get a new implementation or a sub-library that can handle being in a thread, but for now, don’t count on it inside web workers.