Skip to content

Latest commit

 

History

History
127 lines (102 loc) · 5.99 KB

panic.md

File metadata and controls

127 lines (102 loc) · 5.99 KB

Panic-Based Development Methodology

Overview

The members of a team using the panic-based development methodology -- PBDM for short -- are motivated by the belief that the fate of their careers (or their departments, their companies, maybe even the world) depends on immediate completion of their mission. A PBDM team is completely focused and will work long hours, ignore distractions, overcome all obstacles, and accept any amount of technical debt if it will move the team closer to achieving its goal.

The mission of a PBDM team may change at any time. When a new goal is determined to be the key to salvation, their previous purpose is forgotten, sometimes permanently. It may seem counterintuitive at first, but while extreme focus is a key aspect of PBDM, the objective of a PBDM team will change far more rapidly than that of a team practicing Agile or other traditional methodologies, and it is very rare that any goal is ever fully-realized. Goals themselves are not important to PBDM: panic and focus are.

Advantages

A team practicing PBDM is single-minded in the pursuit of its mission and will not be deterred by many obstacles that derail traditional development teams, such as:

  • uncertainty
  • fatigue
  • personal relationships
  • recreational activities
  • concerns over quality
  • conventional wisdom

Let there be no doubt: a PBDM team will get things done.

Disadvantages

Poor Quality of Implementation

Because of their extreme haste, the work done by a PBDM team is usually of low quality and extremely unreliable; pausing or even slowing to "do things right" is not acceptable. This concern is not fatal: with the proper training and discipline it is possible for a PBDM team to turn out high-quality code in the midst of constant panic.

Discourages Innovation

A greater problem with PBDM is that the methodology prevents its engineers from innovating: their extreme focus allows them to think only of the immediate mission; if extraneous suggestions are provided by team members they are highly discouraged. The methodology pushes the responsibility for creative thinking up to management.

Creates Panic

Management may initiate PBDM by creating synthetic panic to motivate engineers. Over time, however, following PBDM will sow the seeds for genuine panic: the process is self-reinforcing. By focusing on only the most immediate concerns and piling up technical debt through poor quality, PBDM ensures that there will be future crisis.

Creates Panickers

In the beginning, a management team may purposefully foster PBDM -- maybe out of good intentions, or maybe cynically. However, as noted above, PBDM creates future panics. PBDM also creates panickers: a developer who spends his or her formative years under PBDM learns to believe that panicking is a normal state of being. Over time, some of these developers are promoted into management positions. Eventually, not only does the organization have a steady stream of real panics to which it must respond -- the leaders of the organization are themselves conditioned to believe that panic is a normal, productive state of being. See the five monkeys experiment.

Retention

A PBDM team has difficulty in retaining, and especially attracting, top talent. A-level developers respond to synthetic panic with cynicism and cannot be bullied into fearing for their careers; furthermore, they value strategic vision and do not want to be mired in technical debt.

Use PBDM When

  • Management cannot make up their minds, and/or have extremely short attention spans.
  • Management frequently espouses the action fallacy: "something must be done, this is something, therefore we must do it".
  • You are in technical bankruptcy: the team has more debt than can ever be repaid; panic is the correct response.
  • You are already using PBDM. Once a team is accustomed to PBDM it is difficult to escape. The technical debt piles up. Team members motivated by "saving the world" may find it difficult to rejoin civilian populations. You are probably right to continue panicking.

Avoid PBDM When

  • Your mission requires strategic planning.
  • You want to work with top-notch engineers.
  • You don't already have a pile of technical debt.
  • You need to complete large-scale development efforts.
  • You have a choice.

Recognizing PBDM

PBDM is a widely-used methodology, but many teams come to it organically and may not know they're practicing it -- they may not have even heard of PBDM! There are several signs that indicate a team is following PBDM:

  • Fear -- The team has a culture of fear and mistrust. You frequently hear statements like "we're all going to be fired" or "we're going out of business" even when it is clear that such risks are non-existent.
  • Drama -- The team is working on the most important thing in the world. This fact sets the stage for high drama. If a team has frequent heated arguments and fractured interpersonal relationships, there's a good chance it's using PBDM.
  • Bottom-Heavy -- As mentioned above, it is difficult to attract and retain senior engineers when practicing PBDM, so such a team will have an unusually low average in terms of years of experience. This weighting is not caused by ageism -- senior engineers just know better. Senior engineers that do remain are likely to be valued more as "swamp guides" than architects.
  • Bad Manners -- When you are saving the world, politeness, human decency, and even personal hygiene take a back seat.
  • Booze -- Many organizations utilize boozy team outings to foster camaraderie. A team using PBDM needs booze to survive. Booze gives rest to a brain intensely focused on saving the world; it salves the interpersonal wounds caused by infighting and high drama. A team following PBDM is a like a superhero sitcom: our heroes save the world each episode only to start fresh next time; booze is the balm that allows the team to forget that the story is the same each week.