Skip to content

Instantly share code, notes, and snippets.

@chris-jamieson
Created March 9, 2017 16:06
Show Gist options
  • Save chris-jamieson/cc15cb19f22a36390048d9101aae36e2 to your computer and use it in GitHub Desktop.
Save chris-jamieson/cc15cb19f22a36390048d9101aae36e2 to your computer and use it in GitHub Desktop.
Writing functional specification guidelines

Once you are ready to hire a developer, what should you do to mitigate execution / build risk?

  1. Writing a good functional specification is key to getting the build phase of this project right. It's not easy to do but it's mostly just about thinking hard and writing out all the boring details of your desired outcome. The best guide for this is Joel Spolsky (recently sold Trello for $425M). He wrote a 4 part series on this, starting here, and also has an example (real) spec on his website here (the PDF link is broken, this is the real one)

  2. Before you start on a spec, trim down your functionality to the absolute bare minimum - and be brutal with it! Imagine you had to complete it in one day, or imagine it was only a single feature... take away everything that isn't fundamentally important to giving the user value. As Martin Fowler says, for everything else: you ain't gonna need it.

  3. Make something that works, then improve it over time. Don't get stuck in the trap of thinking "if we just add this feature / optimisation / clever data model up front, it will save us time later when we need to [handle some other functionality requirement]". You have to get comfortable with the prospect of throwing stuff out later and starting from scratch - and this actually makes the application easier to build over time, not harder, because later you'll actually understand what your users want, whereas now you're just guessing (you have no users).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment