31 December 2013

Team Leads and the Opposable Thumb

I once observed an old-school project manager spew voice-quivering animus all over a Google Hangout.

Most people don't respond well to controlled anger, particularly millennials. The project manager's Hangout audience was a group of thirty-something software developers.

I thought, "He's lost them."
They wouldn't follow him into a company-sponsored happy hour.
Software developers have numerous opportunities to pick up and leave should the toxicity level of an organization rise.
Millennials bristle at the scent of an ass-clown.
The developers I have worked with are the polar opposite to the stereotypical slacker dude. They're Do-ers who bang out complex tasks.

Over the years my teammates and I have gotten reams of code pushed, reviewed, and committed. Productivity aside, work must be fun or millennials are done.
Command and control wind-baggery emanating from some two-bit spreadsheet jockey is a buzz kill that sends the best people packing.
Tim Elmore observed that millennials have intrinsic, extrinsic, and altruistic desires in the workplace.

Intrinsically, millennials want to:
  • feel they're growing;
  • do interesting work; and
  • be challenged in their tasks.
Extrinsically, they want their:
  • workplace to feel like family;
  • workplace to be social;
  • leaders to be adaptable with time; and
  • leaders to value their contribution and commitment.
Altruistically, they hope to:
  • contribute to their community;
  • contribute to society; and
  • change the world for the better.

A de facto leader emerges from within every software team. De facto means serving a function without being legally or officially established.
de facto (d fkt, d)
adj.
  1. Actual.
  2. Exercising power or serving a function without being legally or officially established.
Ideally your team's de facto leader is also your titular head where the operative root of titular is title.
“Your value lies not in status or title, but in the roots of your character and depth of your compassion.”
Mollie Marti
The titular head might be at odds with the de facto leader, but given time the titular head will be willfully ignored.

Teammates of all stripes would do well to understand the spirit and essence of servant leadership. Mollie Marti wrote,
“A noble leader answers not to the trumpet calls of self promotion, but to the hushed whispers of necessity.”
A team lead should be an indispensable “opposable thumb” who cheerfully helps all the other “digits” grasp and handle stuff.

REFERENCES

14 November 2013

The Big Wave Operating System

I surfed in my teens on tame East Coast waves. The draw to surf and to all aspects of water waves has never left me.

I seek and study waves in lakes, rivers, oceans, storm sewers, and boiling hot springs. And like a kid with a shoe box full of treasures, I have mentally cataloged all of the famous surf breaks from the chilly shores of Lake Superior getting pounded by an October gale to Bali the mystical Island of Temples with its thousand surfing waves.

Mavericks in a legendary Northern California wave near Half Moon Bay that breaks a half-mile out to sea and gets downright perilous to surfers when the winter swells get juicy.

Mavericks is also the name given to Apple's new operating system upgrade.
Mavericks is not so much the inspiration for a Beach Boys song as it is a symbol of Melvillian existential struggle.
― Stewart Sinclair
As an late Apple products convert, Mavericks strikes me as an appeal to the existential extremes of the extreme sports universe and a curious marketing decision. As a wave Mavericks is one of the ultimate big wave machismo rides on the globe -- a death defying free fall down a Matterhorn of water chased by an avalanche of roiling whitewater.

As for Mavericks the OSX upgrade, I haven't downloaded it because I rely on a MacBook Pro to ply my trade. I am patiently waiting for my smarter teammates to resolve any compatibility kinks with Chrome Driver that might confound our integration tests and potentially munge other development artifacts so I don't end up dead in the water.

REFERENCES

17 October 2013

Bootstrapping Lessons from Brooklyn

Before attending an October NSF I-Corps entrepreneurial workshop in Brooklyn, I finished the required reading:
In this post I'll share a few things I took away from the workshop as an observer, and what I learned from the books.

As a launching point, a startup was defined as:
"A temporary organisation designed to search for a repeatable and scalable business model"
I was struck by the phrase temporary organization, but I suppose the idea is that once you become a revenue generating venture, you're no longer in the startup phase, rather you toggle the switches into an operational business where success is measured by how well you execute.

National Science Foundation I-Corps

The I in I-Corps stands for Innovation.

There is a shift afoot in the NSF away from funding stand-alone scientific research toward "broadening the impact" of basic research.

