I have a college-ruled notebook that I bought for a dime some years ago. I carried it to college with me and kept it in a box under my bed. Now, almost a year after graduation, I can still see that notebook sitting on the bookshelf to my right. Contained in that notebook is every project idea I have had in the intervening years and considered worthy, along with a bevy of notes and scribbles about the goals, design, and often implementation of that idea.
This long-term series is going to take the first idea entered into my notebook, in fact, older than my notebook: a minimalistic, old-school, single-player, open-world, 2D RPG.
This is hardly ground-breaking or original. The market is filled with such things and each has their own twist or gimmick. That is fine. I’m here to learn new things. I own this project and have the advantage of being able to do what I want.
So what do I want? I’m going to lay out a list of general goals here so that I can periodically remind myself. Many of these goals will be difficult to quantify and define, but I’m going to list them anyway because those are very commonly seen software requirements.
Goals
- Be able to build confidence in my code through the use of unit testing.
- Unit testing cannot prove that something will work 100% of the time but it can show that something is more likely to be correct.
- Unit testing can be very important in recognizing that existing functionality has been compromised when adding new functionality.
- I’ve never done this before and I really want to.
- The user should have a good user experience.
- This is the http://en.wikipedia.org/wiki/Kobayashi_Maru no-win scenario. Pleasing everyone is quite difficult.
- Certainly, this is completely subjective, but a good place to start is maintaining consistency.
- To have a working piece of software.
- No matter how elegant the code, mind-blowing the idea, or enthusiasm of the developers, it has all been for naught if there is no working software. See the Agile Manifesto: http://agilemanifesto.org/
- That I should enjoy using the software.
- I’m a user too and I want a good user experience. After all, what use is making a video game if you don’t want to play it?
- Some of the best software is written when the developer is a user himself. When the developer understands the process, workflow, and use cases, he may suggest improvements. If he doesn’t understand, then he reads the design document and hopefully gets to talk to someone who does understand, but the developer is unlikely to suggest any improvements because he has no clue what is really going on.
- To readily accept changes.
- “No plan survives contact with the enemy” http://en.wikiquote.org/wiki/Helmuth_von_Moltke_the_Elder
- The user will always want changes to the software. Software is too complex to plan for every contingency of unexpected behavior.
- Being the developer and primary user of a piece of software brings its own risk: feature creep. The trick is to balance it with working software. Amazing features being added are useless if the core doesn’t work first.
Those are the general ideas. Notice I didn’t actually list any specific requirements of what the software should do? I’m going to slowly unveil those with each week’s blog post.