Part 1 Again...
New rule. Never write software for family. I probably would have needed a re-write anyway to deal with all of the strange sorts of things they are doing and all of the short-cuts they need to make life easier. But the real problem with having close relations to the people you are writing software for, is that it is damn near impossible to keep them on the topic at hand. Then, since it seems my parents now actually own the business they also have a separate set of ideas of what it should do, and my brother seems completely disconnected from the whole affair and nods at everything. I almost think he enjoys doing everything on paper (and perhaps he does, he claims to not get technology very well).
So, what did I decide on? Well obviously a complete re-write again, hence the "Part 1". Thanks to code snippets from earlier the Database/Models, Mappings, CRUD operations and service are all completed and the UI is in progress again. Why did I decide on a re-write? Some of the things I did which are perhaps good things in general, added layers of complexity that weren't needed here and then other things lacked layers of complexity that ended up being needed.
Basically, individual tables have become less complicated while there has been a substantial increase in the number of tables and their usage. So, I now have tables for both work orders (what I used to call sales orders) and purchase orders (which I was told I didn't even need last time). I also created a fun little table tied into my work orders for special orders. So the distinction here is that a purchase order is an order to a supplier to bring in inventory, whereas a special order is an order to a supplier that will leave with the customer almost immediately after it is received. Need to track the order and costs, but don't need a full PO to do so really. So it is a single table tied directly to the line on the order it is fulfilling, tracking the vendor, part number, purchase price, a reference number, and all of that fun sort of stuff.
Address and phone information was merged into the customer record. While it was nice to be able to have as many addresses as possible, it seems unlikely they will care to even store the address at all most times, let alone multiple of them. Multiple phone numbers is possible, but I simply created an "Additional Contact" field, and then if they aren't using the address field as I expect, they can always store a third contact number in there. I doubt they will ever need more than 3. And if all else fails, there is no validation on the contents and no explicit limits on the field length so they can really go ahead and 300 comma delimited numbers in the phone field if they really wanted.
I created a lot of the relationships this time around as well. While it may increase my overhead it means I can cascade deletes and maintain the data integrity better.
As far as the UI goes. The "main" screen area will basically serve as a place to do just a handful of things. Add customers and work orders, create purchase orders and receive them, will probably put the customer search in there as well, perhaps as the precursor to creating an order, and then possibly some interactive data tabs showing things like the last customers and orders added, allowing Tony to double click them to bring the editor for those models up, perhaps show work orders scheduled for that day or other information he may want or need to act upon.
Most of these screens will be full screen, trying to cram as much on one screen as possible to save from diving into as many screens as I had before. To save time, wherever possible auto completion will be used instead of pop-ups and most things will simply run off of DataGrids. I think it looks tacky, but functionality is king over looks and if I can make the auto-complete work the way they want, it will probably be much more functional indeed.
This design change means that the main screen won't provide access to the management grids for editing and deleting most items anymore. Remove some clutter and remove temptation and possibility of breaking data (should be harder to break with the cascades, but deleting can still be a problem).
Other things a little further on the horizon are grabbing my reporting code from Veronica's application and then actually writing some reports for them. Great part here is that the reporting stuff always required WPF, but before I had to hack it into a windows form application, this time it will be native which will open a world of possibilities.
Anyway, lots of code done today and lots of writing to accompany it done just now, so I will part at that and look at what Netflix has to offer.
So, what did I decide on? Well obviously a complete re-write again, hence the "Part 1". Thanks to code snippets from earlier the Database/Models, Mappings, CRUD operations and service are all completed and the UI is in progress again. Why did I decide on a re-write? Some of the things I did which are perhaps good things in general, added layers of complexity that weren't needed here and then other things lacked layers of complexity that ended up being needed.
Basically, individual tables have become less complicated while there has been a substantial increase in the number of tables and their usage. So, I now have tables for both work orders (what I used to call sales orders) and purchase orders (which I was told I didn't even need last time). I also created a fun little table tied into my work orders for special orders. So the distinction here is that a purchase order is an order to a supplier to bring in inventory, whereas a special order is an order to a supplier that will leave with the customer almost immediately after it is received. Need to track the order and costs, but don't need a full PO to do so really. So it is a single table tied directly to the line on the order it is fulfilling, tracking the vendor, part number, purchase price, a reference number, and all of that fun sort of stuff.
Address and phone information was merged into the customer record. While it was nice to be able to have as many addresses as possible, it seems unlikely they will care to even store the address at all most times, let alone multiple of them. Multiple phone numbers is possible, but I simply created an "Additional Contact" field, and then if they aren't using the address field as I expect, they can always store a third contact number in there. I doubt they will ever need more than 3. And if all else fails, there is no validation on the contents and no explicit limits on the field length so they can really go ahead and 300 comma delimited numbers in the phone field if they really wanted.
I created a lot of the relationships this time around as well. While it may increase my overhead it means I can cascade deletes and maintain the data integrity better.
As far as the UI goes. The "main" screen area will basically serve as a place to do just a handful of things. Add customers and work orders, create purchase orders and receive them, will probably put the customer search in there as well, perhaps as the precursor to creating an order, and then possibly some interactive data tabs showing things like the last customers and orders added, allowing Tony to double click them to bring the editor for those models up, perhaps show work orders scheduled for that day or other information he may want or need to act upon.
Most of these screens will be full screen, trying to cram as much on one screen as possible to save from diving into as many screens as I had before. To save time, wherever possible auto completion will be used instead of pop-ups and most things will simply run off of DataGrids. I think it looks tacky, but functionality is king over looks and if I can make the auto-complete work the way they want, it will probably be much more functional indeed.
This design change means that the main screen won't provide access to the management grids for editing and deleting most items anymore. Remove some clutter and remove temptation and possibility of breaking data (should be harder to break with the cascades, but deleting can still be a problem).
Other things a little further on the horizon are grabbing my reporting code from Veronica's application and then actually writing some reports for them. Great part here is that the reporting stuff always required WPF, but before I had to hack it into a windows form application, this time it will be native which will open a world of possibilities.
Anyway, lots of code done today and lots of writing to accompany it done just now, so I will part at that and look at what Netflix has to offer.
Comments
Post a Comment