One way to broaden the impact of scientific research is to fast-track the science into products and businesses. Ergo we have I-Corps. From the I-Corps website:
The NSF Innovation Corps (I-Corps) is a set of activities and programs that prepare scientists and engineers to extend their focus beyond the laboratory and broadens the impact of select, NSF-funded, basic-research projects.
I-Corps, and the Brooklyn workshop I attended, are rooted in the soil of the Lean Startup movement.

Context: Customer Discovery & Lean Startup

Steve Blank is the de facto graybeard of Lean Startup. Lean Startup was proposed in 2011 by Blank's former student and entrepreneurial mentee, Eric Ries. While Ries popularized the movement beyond the software community, Blank contributed the essential first step:
Customer Discovery
With the exception of Customer Discovery, Minimum Viable Product, and the novel idea of iteratively testing a hypothesis about perceived customer value, much of Lean Startup is derived from the Agile / XP movement which has been used for over a decade in the software community.

Historical Context: Waterfall → Agile → Lean Startup

Software developers progressed from Waterfall to Agile and, more recently, into Lean Startup.

Waterfall is a sequential design process that was the canonical approach to software development for over 40 years. The stages of a waterfall are an unfortunate but apt metaphor for process rigidity (i.e., a new stage may not start until its immediate predecessor is completed).

Out of the process rigidity of Waterfall came the Agile Manifesto (Snowbird, Utah 2001).

Software developers have lived through the gains and pains of Agile implementations for over a decade (see Bottom-Up Change: The Agile Manifesto at 10). The lighter weight Agile taught us to embrace change, to adapt quickly to an evolving product vision, and to produce working software for the customer. Agile also taught us to iterate over bite-sized chucks of work and to reflect upon what we'd accomplished. We learned the value of incremental development. In short, we learned to
Plan, produce, and reflect.
Much of the Agile mindset is well-suited for starting a business.

The Business Model Canvas

Much of the workshop was centered about teaching graduate science and engineering students how to effectively use a Business Model Canvas. A Business Model Canvas is a template for developing new business models. The primary directive of a startup is to search for a viable business model.
"Startups search. Companies execute."
Frank Rimalovski, NYU Entrepreneurial Institute.
In the journey to find out if your model has legs, the Business Model Canvas is used to organize your hunches about what will sell and who your customers will be.

Business Model Canvas
Over the course of the 3-day workshop, the Business Model Canvas became both narrative and scorecard. It was used for measuring progress in discovering the essential aspects of the model. Participants were charged with finding and interviewing potential customers so they could test their hunches. They were admonished to
"Get out of the building!"
And participants were urged to,
"Start thinking about the ecosystem...how the money flows."
Participants were instructed to frame, trim, and hone their product concepts (and the written descriptions of their products) so that the gist of the product was easily and instantly communicated to a less sophisticated audience.
"Frame the description of your product for your mother."
― Lyndsey Marshall Gray, NYU Entrepreneurial Institute
I observed graduate students, called Entrepreneurial Leads or ELs, struggling to coherently and concisely express concepts like Value Proposition or Customer Segments to a panel of business experts and instructors who grilled them. Several times a panel member blurted out, "Who cares?"
"This is delivery. We learn by doing."
Jerry Engel, Berkeley-Haas School of Business
A Value Proposition is a promise of value. The Business Model Canvas has a box for Value Proposition, labeled VP. Participants were encouraged to write their value propositions as testable assertions.

A value proposition applies directly to one customer segment or another. The Business Model Canvas also has a box for Customer Segment, labeled CS. The workshop instructors stressed the importance of being able to map a value proposition to a specific customer.

When participants struggled with identifying their customer segments, they were encouraged to be concise and to think about the pointy tip of the arrow.
"Who are the people who will open their wallets first?"
―Lyndsey Marshall Gray, NYU Entrepreneurial Institute
Parting Wisdom

Many scientists, and would-be entrepreneurs, are hyper-focused on technologies or alleged features rather than benefits because that's what they find most compelling, but the process of determining value, and who might buy a product, has more to do with the Pains and Gains experienced by a potential customer.

Like the Business Model Canvas, The Startup Owner's Manual and Business Model Generation are dry and formulaic. But who am I to argue with success?

