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 approach.

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