Alex Vs. "The Code" - Round 1

Iteration 1 for this project was a real eye opener. Or rather it taught me the hard way that I should have followed things I knew to be best practices. I had stuck with a lot of technologies I had worked with the past and thought I was playing it safe and things would work out super easily without any bumps in the road. I was wrong.

Some background on my first stab at this. I didn't like the software Veronica was using in her shop. It was ugly, simplistic (not really a strike against it, just a reason I could replace it) and had an annual license fee. At the time I started it, I had no need to complete the project so it got done off and on in my spare time.

As stated, I chose things I either knew well or had worked with in the past. The UI was all Windows Forms, I chose SQLite for the database and a demo version of a proprietary software for reports (receipts actually in this case). And a bit shamefully I will admit that I also started off without using a version control system of any sort which came back at me regularly.

Despite not having anything driving me, once I really dug into it, I probably finished the code within a week. However, everything was heavily coupled together making changes difficult and, because I had no version control, I also knew any change was potentially dangerous.

This first draft was not terrible, but I had missed a few things in the design phase that needed to be hacked in over the life of the project. As a result, when Veronica finally tested it and found a bug, it was more pain than I was willing dig through to fix it.

So began the planning for Version 2!

I learned some valuable things from this iteration:

- No project is too small for version control. I may have been able to salvage the project if I hadn't been so afraid to break it. And there were times, where from weekend to weekend, I would want to go back and see what I had done the prior week, but the code was now gone. While this should be an obvious point to anyone (including myself) I need to point it out again, because despite knowing it, I got cocky and went ahead without following this basic piece of advice.

- Choose tools that suite the needs of the project over ones you know, this may mean doing some research first. In my case I chose a reporting software I knew already. I spent extra time just making it do what I needed it to and could never make it do the things I wanted it to do and we would have needed to pay to use it legitimately. Between the extra development overhead and cost I could have easily justified spending a few more hours searching to find either a better or cheaper solution.

- And hot on the tails of the last point. Do some investigating beforehand! I was flying blind for the most part. As an example I had written a home grown engine for communicating with SQLite, and while it worked, there were better and easier alternatives out there with more mature feature sets that would have made the code more flexible. At the time I had done no research and felt the learning curve for some of the frameworks I knew were out there were too steep to be beneficial. But again I was wrong. I was trying to map database records to objects and doing this all in my own manual code tied the entire data layer so close together that database changes were suicidal.

If I have some more time this week, I'll try and dig into the things I did in version 2 of the project to address the things I learned/reinforced during this first attempt.