By all accounts, searching for a business model is a step-by-step journey of conquering one of the aspects of business development that might be most uncomfortable to those of us who are socially-inept or analytically minded:
Engaging people to validate your hunches about your product.
Software startups must be able to distinguish between users and paying customers because they're not always one in the same.

Stripped bare, Steve Blank's insight is that customer discovery is essential. One personal epiphany worth repeating over and over again for would-be software entrepreneurs:
Don't bother coding anything until you discover & understand who's going to buy it.
If you're attempting to bootstrap a software product or company, The Startup Owner's Manual is essential reading because I'm betting the formulaic practices will save you months, if not years, of misguided effort.

REFERENCES
SUPPLEMENTAL READING

30 September 2013

Shorting Microsoft?

Are you short selling Microsoft?

Technology entrepreneur and academic Vivek Wadhwa asks, Can Microsoft be saved?

Wadhwa's PBS article offers a glimmer of hope for Microsoft in its wealth of great people.
"But there is still hope for Microsoft. It has a wealth of great people and great technologies in its labs. They need to be untethered from the central bureaucracy and set free to compete and take big risks. I am not too optimistic, though, that this will happen. I worry that Microsoft will go the way of Kodak, RIM and Nokia -- or even the former Soviet Union -- all of which tanked because they were busy protecting old turf."
Vivek Wadhwa
As one who has used Microsoft's software development products extensively and almost exclusively in years past, my opinions about Microsoft align with Vivek Wadha's critique of Microsoft's fate.
Perhaps Microsoft will be saved, but it will be a tough row to hoe.
Culture-Changing & Product Focused

Yahoo! CEO Mayer
We all thought Yahoo! was dead, but against all odds, Marissa Mayer is reviving Yahoo! Microsoft sorely needs a culture-changing & product-focused CEO like Mayer.

Microsoft has a busted culture that historically pitted one division against another. Microsoft is also burdened with a shitty stable of over-priced, sever-centric products.
Windows 8? Fahgettaboutit!
Not only has Microsoft been late on just about everything the last decade, they've also lost the software development community. Losing the software development community is one big, sloppy kiss of death. For today's software developer, having too much Microsoft on your LinkedIn profile is a liability that says,
"I'm old school & unmotivated to learn new stuff".
No software product start-up worth its salt builds on the Microsoft tech stack. The price of entry is too high, the tools are insular, and the ecosystems around the tools are anemic when compared to competing tech stacks.

Nuke & Pave?

Microsoft needs the Marissa Mayer playbook. Microsoft's new CEO will have to nuke and pave the culture, then put a laser focus on products. Borrowing from Steve Jobs, the Microsoft product line must be trimmed and profoundly simplified.

Make it Cool?

You don't see many hipsters booting Windows 8 in your local coffee shop do you?

Creating, sustaining, or turning-around a company usually boils down to people and buzz. Underlying and buttressing the buzz are kick-ass products that aid and delight.

One of the questions the new CEO should address is,
How do we win back the software development community?
Somehow the new CEO needs to make it cool to have Microsoft chops again.

28 August 2013

Pull Requests for Teams

Sunflowers, 1887
Vincent van Gogh
If you recognize a measure of truth in the proverb:
Two heads are better than one,
you will want to experiment with the Pull Request workflow with your next software team.

Pull Request Workflow

The Pull Request workflow, implemented by popular shared source code repositories like GitHub and Bitbucket, is an excellent means to spark team discussions and improve code quality.

Like a classic Greek ode, the Pull Request Workflow has three call & response parts:
  1. Branch;
  2. Discussion; and
  3. Merge
Pull Request Workflow: 1. Branch; 2. Discussion; and 3. Merge

Following is a sample workflow for a hypothetical feature called more_cowbell.

1. Branch

Assuming you have already cloned (downloaded) a shared repository to your local machine, the first step is to create a branch off of the trunk (often called master).

Following are series of git terminal commands that will get you to the point where you can modify code. Typically you will create a local branch from the shared repository to work on a new feature or a bug.

Create the more_cowbell branch as follows:

(master) $ git checkout -b more_cowbell

Then checkout the newly created local branch as follows:

$ git checkout more_cowbell

