I’ve been programming for over a year now, but today marks the first time I’ve ever written a technical spec. Since my work has all been within the context of programming classes, the applications and programs I’ve written have all had stringent functional requirements, and many had equally strict aesthetic guidelines. What’s more, most have laid out a suggested development path, often with obvious hints as to what data structures and algorithms to use. I had my first meeting with my project advisor Prof. Steve Cooper last Monday, and he tasked me with my first assignment: plan my project. The guidelines? Hardly the 3000-word descriptions (seriously) that I’m used to. Instead I got, “Write something that will enable you to create your program.”
So I’ve found myself in that wonderful but daunting place of having near-total freedom to shape something in which I’m heavily invested. Steve told me that I could draw pictures in my notebook for all he cared, but I was pretty sure I’d end up with some gloriously formatted, highly detailed, neatly illustrated document. I did not disappoint myself, but I may well have created several hours’ extra work for myself. A little Googling led me to this quick-and-dirty guide to planning a piece of software, which was a lot more helpful than the idiosyncratically divided, UML-extolling templates I found. Ultimately, this isn’t for anyone but me, so company style and universal readability aren’t priorities.
Since I had a good idea of what I wanted the UI to be like as well as what features I need, I decided to start with a wireframe and then move on to the written portion of the events, updating my wireframe as necessary. I found an online diagramming tool called Gliffy, and I can testify to its utter beastliness. It’s right on that sweet spot of nothing you don’t need and almost everything you do. I’d love the ability to lock and see a list of layers, but working around that wasn’t too hard. Here’s my first hack at a main transaction interface, heavily inspired by restaurant point-of-sale software like Aloha.
Sure beats the kind of result I could achieve using PowerPoint, huh?
The further along I got in my spec, the more I realized how much I learned in my databases class. To be honest, I found several sections of it tedious (especially the section on Boyce-Codd Normal Form and Multivalued Dependencies, which I find much easier to understand intuitively and through real-world examples than through codified formulas and toy data), but I’ve come out of it with a confident grasp on designing databases and writing powerful queries.
I’ve also got a lot of questions about the relationships between backend databases and runtime data structures. It seems inefficient or silly to query a very small database many times to get the information I need, which suggests that loading the database contents into a Java object would be prudent, but I wonder if that’s redundant. Or what about objects on the frontend that could – but possibly shouldn’t – include data. For example, my instinct is to have the product buttons store only the product’s unique ID and get the price information from a product database object, but I might just as easily store the price in the button object, too. The good news is that I’m surrounded by people who can teach me about best design practices and help me make these decisions.
Tomorrow morning, I’m going to try to set a timeline for my project and practice using Git on Windows. Until then, however, I have meetings to attend and Whitman, Mills, and Mailer to read! (And sleep to get, naturally.)