bertwagnerHow I break down projects to increase the chances of success.
I am about to start working on a new programming project and I’m trying to think about what I can do to try and guarantee as much success as possible. For me, the most important time during project creation is the first few days or weeks while I am still extremely excited about what I am doing. During this time, I am able to work happily on the project and not get distracted by other ideas or activities. Therefore, I’ve determined that in the first period of excitement it is critical for me to get the minimal viable product fully built out and coded. If I don’t, rarely will I be able to create any additional excitement to keep the project going. If I’m able to get a working version built early on however, my excitement doesn’t wane and I can continue working on the project, adding features over time.d
Until recently, I never gave much thought to prioritizing the most important features of a project; sounds dumb, I know, but basically I would work on whatever I felt was “sexiest” — meaning using some new language, framework, or concept that I haven’t used before. This has been my downfall many times because when learning something new, there is inevitable frustration. This frustration always lead me to give up on the project before it even was built. This is why I now have switched my focus to building the minimum amount of features as quickly as possible to get my minimum viable product working, using techniques that are mostly familiar to me, so that I can get it done quickly. This way, I hope I can keep the excitement momentum going.
Plan, plan, plan
The key for me in building a successful project (meaning one that gets finished) is by first planning everything out on paper. This planning is never incredibly detailed, but it does provide me enough of a roadmap to help identify what my biggest challenges will be. Some upfront planning also helps me solidify things like program and database design, and lets me think through multiple options. Going through this iteration of different designs while on paper is much easier and faster than building out a version in code and then realizing it has to be scrapped because it doesn’t work well.
Trim the fat
Once I figure out the rough design of a program, I try to identify all of the features that are critical to get it functioning as quickly as possible. For example, if building a to-do list application, I might consider building a user registration and login system so people can manage their own checklists. Is this critical though? No, I can build the app so it only works for one user initially and worry about a multiple user scenario later on. I could use some new and popular animation library to work on animating the checklist items on the screen — but is this important? Definitely not — this kind of stuff causes many hours of frustration to occur with very little final product to show, so I skip it initially. Do I want to build basic functionality to let the user add and delete items on the checklist — YES! This is definitely highest priority. Once I figure out what features are critical to get the application functioning, I work on those first.
Just Do It
Just like Nike’s slogan, at this point it’s go time. I set my deadline for getting the first version of the program built as quickly as possible. The sooner the better. This is critical for me because initial project excitement is short lived and I know I have to create a functioning app before that giddiness runs out. I’m much more likely to get through road blocks in this phase as long as I’m still making noticeable progress and I need to get a working version of the program done before I hit a major road block.
Is it still worth it?
This is the question I ask myself once I get my minimum viable version of my app done. At this point the app will still look extremely ugly, usually all black text on white backgrounds, but I should be able to navigate through actions and get a feel for how the final product will work. Does the process to perform an action seem clunky or too complicated? I go back and fix it — good thing I didn’t waste hours on making a nice looking design. I can afford to lose what I built because at this point I simply don’t have enough invested in it to care; I can think a lot more clearly about it if I can emotionally separate myself from the work I put into it. If things are working well and I’m happy with the basic app functionality then it’s time to keep going.
The reprioritization and build cycle
At this point I keep adding the most essential features. After every feature I add, I try to reevaluate if I am still working on the most current feature. I might hit some stumbling blocks along the way, like realizing I need to modify my database design sooner rather than later, and so those items get prioritized higher on the list of features that need to get completed first. But by constantly reevaluating and reprioritizing the feature list, I guarantee myself that I am working on code that is adding immediate value, is satisfying to work on, and is bringing the project closer to completion. Becoming discouraged or disengaged is difficult when you set yourself to succeed frequently so early on in a project.
Get feedback
Launch the project before it is done. This could just be to a couple friends or it could be public. Getting feedback from others early on will help steer you in the direction of the most important features, as well as give you that instant gratification and encouragement to keep pushing forward. Don’t be afraid to show the world your unfinished baby.
Reprioritize, iterate
With each version that you release you will be able to decide 1)is it worth continuing to build this app and 2)what are the next most important features. If you like how the app works and you get feedback of other people saying they like the app, then that is good motivation to keep working. Feedback will also tell you what is most important to add to the program next. Eventually you will get through your critical list of functional features and you can work on some of the more of the less important things like design, animations, etc… At this point if you get frustrated on trying to learn something new it’s not as big of deal — you already have a functioning program that is being used. If you can’t animate the to-do list item additions/deletions slike you originally envisioned, that’s ok — at least you can still add and delete items! Maybe you can find an alternate way to make the design better. The point is, by the time you have a functioning app, these types of roadblocks will not be as discouraging and you will still feel accomplished with a job well done.
Finish it up
Eventually you need to decide when your app has enough features and you can switch to marketing/using the app in the real world. That doesn’t mean you won’t ever modify the program again, it just means that real world use and feedback will help you determine what changes to make in the future, if any. It might also turn out that your app works well enough without the need to iterate any further, and you can decide to then start on the next project idea that has been bouncing around in your head.