In my day job I’m a software developer. That means I create software that automates or aids some process that humans used to do by hand, or could not perform altogether. Before my team actually gets down to writing the software, and sometimes even during, we have to have a lot of long discussions. This is in shrill contrast to writing a story, where I can sit down and go. I’m going to look at both extremes a bit closer today.
Why discuss things?
Assumption is the mother of all screw-ups. During the software development process, the developer makes thousands of small decision. They base these decisions on what they think they know about the process they’re translating to software, how it will be used, and how much time they have to create it. The problems is that what they think they know is mostly assumptions.
This actually applies to all people involved in any project. Everybody looks at things a certain way and makes assumptions. This can lead to this famous problem:
Most people already know this picture. The original author of the image is lost in history, apparently.
To counteract this, everybody is put together in meetings to discuss things. One of the things we developers learn during our career, is how to check our assumptions.
Of course, working by committee also has its downsides.
Why go at it alone?
When you work on a project by yourself, you have full creative control. This is the default for novelists, many indy game developers, and many musicians.
The advantage is that the project can become exactly how you envisioned it. In a novel, every line and every word is your own. Any advice you receive, you can lay aside and ignore.
One of the problems in the movie industry, is that certain movies are created ‘by committee’. Executives, who know nothing of storytelling, force certain scenes into a movie, because they should sell. Of course, it doesn’t always improve the story.
A prime example is making Wolverine the protagonist in X-Men: Days of Future Past. I’ve made no secret of how that move ruined the movie for me. Somebody decided it was a good idea, for reasons, but it’s pretty clear it wasn’t part of the original vision of the story.
Computer games can be even worse, as you can see from gems such as this one.
Look at the image above again. Now think of another solution besides better communication… Yep, if the customer could do all the work themselves, they would get exactly what they wanted, because no communication would be needed.
The takeaway
I think the two things to take away from this are these:
- When multiple people work on the same project, they should communicate a lot about their vision and assumptions.
- A project should have as few different roles as possible involved in the actual product creation.
The above guidelines explain why a single-person project like writing a novel works so well.
However, what to do for projects that are too big to handle alone? Ways-of-working have been developed with these same guidelines in mind. ‘Agile’, ‘Lean Startups’, and ‘DevOps’ — to name a few — all try to minimize the different people involved in creating a product. The idea is to have the same small group of people fulfill different roles as needed to avoid the problems from the picture above.
These methods are catching on. This means a bigger push for people that can do everything. The future is a swiss-army knife. If you’re a developer, you should learn how to talk to customers and hold meetings. If you’re an analyst, you should how to test or code. And so on, and so forth.
On that note, I should mention that actually publishing a novel does take a whole team of people, even if writing a novel doesn’t. The writing is usually one person, but the rest of the process is often not, except for people self-publishing.
Conclusion
In the end, there really is no discrepancy between working in teams on software, and working alone as a writer. They are two approaches to the same problem.
