Swimming In Code

I've been up to my neck in code the last little while — mostly poking around in the graph drawing classes. I have noticed a lot of drawing bugs in the graph, and I decided it was time to put my refactoring hat on while I was in there. I write a lot of non-object-oriented C code, and rarely worked in a role where my primary responsibility involved writing up class hierarchies. Most of my OO knowledge comes from these side-projects that I work with, and projects I did in school. So, object-oriented design doesn't come very naturally for me. As a result, I tend to start out with a procedural style, but wrapped up inside classes. Then, the design evolves. FuzzMeasure 1.0 was (mostly) one single class, with no document-based structure to speak of. It consisted of about 20 or so source files, with a lot of weight on the main window controller. FuzzMeasure 1.2 was almost a complete rewrite of 1.0, because I had to shift the operation into a group of classes that better utilized the document-based app organization. Now, 2.0 carries much of the same code that 1.2 had, but I totally reorganized a lot of my signal processing code and graph drawing code. These two areas alone represent a lot of arduous design and development work. Unfortunately, I gave up too early on my graph drawing classes when I first ported the code over from 1.2, because they worked fine. However, now I'm adding new drawing types to the graph, and the design's not holding up very well. So, taking a page from Agile methods, I'm iterating over the design to fix it up now that I've encountered a problem with it. So, as you can see, the iterative method works pretty well. I started out with a project that came naturally to me, and kept improving it over time. I released my product nice and early, and started gaining users (and, more importantly, money). Had I started out with an insane design, I would have taken much longer to release my 1.0, or I might have given up on it completely out of frustration. Back to coding for me!