Alignment

My earliest memories are wrapped around an incredibly long folding table that my father had inherited from an Off Track Betting parlor. When unfolded, there were long benches that flipped down and were as comfortable as you could imagine flat polycarbonate to be. The monstrosity stood in our family's garage, and it captured my imagination because in my mind it was all you needed to play Dungeons & Dragons.

I was a nerd. I am a nerd still, and proud of all that the word implies, but at the time, D&D drove me to learn by orders of magnitude more than any class or school activity. I knew words no other third graders knew, much to the irritation of my teachers. I still remember asking if I NEEDED to look up all the definitions on our vocabulary list, or if I could just write them. I had no idea how pompous I had sounded: I learned to be socially awkward shortly after that.

"You can tell me what 'encumbered' means?" I remember the teacher challenged me. Having played a thief the previous summer and getting into an argument with my DM about how an 11 strength should allow me to sneak a chest out of a window and retain my 30' of movement, yes I felt I had a visceral understanding of what encumbrance meant. I tried and failed to explain it eloquently, and while the teacher's words were, "Just look up the definition," I think everyone heard the unspoken, "Gettin' real tired of your shit, wompa."

The word that stuck with me for years, however, was "Alignment". I knew the definition of alignment and it was settled firmly in my head. That's unfortunate. It took me many years to really internalize what alternative meanings could be there, and how it could help a software team.

Alignment

Alignment is one of those concepts that seems simple at first, and quickly devolves into fuzzy definitions, particularly when trying to quantify the benefits. At the core, the concept of alignment implies that all members of your team have a similar understanding of the project. But with that said, a project is an incredibly complex collection of moving parts, and "similar understanding" is downright useless when it comes to pinning down if you have alignment or not.

I think it's useful to break Alignment into smaller pieces:

• Priority
• Expectations
• Process

There are literally hundreds of ways to define the various shades of meaning, but these seem like a useful level of scope to start with.

Alignment of Priority

There's as many wrong ways to write software as there are right ways. In order to attain alignment of priority, I've found it useful to break down the virtues of 'good' code into a list, and to make sure that all of my team members agree on the same order, or at least similar and compatible order:

• Stability - Is the code simple enough to not invite side effects and bugs?
• Time - Is the code taking too long to get to a deliverable? Is there a large number of features
• Optimization - Is your code running wasteful cycles or allocating unnecessary memory?
• Readability - Can other team members understand your code without unnecessary effort?
• Modularity - Are these classes reusable in other projects? Do they establish a pattern?

What's the best order? The answer is that it depends greatly on the needs and goals of the project. A prototyping phase is going to have a wildly different profile than the priorities of creating tools to tune analytics data of a live product. The important thing is to communicate about this, and to make sure your team agrees.

Alignment of Expectations

I can't count how many times I've seen a disconnect about expectations lead to lost time, speed, and morale. I'm beginning to think 

Alignment of Process

When individuals don't follow the 'accepted process'