Think of more_cowbell as your local sandbox. Now make additions, deletions, or changes, then create/run unit tests and integration tests, and commit your changes. Or if you prefer test-first, do the tests first, then commit.

(more_cowbell) $ git commit -am "Add more cowbell"

Finally you're ready to push your changes back to the shared repository for review, discussion, and a potential merge back to master.

(more_cowbell) $ git push -u origin more_cowbell

2. Discussion

Go to your shared repository on GitHub, Bitbucket, or other. Locate the more_cowbell branch you pushed in Step #1.

GitHub and Bitbucket both have side-by-side comparison tools. Use the compare tools to carefully inspect the proposed changes by comparing more_cowbell with master.

When you're ready to open your proposed more_cowbell changes to a team discussion, locate and click the Pull Request link (or button).

Your teammates will be notified of your Pull Request. They will then review your changes, post comments on individual lines of code, or post general comments on the Pull Request. Typical comments might involve issues with formatting, the location of a method, notification of code duplication, suggestions for refactoring, etc.

It is courteous to respond to the comments posted on your Pull Request in a timely and respectful fashion. A concise and courteous response from you following a "you might want to..." comment might be:
"Good catch. Will do."
Some teams use round-robin to determine who reviews a given Pull Request with each developer assuming the role of reviewer. Other teams assign one or more lead developers to review all the Pull Requests. Most teams encourage the entire team to look at and comment on Pull Requests as time permits.

Others may add commits to your branch by doing a fetch and a checkout of more_cowbell on their local machines. They would follow the same workflow of modify, commit, and push back to the shared repository. Presumably more discussion would ensue.

3. Merge

After ample discussion, and perhaps following some additional changes or tweaks that have been suggested to you, someone other than you will merge your changes to master.

Summary

For me, the essence of a Pull Request is:
  • to learn from my teammates, and
  • to agree upon what constitutes a worthy addition or an incremental improvement.
Like me, most developers readily agree that code reviews improve quality. And like me, most developers dread the traditional code review because it often means an uncomfortable one-on-one encounter with a high-ranking alpha developer where one is made to feel defensive or worse, incompetent.

Pull Requests feel less authoritarian and more democratic. It is a lightweight quality improvment process more in the mode of discussion and edification, than in the mode of admonishment. It has been my experience that Pull Requests spark discussions about the code and the craft which, in turn, tends to improve the quality of the code.
I'm all in favor of the democratic principle that one idiot is as good as one genius, but I draw the line when someone takes the next step and concludes that two idiots are better than one genius.
-Leo Szilard
References


14 July 2013

I'm Doing it Wrong? Really?

I chafe at how freely many of us will say you're doing it wrong.

Sometimes distinguishing a right way from a wrong way is easy. Sometimes it's not.

Holding a telephone handset upside down appears laughably wrong - unless you're doing a comedy bit (where it might appear laughably right).

The wrong way to produce software is not as obvious as holding a telephone handset upside down.

Producing software involves contextually-dependent variables. We are faced with business constraints, technical hurdles, and inter-personal challenges. Constraints, hurdles, and challenges are situationally-dependent. Constraints, hurdles, and challenges vary from product to product, and change from one environment to the next.

What might have seemed wildly right in one context, might be wildly wrong in another.

Your Dogma Ran Over Your Karma

A post was shared on agile .net practitioners with the title "If you are building applications without writing your tests first then you are doing it wrong. The title was probably meant to attract attention, and the post was probably written in the vein of self-promotion, but it got my attention.

I have benefited from the virtues of Test First, but the statement, "If you are building applications without writing your tests first then you are doing it wrong" seems hyperbolic, naive and unnecessarily dogmatic.

Situational Utility

Test-Driven Development (TDD) and Test-First have become catchphrases. Who hasn't been endorsed for TDD on their LinkedIn profile?

Several developers I know use Test First exclusively. Many more developers I know talk about Test First, but do Test After. Still more developers I know appreciate and espouse the virtues of Test-Driven Development, but rarely use it. Hardly anyone doesn't, at least, pay lip service to TDD.

Developers encounter many different situations. It follows that there are many ways to approach the tasks at hand. TDD is not the holy grail.

Craftsmanship Surcharge

