Over the course of my adult life, I’ve had my feet in two seemingly disparate worlds: creative writing (including screenwriting) and software engineering.

After a long career in web development, I transitioned (2.5 years ago) from the tech industry back to content production (which was my original focus after college).

Since then, in addition to blogging and audio/video production, I’ve spent a substantial amount of time on screenwriting. I’ve written (or re-written) three feature films and one short.

While working on my screenplays, I’ve applied numerous best practices from software engineering to my screenwriting process. I’ve discovered that software development and script development have a surprising degree of congruity.

With that in mind, below are six software development practices that may help you improve your screenwriting.


Use Open Source Languages & Free Tools

Software Development

Over the years, the software engineering field has moved away from proprietary programming languages (often requiring paid licenses) towards free open source languages. Moreover, many software engineers choose free coding tools to build their applications.

Python Logo
Python is one of the most popular open-source programming languages.

Script Development

Historically, for screenwriters, the industry-standard software for writing and correctly formatting screenplays has been Final Draft. The program (which currently retails for around $200) uses a proprietary file format (FDX), although it can import and export other formats.

Today, Final Draft is still wildly popular, but other options (both free and paid) are abundantly available. Also, and perhaps more importantly, screenwriting now has an open-source format of its own. Fountain text markup allows you to easily move your script between different screenwriting programs and text editors.

Fountain Logo
“Fountain is a simple markup syntax for writing, editing and sharing screenplays in plain, human-readable text.” (Source: Fountain)

If you use Fountain syntax, you can write your script in virtually any text editing program — anything from a plain text editor (like Notepad) to a word processor (like MicrosoftWord or Google Docs) to a dedicated screenwriting program (like Final Draft or Fade In).

That said, when you’re ready to publish your screenplay to PDF, you should use a specialized screenwriting program to auto-format your text.

Personally, I use a combination of tools during script development.

  • I use Microsoft Word (on my Windows PC and iPad) to write and edit my screenplays (in Fountain syntax).
  • I use the free version of WriterDuet to auto-format my fountain text to industry standard layout (font-size, margins, indentations, etc.).
  • I recently used Trelby (a free screenwriting program for Windows and Linux) to generate a Character Report — to help me plan a table read. Reporting features are restricted in WriterDuet to the Pro version, but the beauty of Fountain is that you can mix and match which tools you use.
Trelby Character Report
Part of a Character Report generated by Trelby.

Perform Lint Checks

Software Development

Any coder worth their salt knows to check their code for syntax errors before submitting it for peer review or testing. In most cases, the first test will be to “lint” the code either with the checker built into the main coding tool or in a separate, dedicated tool or automated process

What is linting?

Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise known as linter). A lint tool is a basic static code analyzer.

(Source: Perforce)

If a developer were to skip linting and proceed with defective code, his or her application would likely fail to compile or crash at runtime.

AdLint Screenshot
AdLint  — an open source and free source code static analyzer — highlights some programmatic errors in a block of code.

Script Development

In screenplays, the equivalent of syntax errors is misspellings and grammar problems.

Like a good coder, a screenwriter should employ the best practice of using tools to check for these types of errors, as early in the writing process as possible.

Most writing programs have automatic spell checkers and many also have grammar checkers. For example, both Microsoft Word and Google Docs can check for misspellings as you type. They can also identify possible grammar issues. For me, Microsoft Word provides a robust first line of defense.

An even more powerful tool is Grammarly. After running the proofing tools in Microsoft Word, I copy and paste all of my scripts into Grammarly before publishing them. Grammarly usually finds numerous errors that Microsoft missed. Grammarly can integrate with both Word and Docs to check for errors as you type. I employ this technique in Docs, but I skip it in Word because I find the Microsoft integration clumsy.

Grammarly Logo
Grammarly can prevent embarrassing errors from getting into your published drafts.
Grammarly Errors
Grammarly finds an error in one of my scripts, which I chose to ignore since it’s in a conversational dialogue line. (Note: the script is in Fountain format which is why the typical indentations are missing.)

Squash Bugs Early

Software Development

A truism in software engineering is that the cost of fixing bugs increases the later they are found in the software development life cycle.

The cost of detecting and fixing defects in software increases exponentially with time in the software development workflow. Fixing bugs in the field is incredibly costly, and risky — often by an order of magnitude or two. The cost is not just in the form of time and resources wasted in the present, but also in the form of lost opportunities in the future.

