I am currently a firm believer and a practicer in the Three Day Project Paradigm. This is, simply put, that one can learn a lot by building 100% of a project within the timespan of three days. It is worth noting that, given my current state of unemployment, this means 3 full days rather than three evenings. What sort of lessons can we get from such a project?
First, open-ended projects can have the tendency to drag on. Putting a limit on the length of the project automatically stops this. The time limit forces one to properly spec out the idea before simply diving in and coding. It has also forced me to budget my time in very specific ways. For example, my timeline might go something like this:
- Pick an idea.
- Create a precise feature list.
- Design the software. Whiteboards are excellent for this.
- Create a skeleton of the modules, classes, and functions required for the given features. Do not flake out on this step! The more parts you skeleton in, the more you will understand the potential issues of your own project.
- Flesh out the major routines with pseudocode.
- Make the app work (or at least start), and start building in
- Discover potential issues, re-design anything necessary, and continue hammering away.
- Have a major code re-factor before the end of the day. It is ultra important to not leave your code in a state of disarray. If anything gets out of hand in terms of being difficult to read or understand, crack down on it as soon as possible.
- Code the final features.
- Fix any bugs after performing as much testing as is reasonable.
- Tidy the code.
- FINALLY, write up a short report about the shortcomings of the project, your future goals for the project (were you to continue), any bugs you were not able to fix, and what you learned/what you would do differently. This really helps to tie off the project and make sure you’ve learned something.
Day 1 is all about figuring out what you’re going to be doing. If things go well, you can jump into Day 2’s tasks, but everything in Day 1 helps to make sure the rest of the project is finished expediently. Having a whiteboard with my plan on it helps to keep me focused on the original idea.
The initial feature list can include room for improvement if the project is finished early. Those extra features should be categorized as such, however, or else one risks skipping other important tasks.
As a fan of the PPP (Pseudocode Programming Process), on Day 2 I like to really flesh out some of the routines before I get to coding them in. In my most recent project, a Blackjack implementation in Python, this involved writing out the game loop in detailed comments before actually coding any of it. If the primary game loop (ie. receive input from player, output result, repeat) is not set up well, this can only lead to problems. This can apply to just about any program, as it is likely that you will have some sort of module that will activate the rest of your code and communicate with the major classes.
The final day is really all about making sure all of your features are in place, and that the cody is tidy and readable. Make sure that the idea is to make your project open-source so that other people can contribute. With this in mind, you will start to notice how horribly unreadable your code can be.
I find the report aspect of the project to be very rewarding. My Blackjack implementation was actually completed in order to secure a phone interview, and the task happened to fit perfectly with the Three Day Project Paradigm. I made sure I put together a report so that they understood that I was well aware of my own project’s shortcomings. Indeed, it is far from perfect, and there are a number of things that I would change and refactor.
For an example of such a (less than perfect) project, please visit my github at github.com/danielmoniz/blackjack. Browse the README and the REPORT files if you want an idea as to how the program functions. It allows for people to create AIs to count cards using any method they desire. This means that people can simulate card counting and statistically determine best methods.
Do note that the Three Day Project Paradigm is a work in progress, and I will accept constructive criticism from anyone with experience. I hope somebody will get something out of trying it out.