How to Plan a Project: Learned Tips From a Terrible Project Planner
I am the worst about flying blindly into a project, so for my phase 2 project ( a fun little web-app where students at Hogwarts can attend a class to brush up on their magical skills), I decided to take a different approach:
Yeah, I know. That’s a lot. Let me break it down for ya.
First I broke down my User Stories into CRUD actions. This gives me a clearer idea of how I want my app to function and what methods I might want to implement to achieve functionality. I tend to like really ambitious ideas, but I had to limit myself a little to make sure I get this WIP wrapped up in time! Still, I don’t want to forget them if I have some extra time to add bells and whistles, so I have some stretch goals right outside of my User Stories box. Y’know, just for funzies.
Below that block I have a breakdown of my schema. This is going to help me better visualize my MVC structure. I have three main models here (Teacher, Student, and Skill) and two joins (CourseStudent — written just as course here — and StudentSkill). Each will end up with a model and controller class so we can define behaviors and how the pages of our app “move”. Not all of our models will have views (CourseStudents and StudentSkills for example are built to create interactive functionality between our main models), but those that have views will have a number depending on what we want to do with these models. Since each model might have several different views, we’ll drop a folder titled for each model in app>views to store all our fun lil’ view files in.
My schema map will eventually be converted into tables in my database. The details in each individual box will serve as column names for each instance’s attributes. If you look at the join tables you’ll see that they have columns for ids from the main models. Those will get generated as we create our tables. It’s important to create these three first! I stumbled across a problem getting my tables to work at first because I had created them out of order. Always make your joins last!
You’ll notice I also have arrows between each box indicating relationships between certain models. This information will be particularly important in the model classes. We want to make sure these make it into each model’s class code so our program understands the relationships between them:
EX:
class Student < ApplicationRecord
has_many :course_students
has_many :courses, through course_students
has_many :student_skills
has_many :skills, through: :student_skills
end
So now that I have my backend sketched out, let’s take a peek at the right side of the page. I have a different roadmap drawn out for my models, this one illustrating the view pages and the functionality of each. For ease of reference, I highlighted each of my CRUD actions in a different color. That way I can tell at a glance that I have all my actions accounted for. Looking further at the boxes, each details what kind of view each page will display, as well as the functionality expected of each page and where it should lead next.
Exciting! It looks like I have enough information to get started on my app!
Even though this all looks pretty solid, it’s important that I’m not married to every single idea here. Until I have working code, this is essentially just brainstorming. I’ll probably break and fix this setup multiple times before I have a finished product, and that’s okay! Programming requires both planning and flexibility and a fine balance between the two.
So, why is all this so important I’m dedicating a blog post to it?
Well, my last project I kinda flew through on the seat of my pants. I did okay but I know I had the ability to do better. By breaking my project down piece by piece I have been able to accomplish several things:
1. I have a much better understanding of the relationships between my models and how they should interact
2. I have a clear visual of how my app should look and function, and of what methods I’ll want to use.
3. I have a clear path that is easily broken down into steps (ex: create, server, then table migrations, then mvcs, etc…) that I can use as a checklist to make sure I’m hitting my goals in time and that I’m not forgetting anything.
Already by following a more clearly defined project plan, with as many details pre-considered as possible, I have created a more stable base for my project in half the time it took for my (much smaller) phase one CLI app project.
If you find you like to dive in head first and then immediately find yourself drowning, I highly recommend trying a similar breakdown. It will help clarify and solidify your idea, provide a list of trackable goals, and might even unearth some problems in your idea that weren’t as tangible in your head.
