A plea to my fellow developers and our employers [Harm]

water waveRevelations today about a security breach at Sony Pictures. If the claims are true, the company failed to take even minimal steps to protect the identities of their users. Passwords were stored in plain text.

There are many reasons why this happens: naive business sponsors, inexperienced or pliable developers, poorly thought out or narrowly defined requirements, lack of regard for user privacy, and simple schedule pressure that leads to mistakes and cut corners.

It is unacceptable to assume stored user information is not sensitive simply because your site doesn’t do anything sensitive with it.

People re-use passwords. They shouldn’t but they do. They may only be signing up with you for access to white papers but that username and password may crack facebook, paypal, capital one, or any number of other websites.

We can’t treat websites as something less than software, cram as many front facing features into them with as little time and investment as possible and expect a serviceable, safe, and usable consumer experience.

We can’t treat developers as disposable widgets that are there to “work hard” and “do what they’re told” and expect them to watch our back by behaving as ethical professionals and crafts people.

We can’t expose customers to this kind of risk and expect to retain them as customers.

The best way to encourage new and onerous legal obligations is to act irresponsibly because there is no current legal obligation to do otherwise.

There is a historical pattern. A new field starts generating significant wealth and the resulting products and services become widely adopted by society. As a result of that success, failure becomes more visible, more frequent, destroys more wealth and harms more people.

The industry, practitioners and the government step in to reduce the failure rate. The typical result is government licensing of practitioners and regulation of businesses, accreditation of training organizations, and professional bodies with codes of practice and certifications.

I’m not against any one of these things if they evolve gradually.

But if we create another “software crisis.” This time one that affects the safety of large swaths of society or the wealth creation their trust of the internet represents. Then these things will happen too rapidly, too thoughtlessly.

So, here’s my plea to product people and executive sponsors:

  • Realize software is complex and websites are software.
  • Hire experienced, thoughtful developers, encourage them to tell you the truth and LISTEN TO THEM.
  • If you take risks to get something to market, take the time later to circle back and invest to bring that risk down.
  • Don’t take risks that can harm your end users.
  • Realize a website is not a onetime upfront spend but an ongoing commitment of time attention and resources.
  • Realize if you intend to use a website for a short time or an experiment, follow through and dispose of it — or be prepared to invest significantly more in turning it into a long-term asset.

Here’s the plea to my fellow developers:

  • Take the quality of our work seriously.
  • Learn, learn, learn how to write good code.
  • Take our end users seriously. DO NO HARM.
  • Band together and demand the best of each other

Collaboration and Competition: Balkanization vs. Bounded Cohabitation

Small collaborative groups often exist in isolation or in competition with other groups within an organization.

Unhealthy Competition: Balkanization1

This is the second pattern of collaboration that entrenches status quo (see Contrived Collegiality).

balkanize:

  1. : to break up (as a region or group) into smaller and often hostile units
  2. : divide, compartmentalize <now pop culture has been balkanized; it is full of niches, with different groups watching and playing their own things — Richard Corliss>

Balkanization

In a Balkanized environment, one team’s win is another team’s loss or, at least, one team’s loss is not every team’s loss.

A company that organizes itself by specialty and doesn’t matrix well to projects lends itself to balkanization but leadership can encourage politics under any structure if they distribute rewards based on unclear, unfair or arbitrary criteria.

Valuable learning in one group is not communicated or is disputed and not widely adopted. Managers drive to surface shows of success. Individuals are not encouraged to true joint work across organizational boundaries.

Agile is often introduced bottom up without executive sponsors in less than optimal cultures. In this context, development teams have dependencies on teams that do not buy into agile values. Developers are separated from decisions about opportunities, product portfolios, potential revenues, and product features. This is both a fragile place for agile teams and also diminishes opportunity for the company.

Healthy Competition: Bounded Cohabitation

Internal competition can be used to spur original thinking and organizational change.

Nonaka and Takeuchi describe a concept of “bounded cohabitation” where teams are set in productive competition with each team pursuing a different set of premises and value propositions all geared toward the same outcome.2

The example they use is detective work. One approach is to form autonomous teams around different premises: premeditated murder, crime of passion, accident, natural causes, etc. Let the teams self-organize assembling the appropriate numbers with relevant skills and experience for their specific premise.

The teams investigate independent of each other. Under their premise, each team may look past evidence others find relevant but also follow leads other teams wouldn’t think to pursue. Eventually, one team establishes the most plausible course of events. The shared outcome is met and the teams re-organize around the next investigation.

Japanese manufactures often form multiple engineering teams around the same design challenge; e.g., an engine meeting novel requirements of size, efficiency and performance. They adopt the best solution incorporating other good ideas into the current or future products.

In one case, Sony merged two teams pursuing different product strategies: (1) an evolution in video tape players and (2) a revolutionary digital non-linear editor.

Synthesizing those world views resulted in the digital video editor with engineer-friendly analog controls that broadcast centers could rack into their existing facilities. This new technology with a familiar form factor created a new market that Sony decks dominated.

An executive sponsoring agile adoption must strive for healthy internal competition. Carve out self-organizing teams. Encourage them to follow their own paths to a clear, common goal. Mutually agree upon performance measures. Retrospect across teams to determine what’s working and why. Allow for wrong paths, allow for variation and embrace the unexpected.

The concepts and examples in this post are drawn from:

1 Hargreaves A. and Fullan M., What’s Worth Fighting for in Your School?, Teacher’s College Press, New York, 1991.

2 Nonaka, I. and Takeuchi, H., Hitotsubashi on Knowledge Management, John Wiley and Sons, Asia, 2004.