In my previous post, I pointed out that as software developers writing business-driven software, we build automation, not products—at least not products in the traditional manufacturing sense. This idea has been around for quite awhile; in fact, even Dijkstra has something to say on this topic:
It is not unusual—although a mistake—to consider the programmer’s task to be the production of programs. (One finds terms such as “software manufacturing”, proposals to measure programmer productivity by the number of lines of code produced per month, etc., although I have never seen the suggestion to measure composer productivity by the number of notes monthly scribbled on his score!) This mistake may be at the heart of the management failure which is so apparent in many large software efforts.
~ Professor Edsger W. Dijkstra, 1971
The inputs to software are not primarily mechanical but rather organic—they are people!1 In fact, the Manifesto for Agile Software Development really boils down to an affirmation of the human aspects in the development process. To provide some context, let’s examine the core tenants of the manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
All of these points call attention to the dynamic and organic nature of human interaction as it relates to business. Manufacturing is not this way:
- a robotic arm doesn’t deal with unique individual problems—we do.
- a laser cutter doesn’t take a customer’s feedback into consideration before etching a part—we do.
- Cams and rollers don’t need to adapt to an ever-changing business atmosphere—we do.
But if manufacturing isn’t a great metaphor for developing software, then what is?
I think I’ve landed on a much better analogy—software as a symphony, and we the musicians.
The great symphony orchestras create beautiful music together by deciding as a group to follow the same tempo, rehearse together, focus on the audience, and work together as a team. These principles hold true and produce amazing results regardless of the type of music they encounter together.
Software teams that do the same—setting their team a common rhythm, committing to rehearsing a release by demoing regularly, focusing on their user audience for feedback, and working together as a team—end up producing amazing software. And this is true whether the software is a lowly microservice that’s part of a giant codebase of millions of lines or a flashy new customer-focused product.
Music has a tempo, and so does software. In music, the tempo is a commonly understood sense of time that allows musicians to stay together. Without agreeing on a common sense of tempo, even a few musicians trying to play together would end in chaos.
Thus it is with software teams. Setting a regular rhythm on your team is focused specifically on how and when they can work together or work alone. And while in a symphony orchestra, it’s the conductor who sets the tempo and signals tempo changes, it’s interesting to think about who the conductor might be on a software development team.
Establishing a common operational tempo on a software team is also the intention behind fixed meetings (standups, sprint planning, etc). Sometimes the situation calls for two week sprints, sometimes it calls for one week. Finally, it’s important to remember that a team will develop its own rhythm as it works together—for example, when integrations occur, or when some members complete assignments more quickly—and this rhythm should be encouraged unless it has unhealthy elements that can cause team burnout—for example, rhythms of late-nights before the demo to push out those couple extra features.
Concert performances don’t simply happen on the first try. Rather, they are the result of multiple rehearsals that provide opportunities for feedback, timing and style adjustments, and refinement to make sure the final result is spectacular.
Similarly, it is important to release early and often with your customer. A good product release doesn’t simply happen in one massive git commit. It is the result of multiple iterations of release, listening, and incorporating feedback into your work. Additionally, showing “close to finished” versions of your final product gives you a much higher chance of success, since you get early warning signs of change. Maybe the business need has changed overnight. Maybe your client has a new opportunity that’s on a tight deadline and you need to take on some tech debt to speed through a key feature.
A musician can occasionally forget their primary purpose amidst the technical or stylistic complications that they face. In the end, they have to remember that they are producing music for one reason—to bring joy to your audience.
The travails of building software can often make us forget that, primarily, we are here to bring a great user experience to whoever is using our software. We believe at PKC that shifting from an internal focus to an external one allows you, the software developer, to enjoy your craft in a long-lasting and avoid the feeling of becoming a code-monkey—ultimately, an unacceptable place to be in—even when you’re stuck in the valley of a tough technical challenge.
The greatest symphonies and bands in the world are also amazing teams. It takes great focus, skill, and self-sacrifice to merge your flow of musical creativity into dozens of others. But when it happens, it’s an incredible, almost other-worldly experience for musicians and audience alike.
At PKC, our goal is to meld teams into great symphonies. We hire the best talent, yes, but we also work hard at things like teamwork and joy, because those are the components to great software (and great symphonies).
If that sounds like something you’d like to be a part of, we’re hiring!
I think this property of software explains why security is such a big issue for us, but not as much an issue in manufacturing. ↩