(Source: DeepSource)
Chart
It costs more in time, disruption, and reputation to fix a bug after it has been released to production.

To minimize the cost of bugs in software development, the best practice is to test in as many ways as possible at each step of the process, through some combination of manual and automated testing. Even better is to catch potential problems during the design process and solve for them even before coding begins!

Script Development

The same truism holds for screenwriting: the later you identify problems, the more painful and costly they become.

In addition to typos, misspellings, and grammatical mistakes, “bugs” in a screenplay can include all sorts of other errors. A few examples:

  • Inconsistent or incorrect character names (e.g. you put the wrong name by accident above a line of dialogue).
  • Failing to capitalize sound effects or the first appearance of character names in action blocks.
  • Divergences from standard formatting conventions (e.g. putting “V.O.” in a parenthetical below a character name instead of next to it).
  • Homophone errors (there vs. their, then vs. than, to vs. too, your vs. you’re, etc.). Grammarly usually catches these, but I’ve seen some get past it.
  • Action blocks which go on for too many lines of code without enough white space line breaks, making them hard to read.

Now imagine that your script is riddled with these types of problems and consider how they can increasingly impact your success over the course of the creative development life cycle.

  • While writing.
    Fixing errors as you type is basically painless if your writing software automatically identifies them and/or fixes them as you type.
  • While proofreading.
    Fixing errors as you proof or edit your script is relatively easy. Also, at this point, nobody but you (the writer) has seen them!
  • During peer review.
    If you give your script to one or more trusted readers for analysis and comments, errors in the script may take your reader “out of the story” and negatively impact their impression of your script.
  • After submitting to a competition, producer, agent, or manager.
    When you submit your script to anyone in the industry, you want to put your best foot forward. A “buggy” screenplay will almost certainly hamper your chances of success. Nothing screams “amateur” more than a script chock full of typos and misspellings.

You may have written the next great American action movie, but if a reader bails on the script after ten pages because of formatting sloppiness and typos, then you’ve shot yourself in the foot.


Get Peer Reviews

Software Development

Code review (a.k.a. peer review) is an essential part of ensuring quality in software development.

What is code Review?

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the more expensive process of handling, locating, and fixing bugs during later stages of development or after programs are delivered to users.

(Source: TechTarget)
Woman looking at code
A second set of eyes can catch code errors that the original programmer missed.

Savvy software development teams not only formalize peer review as a required convention, they also build systems and processes that prevent unreviewed code from shipping. For example, in my last tech job as a Software Manager at TripIt, new code could not reach the main source control repository unless at least three peers had reviewed and approved the changes.

Script Development

Peer review is also a critical phase of screenwriting. At minimum, you should have at least one other person read your script to check for typos and grammatical errors.

Ideally, you should give your script to several people to read, especially fellow screenwriters or experienced industry readers. Try to find readers who can not only look for errors but also advise on story themes, character development, writing style, etc.

If you don’t know any other screenwriters or (like most people) don’t have any industry contacts, here are a few ideas for how to connect.

  • Look for local screenwriting groups or meetups. My area, the Sacramento region in California, has several such groups.
  • Look for online screenwriting groups (these are easy to find on Facebook or LinkedIn).
  • Coverfly offers a free peer-to-peer script notes platform. I haven’t tried it yet, but it seems like a good option.
  • Pay for professional coverage from an industry reader. For a price, many companies (and several screenwriting competitions) offer paid analysis. Many writers find this helpful to gauge the readiness of their script. Personally, I’ve relied on the first two methods and so far have not paid for coverage.
  • Organize a table read for your script. Find ways to connect with actors in your community. You’ll likely find many who are eager to practice their craft and would welcome the opportunity to join your table read. You should also consider recruiting some audience members (possibly fellow screenwriters) to watch the read and participate in the feedback discussion.
Monitor with Zoom boxes
I recently organized a Zoom table read of my latest sci-fi screenplay and had no problem finding actors to participate (including several I had never met before).

Here are a few articles with useful tips for organizing a table read.


Use Diff Tools

Software Development

At the heart of peer code review in software development is the diff tool.

A diff tool allows one software engineer to easily review the additions, substractions, and changes made by another engineer.

WinMerge showing a code diff
A code revision in WinMerge, a free open source diff tool for Windows.

Script Development

