small medium large xlarge

Team Work

The most important ingredient of any project is the people. Not only
do you need good people to begin with, you need people who can work
together effectively.

On larger teams, you can afford to have some trainees aboard—folks
who aren’t at the top of their game yet, but aspire to grow in that
direction. On small teams, you may not have that luxury.

In this case, with such a small team, each member is a highly-skilled
professional. To get maximum skill coverage, each specializes in
separate, non-overlapping areas of expertise: John handles the high-definition MIDI format,
Drew Gross does the audio processing and acoustics, Peter tackles the
infrastructure and architecture, and Anatoly evaluates the concert piano performance.

Each team member is good at prioritizing their own tasks and maintains
their own to-do lists. But despite this autonomy, they still hold
weekly virtual meetings to share progress and status and coordinate
their plans.

Developer team meeting

Developer team meeting

To leverage their computing environment and maximize mobility and
interoperability, all their development work is done on laptops
(larger servers or grids will be used in production).
Many of the laptops are of the same brand,
which allows the
team members who are collocated to share parts more easily in case of
emergency. But since their creation is cross-platform, they also have Mac
and Linux notebooks in the mix.

But while the development hardware platform is standardized, the
software isn’t. There is no mandated IDE—nor should there be.
Different people will be more productive in different IDE
environments, and these team members tend to prefer powerful
stand-alone editors in lieu of bloated, slow, all-encompassing IDE’s
(note the complete lack of editorial bias here).

With this technology and methodology in hand, this small team was able
to create ground-breaking software in a relatively short space of
time. Let’s take a quick recap of the salient points of their

Lessons Learned

What can we learn from this team? Just that the basics on which we
continue to publish and lecture make a big difference. Your team
could be a success or yet another dismal statistic, it’s up to you.
Here the practices observed by the Zenph team that we think are
most important.

  • Start with good people. If you’re lacking in certain
    skills or experience, invest in training or workshops to help bring
    everyone up to speed (if you’ve got trainees you need to bring along,
    make sure they have a chance to learn while keeping them out of harm’s
    way on the critical path). If you’re faced with choosing between a
    mediocre team that’s collocated vs. a skilled team that’s
    geographically disperse, choose the skilled team and invest in a
    decent VPN.
  • Everything under version control. We’re getting kinda
    tired of beating this drum, but many teams still either don’t use
    version control at all or do so improperly. If your version control
    system is getting in your way or slowing you down, you need to replace
    it or learn how to use it properly. By the way, my address book is
    under version control, as well as my daily to-do list.
  • Define success. The project manager or sponsor needs to
    define what “done” means for the team. And not just in some flowery
    mission statement. Give developers quantifiable and achievable goals
    and they’ll meet them.
  • Start small. Tracer-Bullet development is all about
    starting with a full framework, but with all the functionality stubbed
    out. Get the small, fundamental basics right first, operating within a
    sketch of the larger architectural context.
  • Test. There’s no excuse not to unit test. If the code is
    “too hard” to test, then it’s likely too hard to write. Well-designed
    code is easily testable; poorly-designed code is not. Don’t be afraid
    to create your own test framework or supporting code (like the Grader)
    if needed.
  • Learn from the user. Listen closely to the user—their
    expert knowledge should be driving the requirements. But their
    suggestions should not determine the architecture and design, that’s
    the developer’s job. Always look past the user’s stated requirement
    to discover their real need.
  • Leverage technology. Use open source where it makes sense.
    Build proprietary software where it makes sense. Don’t be dogmatic in
    either case. Fancy or expensive IDE’s may be a great help, or they
    may slow the team down. Developers usually know which is true for
    them; make sure the team honors that.
  • Teams build products. To build a great product, you need
    to also build a great team. Whether your team is composed of novices
    or experts make sure everyone is allowed to work appropriate to their
    skill level, and can all work together well (that’s all easier said
    than done, of course, but that’s a topic for another book).

Looking Forward

John Walker says there are a great many historic recordings that were
never released to the public due to minor recording problems—an out
of tune string, someone in the audience coughing up a furball, that
sort of thing.

But once converted into the high-definition MIDI domain, the performance can be
edited: a blown note fixed, technique adjusted to match the response
of modern equipment, and so on. When recording the Disklavier, there
doesn’t need be an audience present. That means the recording engineer
doesn’t have to contend with squeaks from the piano bench, the
air-conditioning suddenly kicking on, or anything of that nature. And
even if some noisy event did ruin the take, it’s trivial to restart
the high-definition MIDI playback and re-record.

Thanks to well-written software that meets the requirements, this
technology may well end up having vast repercussions for historians,
performing artists and fans alike.

That’s what we call a successful project.

<< The Methodology