Principles of Project Planning by Don Burks is a book for junior developer on how to execute a software project from start to finish.
The small booklet is easy to understand and contains some helpful tips for people new to the tech industry (coding bootcamp graduates, freshly minted CS graduates or other career changers).
Here are my notes.
TL;DR
Don’t start a new project fresh from an idea. Take your time to plan the data, user specifications and design.
The Idea
No one hires you to code.
In every case, you are being hired to build and/or maintain a product. Yes, you will likely write code to build and/or maintain that product, but as a point of fact the purpose for bringing yoyu on as a developer is for the product.
Think about what the code is supposed to do.
It’s ok if your idea is not novel, if you can specialize, extend, enhance or internationalize an existing product.
Don’t pitch your idea to friends or family. They won’t disagree with you.
You need to validate your idea by strangers willing to give you money for your product.
Data
Your data is your product.
3 important questions:
- What data can I access or acquire?
- Can I correlate that data to something else?
- How do I pivot the correlation to provide value?
Features vs. Benefits
Users pay for benefits, not features.
Universal values:
- Look good - we love to look good to others.
- Feel good - internal view on ourselves.
- Save time
- Save money
Try to address at least one of those values.
User Specifications
User stories are a useful tool to help find a list of features to ship.
As a <role>
I want to <action>,
Because <positive outcome>.
The “because” serves to point out the specific benefit to the user.
User Scenarios describe the actual mechanic and situation in which a feature is experienced.
Given <some context>,
When <some action is taken>,
Then <some outcome occurs>,
And <some visible result is seem>.
Example:
Given that I am logged out,
When In enter my credentials and submit the login form,
Then I am logged into the site
And I can see a logout link.
User Specifications combine User Stories and User Scenarios:
As a <role>
I want to <action>,
Because <positive outcome>.
Given <some context>,
When <some action is taken>,
Then <some outcome occurs>,
And <some visible result is seem>.Info:
<Metadata about spec here>
The author recommends writing User Specs for all of the features.
Feature Complete
Decide what “Feature Complete” means.
- Pick a deadline.
- Define what features will be delivered.
- Stick to it as much as possible.
Real life has constraints — you don’t have infinite time and infinite budget.
Ship a product. Software is never done, but you still need to decide which core features you want to deploy.
Glossary:
- Testable — implemented feature that needs to be tested to verify and validate
- Shippable — tested code that works and executes the feature as designed
- Finished — shippable code that’s been reviewed, refactored, and revised until it is the best implementation which can currently be delivered.
Test your code.
Deployment
Make some decisions about how you plan to deploy your project: domain name, hosting, DevOps.
Be aware of common pitfalls, e.g., CORS.
Database
The most important technical decision is how you store your data: SQL or NoSQL database, Single vs. Multi-user databases.
Guiding principle: store your data the way you intend to query your data.
Make sure to do your research if you use a DBaaS (Database-as-a-Service) to be clear about query limit thresholds and scaling.
Design your data with an ERD (Entity Relationship Diagram). The data model is the core of your application.
What are the major “nouns” of your product? Look at your User Specs.
The ERD is an initial sketch and not set in stone.
When building the ERD, get input from all stakeholders.
Technical Architecture
Pick the programming language first. If you have many people working together, democratize the ability to contribute. Pick a language that allows most people to share ownership of the code-base.
Weigh the learning curve for the stack you choose.
What is the secret sauce of your application? How much of it do you plan on coding from scratch?
Talk to other developers who may have used the libraries/frameworks you are considering.
If you want to use a front-end framework, be aware that you are most likely duplicating your data models on the front-end. Most of your business logic is now going to be in the front-end as well.
Routes
Plan your routes/pages/views.
If you build an API, what are the endpoints?
If you build a mobile app, what are the “views”?
Look at the User Specifications.
If data models are nouns, routes are verbs.
Design
- Wireframing
- Storyboarding
- Design
Wireframing
Create a layout for your data. Demonstrate the significance and relationships of your data in a meaningful way.
Don’t invent data during wireframing. Allow the design to be sparse and minimal.
Wireframe interactions.
Every data point you plan in a wireframe must have a provenance, or source, in your ERD.
- Does my navigation scheme work with the rest of my content?
- Would a user understand the most important data points on this page?
- Have you accounted for every bit of UI interaction a user needs with the data you have presented?
Storyboarding
Storyboarding is the practice of visually ordering elements of a story in chronological order.
Plan out how a user will progress through your application. Build your navigation to match.
Challenge your assumptions.
Design
You are a developer, not a designer. The design matters.
It’s ok to use themes.
CRAP: Contrast, Repetition, Alignment, Proximity.
Contrast focuses our attention and highlights most important parts.
Repetition ties objects and images together.
Alignment indicates polish and strength. Applications are organically organized in rows and columns.
Proximity implies a connectedness. Group related things together.
Put time and effort into making some informed decisions about the appearance and interactions of your product.
Version Control
Use it.
For Git, use a good branching strategy. Don’t develop on the master/main branch.
Name your branch feature/name-of-feature or bugfix/name-of-bug.
Test your work before you merge to master. Then test again on master.
Scaffolding
Establish your dev environment and make sure that it works.
Build static placeholder content first and make sure that your layout and styling are going to work.
Solve layout problems now, not later.
Start with your database models first. Use the REPL or CLI to test your queries before you build that business logic into your application.
Code atomically.
Methods and modules should follow the FIRST principle:
- Fast
- Independent
- Re-usable
- Simple
- Testable
Communication
Use project management tools to track tasks.
For example, use a Trello board for User Stories. Use the attachment feature to like your ERD files and wireframes.
Communication is critical: what tasks are being worked on, ideas about implementations, conversations about the best way to approach a problem, etc.
Be accountable to each other.
The entire team is responsible for the delivery of the product.
Set expectations accordingly.
Technical Debt
Development work that you chose not to finish before shipping your product
Use proper scoping and planning to avoid common reasons for technical debt.
How much technical debt can the team justify leaving in a product when it is deployed?
Find a balance between done and deployable.
Further Reading
- Principles of Project Planning by Don Burks