"Nothing in the world can take the place of Persistence. ... Persistence and determination alone are omnipotent."
- Calvin Coolidge
When you're slaving away on any long-term effort, there may come a time when you're a few months into it but nothing much actually works the way you want it to, and all you can see is the huge gulf between your current position hip-deep in mud and your original vision high in the clouds. At this point it's really easy to get discouraged, to lose sight of your overall goals, to feel that you're not getting anything accomplished, and to prematurely conclude that the whole project is and always was pointless.
There are many techniques which can help defend against this danger, one of which is to log the completion of every development task, even the little ones that seem trivial but which eat up inordinate amounts of time and energy. With that kind of work-log, you can look back and objectively see how much you've accomplished and how far the project has come, so I keep such a log for JIFFEE.
While I seriously doubt that anyone will care about the details of this timeline, I'm posting it here so that if you're contemplating anything similar you can get some little inkling of what you're getting into. The purpose here is not to scare you away from large projects; on the contrary, the purpose is to increase your chances of success by helping you embark on any such project with realistic expectations so you don't needlessly abandon your quest half-way up the mountain.
To add a bit of perspective, I call this "long-term" but not "large-scale" development, because after spending many years working for big software shops, "large" to me means over 1 million lines. At under 10,000 lines JIFFEE is still well within the realm of "small-scale," but with a single developer working in spare time even that can take years to really get right.
For those who don't care to read every line, here is an executive summary of a few of the points that can be gleaned from the log:
Only two weeks into the project, there were already hundreds of lines of running code. That's a great thing for morale, but never let it deceive you into thinking you're almost done. It's a bit like learning to play a new song on the guitar - the first time you make it all the way to the end doesn't mean you've finished learning it, it means you've started to learn it.
Sure enough, a few months later most of those hundreds of lines had to be discarded or re-written when I discovered that I had coded myself into a corner with a subtle but fundamental architectural flaw in the system. Then the following year I touched most of those lines again when I realized that my module-linking mechanism stunk and needed to be completely overhauled.
Weeks to make it work, but years to make it simple.
There were repeated times when I changed A to B, only to later change B back to A. Yeah, that happens, especially when some other change C alters the overall environment/design and reverses the original rationale for the first change. As long as you have a good reason for the reversal, don't worry about it.
There was (and always will be) a huge amount of "support" work to do, like setting up a nice website (and then later migrating it to a new hosting service when the old one closed), writing documentation, testing out the system with real users, re-designing the parts that still feel clunky, etc. etc. etc. Work like that won't increase your "line count," but it all takes time - a lot of time. Keeping a log lets you give yourself credit for that very necessary but otherwise almost invisible investment.
Stuff happens. In December 2008 my primary development computer died, just before I had a week of vacation scheduled to make a big push on the next release. It was two months before I found replacement hardware that I was happy with and got it configured the way I like it, and that left me scrambling to have a partial release ready for the next class that I was already scheduled to teach. It could have been worse: Since I'd been careful about regular backups, I lost schedule but did not lose any files.
There were multiple mini-releases of JIFFEE to very small groups of 3 to 5 alpha-testers (my Citizen Schools apprentices). Instead of surveying them, I actually watched them use the system and answered all their questions personally in real time. Your mistakes quickly become clear that way. It works even better if you can find somebody to help you teach, because she'll see patterns that you are blind to.
Although this is an individual project, lots of other people have helped me in various capacities. Like many programmers I'm a pretty solitary guy, but a project developed in total isolation is unlikely to succeed.
Vacation time is precious. Spending an entire day focused on a project can be wonderfully helpful. A whole week is even better.
On the other hand, there are gaps of days and even weeks with no development activity at all. That's because I have a life, and I hope you do too. Turn off the computer, play with a dog, kiss someone you love, teach a kid to fly a kite.
And now, without further ado, here is the log:
All ye code warriors with courage enough to gaze upon the dragon, cast off your rose-colored glasses and behold the glorious, gruesome path of software development.
JIFFEE and JIFFEEgames.com copyright © 2007-2010 by Michael S. Kenniston. All rights reserved. This page was last updated on 2010-01-17.