Published: October 20, 2020 • 4 min read
I’ve been working on a development roadmap for my projects, and wanted to share my process. Consider this my recipe to turn an idea into software.
The purpose of codifying a workflow like this is to make working with me a predictable and thorough experience. Writing software is pretty hard; it’s much harder when you don’t have a plan.
Every item here is à la carte– I wouldn’t typically do more, but I might do less on projects of modest scope.
What do I have to show for these words? Several dozen production greenfield and legacy client projects, an in-development startup where I’m Developer #1, and a few things enumerated on my about page. I’m still a work in progress and learning, and this is how I do my best work right now.
Almost everything I know about software, I learned at Hashrocket. This process is very similar to what I’ve done dozens of times with my team there. The main difference is that I’ve added a few steps we don’t typically do, like the competitive analysis, because our clients have usually done that themselves prior to our engagement.
We also have dedicated project managers and designers. For my personal projects I’ve tried to teach myself enough to wear those hats when required.
The flow here also draws inspiration from the following outstanding resources:
Here is my process.
What kind of design expectations are we beholden to, or do we aspire to?
Deliverable: a written document via Google Docs or Basecamp. If neither of those platforms is your cup of tea, chose your own document-sharing service. I think it’s really important that these docs are accessible by everyone at any time.
The first of only a few real meetings! Here’s a great overview of this process from Lucidchart.
A few agenda items for this one-hour meeting:
Deliverable: a productive meeting and notes with actionable action items.
What are the other folks doing?
Who are our users? We’ll brainstorm demographic data about them.
What kind of technology do we want to use? Which boring technologies are we going to use, and are we planning to spend any innovation credits?
Deliverable: written document.
We’ll build a feature map and user flow in Whimsical, and wireframes via Sketch. I’m still refining my wireframes process, and to paraphrase The Pragmatic Programmer chapter 21, I generally ignore:
Deliverable: feature map, user flow, and wireframes.
We’ll produce style concepts and a style guide via Sketch, and high-fidelity mockups via Sketch Cloud. Here I’m taking design and UX more seriously, staying mindful of the Iceberg Secret.
Deliverable: style concepts and style guide, mockups.
If we haven’t already, we’ll make a high-fidelity clickable prototypes via Sketch Cloud. Then, we’ll do development estimates via storycarding, using Vim Slurper, BDD syntax, and Pivotal Tracker. Finally, we may make a development proposal, a written document in Basecamp or Google Docs.
Deliverable: prototypes, stories, written document.
Time to write the code! Over many posts, this blog summarizes how I’d handle this phase.
We’ll be doing Agile, iterative development, with daily standups, refinement, estimation, planning, development, delivery, and retrospectives. The deliverable is the universe-denting software.
When we’re finished, we’ll launch! 🚀
Deliverable: working software to specification.
That’s it! I plan to update the workflow periodically as I continue to ship and refine. I hope this was helpful.
What are your thoughts on this? Let me know!
Join 100+ engineers who subscribe for advice, commentary, and technical deep-dives into the world of software.