Many text editing tools, whether word processors (like Google Docs) or dedicated screenwriting programs (like WriterDuet), have native revision tracking (a.k.a. revision history) as a feature. In other words, they offer built-in diff tools.

As a screenwriter, why would you want to compare drafts of a screenplay in a diff tool?

I can imagine a multitude of use cases, but I’ll keep it simple and just describe examples from my own experience.

  • Sometimes I’ve just needed a quick refresher on what changed between two previous drafts or what has changed so far in my current draft.
  • If I’ve made only minor tweaks (a patch change) to a previous draft that I’ve already proofed, spell-checked, and published (e.g. for a reader or contest), then to save time, I can carefully proof just the changes since that draft. For example, rather than the laborious process of running the entire script through Grammarly again, I can check just the revised lines.
  • I can give a reader of a previous draft a diff file, so he or she can review only my revised scenes instead of reading the whole script again. I’ve tried this only once so far, so the jury is out on this use case.

Plenty of free diff tools exist on Macs and PCs and on the web. For quick and easy, diffs, I usually use the web app Diffchecker.

Screenplay diff between drafts
A revised scene in draft 3.0.1 of my screenplay, as compared to the previous draft 3.0.0.

Use Semantic Versioning

Software Development

Software developers use all kinds of version numbers for their applications.

Below, for example, is the version of Microsoft Word on my computer.

Microsoft Word Version Number

As a user, the arcane, long-winded number isn’t meaningful.

By contrast, many developers use a simpler semantic versioning system. Good examples are mobile operating systems and apps. For example, my iPhone is running iOS 14.1 (and 14.0.1 before that).

According to the conventions of semantic versioning, you update the version number according to the scope of the changes.

  • Increment the MAJOR version when you make incompatible API changes.
  • Increment the MINOR version when you add functionality in a backwards compatible manner.
  • Increment PATCH version when you make backwards compatible bug fixes.
Example Semantic Version of 3.1.2
An illustration of semantic versioning.

In everyday terms for the average user, major releases include significant new features and/or design changes, minor releases include small feature enhancements and patches include bug fixes. (In reality, all three types of releases typically include bug fixes.)

This type of versioning system gives a general sense of the scope of changes in a release. As a user, I understand that an upgrade from iOS 13.7 to 14 is going to be far more dramatic than an update from 14.1 to 14.2.

Script Development

In the world of screenwriting, the equivalent of version number is draft version (e.g. first draft, second draft, third draft).

Shooting scripts have specific conventions for handling revisions in order to minimize reprinting, but that’s beyond the scope of my expertise and this post.

By contrast, spec scripts (which is what most aspiring screenwriters are writing), do not have a standard draft versioning system, as far as I know.

So, for my own internal purposes, I have adopted semantic versioning for my scripts. For example, the current version of my latest script is 3.0.1. This tells me it’s a tweaked version of my third major draft.

More generally, I think of script versioning this way.

  • I increment the MAJOR version when I have made substantial changes to the script, to a point where the revisions invalidate the previous draft. For example, I may have cut characters, changed major plot points, cut or reordered scenes, altered the tone, etc.
  • I increment the MINOR version when I’ve made some minor improvements. For example, I may have shortened some scenes, improved some dialogue, rewritten some action blocks to be more concise or impactful, etc. However, the core nature of the script remains the same as the previous draft.
  • I increment the PATCH version when I make trivial changes such as fixing typos, grammar problems and misspellings or if I make minutial changes to the characters, plot, or dialogue.

For the sake of illustration, here is the version history for my latest screenplay:

Chevrons showing version history

As compared to a simpler draft versioning scheme which might rely on whole numbers and/or dates, semantic versioning gives me more context about drafts that I’ve distributed for peer review or that I’ve entered into screenwriting competitions.

To preserve my script’s file history, every time I start a new draft (whether the new draft will be a major, minor or patch level change), I save a copy of the previous draft. In the example above, I have eight different Word files saved on my computer, one for each version between 1.0.0 and 3.0.1. If you use Google Docs, it allows you to “name current version” which is handy if you want to stamp a draft with a particular version number (similar to what I do with Word).


Your Turn

I can’t imagine that I’m the first screenwriter to draw parallels between screenwriting and software development. On the other hand, while writing this post, I couldn’t find anyone else on the web who had written about the topic.

What do you think? Am I stretching the comparison too far? Did I miss any other software engineering techniques that apply to screenwriting? Are any of these tips helpful?

I’d love to hear from you in the comments.