There is at least one situation, and perhaps several more, where TDD or Test First adds a gratuitous craftsmanship surcharge to the bill.

Lets say you are contracted by a start-up to iterate from an initial proposition to a viable business model. Is TDD a cost-saving approach? Probably not. While the code might be flawless, TDD slows down the cycle of testing a business proposition thereby increasing the start-up's burn rate. Many start-ups don't need flawless code during the market testing phase. The reality is that there is going to be throw-away code, particularly in the context of a lean start-up where the team is meant to be in iterative learning mode.

Be Kind, Rewind

Several of the useful things many of us picked up in the early days of XP, and during the maturation of Agile, are too often applied as blunt instruments to pummel our less dogmatic teammates.

TDD can be a blunt instrument. Just like the common misapplication of Stand-ups, Retros, and Burn-down charts, Test First can degrade to an abrasive command-and-control directive as readily as it can prove to be a prudent practice.

The What and The Why

Approaches, practices and tools have a place when they serve The What and The Why. We agree craftsmanship deserves attention. As practitioners we love bullet-proof code. Many of us have gotten proficient at The How and The When.

I'm self-critical. I know I might be doing it wrong. In many cases, I presume to be wrong. But increasingly I don't care so much for The How or The When.

I'm reviving my old mantra: Don't Lose Sight of The What and The Why.

18 January 2013

A Personal Approach to Agility

I will always appreciate the spirit of the Agile Manifesto. I revisit the 12 principles behind the Agile Manifesto on occasion, particularly after experiencing recipe-driven nincompoops who use the principles as blunt instruments to flog me and fellow developers.

I am also increasingly surprised by how disconnected Conference Circuit Agilists have become from producing software. Pithy anecdotes don't often jibe with in-the-trenches experience.

A Personal Approach

As an itinerant software maker, I enjoy the inter-personal stuff of software teams. I also enjoy the process stuff, but mainly in environments where the process remains in a state of continuous improvement.

Improvement has little to do with output and a much more to do with making software that people like to use. My approach is born from trial and error. I hope my approach remains in continuous improvement. I hope it remains simple.

I try to understand the context of the product challenges. I like to think I have become less dogmatic and grown more pragmatic. I try to be sensitive to the social dynamics of the organization that has invited me in. Some truisms are:
  • Recognize every product is different - There's no one-size-fits-all in producing software.
  • Build capital by getting stuff done - There are few bigger chits than working software.
Assuming you have banked some capital with your benefactors:
  • Protest & respectfully resist process ceremony - Process ceremony wastes everyone's time.
  • Practice the things that make sense - If it has to make sense, it's always a fluid practice.

My approach is a state of mind, rather than a recipe.
"In the beginner's mind there are many possibilities, but in the expert's mind there are few"
Shunryu Suzuki

Commoditized Agile

Commoditized Agile is a market-driven, largely failed, money-making machine. It is a prescriptive approach that metastasized from what began as the agile movement. Behind the guise of agile, ne'er-do-wells seized the chance to make a living lecturing people about The Best way to make software.
It's the product of opportunists and lazy organizations.
Lazy organizations, seeking the easy pills, threw money at a state of mind believing it would somehow morph into a prescriptive remedy for unhappy employees and crappy software.
  • Opportunists packaged prescriptive service offerings and over-featured software products around a set of principles that were probably never intended to be prescriptive.
  • Organizations seized on something new, so they had to throw money at the something new as proof they were doing it.
Commoditized Agile as troweled out by Conference Circuit Agilists, several of whom couldn't possibly have time to produce software, is mostly snake oil. Commoditized Agile, as represented by a host of crappy software products targeted at organizations who are "doing agile", is poorly conceived.

The lessons are simple. Find a personal approach that's an aggregation of trial and error. Co-opt the best ideas of others. Apply those ideas where they make sense. Deep-six any process with the scent of gratuitous ceremony. Remain skeptical of shiny new things. Get rid of tools that hinder your progress. Beware of charlatans selling snake oil.
"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."
- R. Buckminster Fuller

Postscript

I've been told in a tweet that this post is a bit cynical. So readers should know that I almost always enjoy the smart people I work with. In fact,
The joy I get from the people I work with invariably outweighs the profound organizational stupidity I encounter.