We're trying to build great software (teams)

Great software convinces a computer to do our work for us better than or as good as we do it now. Great software performs operations on information faster, more easily, and more reliably than meatware, or paperwork, or mediocre software, and displays the results elegantly and clearly to those who benefit from them. Building great software does not require a team. It requires deeply understanding the meatware system, mapping it into symbolic logic and algorithms, and teaching a computer to run that system with those algorithms.

Building software is an act of translating our meatspace solutions to recurring problems into a form infinitely replicatable by a computer or network of computers. The software itself is a bridge over the chasm between humans and robots. To build this bridge it is important to be able to reach both sides of that chasm. We all start on the human side. Some individuals can reach both sides at once. Some get so far across they need help from those closer to the human side to reach back to where they came from. Some get a quarter of the way out and decide it is too scary; they freeze. Teams can chain together to reach across wider chasms than an individual could bridge alone. But they must distribute evenly. Concentrations/clumps/clusters threaten the integrity of the chain and bridge. Indiana Jones knows.

Computers speak binary. We do not, and computers have trouble parsing English. Some of us learn programming languages that can compile to lower-level programming languages on down the chain of abstraction until we reach assembly language and binary. Many of these abstracted programming languages involve arranging English words and symbols in logical structures to reflect the intended operations. One could even suggest that carefully reasoned and concisely written English prose is itself an abstracted programming language, since it helps programmers encode that reasoning into a computer-readable language. Software starts with logic.

So first someone ought to deeply understand the logic and reasoning of the current meatware. They can describe its functions or failings as concisely as possible, record that description in a place that's easy to access, and link related functions and failings together.

Once these are recorded, someone can begin encoding these functions using known algorithms, and someone can arrange these algorithms into clusters and lattices that perform the functions as directly as possible. It is helpful to have some minds focused on the finer points and others on the broader scope of the software.

The process of encoding happens one keystroke at a time, anyone can do it. Those who do a lot of encoding get faster and make more correct keystrokes per time. Those who are just starting out can proceed more slowly and reference others' code to ensure their contributions are valuable. It is helpful to write about the encoding process as one undertakes itβ€”to write comments and documentation inline and elsewhere.

Once the software is written, someone can run it and verify that it performs the operations intended, and that it does so faster, more easily, and more reliably than the meatware it is to replace. Someone who understands the meatware as well as the software can perform this task well.

That is true of all the roles described so far. All who endeavor to build software lie somewhere on a spectrum from human to robot. The most effective, consistent contributors on a software team often reside in the middle of the spectrum. Some highly effective teams consist of an even distribution of specialists along the spectrum who translate and communicate their specialized efforts to each other with extraordinary concision. Ineffective teams have an imbalance toward one end of the spectrum or the other.

Where do meetings come in?

Meetings among an even distribution of specialists can accelerate and multiply everyone's contributions. Meetings among imbalanced distributions tend to shed light on and magnify the imbalances. Instead of multiplying contributions, they divide the team's effectiveness by an factor proportional to the imbalance.

We've all felt this, the drag, the drain. We know we could be doing more and doing it faster if we didn't spend so much time in meetings talking about doing it.

So what do you do with a team that has an imbalance on the human end of the spectrum? What if you have too few that understand robots? To my mind there are three avenues to greater effectiveness and great software for a team like this:

  • Find more devs from outside
  • Convert non-devs to devs via training
  • Move some non-devs off the team

The third option may not increase velocity or effectiveness, but it will not decrease it either. It is less costly, and will reduce frustration for the existing devs who feel pressured and outnumbered. The well-meaning efforts of redundant team members can easily become distractions for the core team that would otherwise be balanced and effective.

The second option is the most difficult for the non-devs, but the most valuable to the existing members of the team. It will build camaraderie and effectiveness, but the training will take time.

The first option is the easiest, can be costly, and carries more risk. New devs will be cultural unknowns, their value will be difficult to predict. But chosen carefully they can ramp up effectiveness sooner than the other options.

Cited in

We're trying to build great software (teams)