The Goldenseal accounting & estimating software is written in the C++ programming language. It’s about 1000 files, organized with OOP: Object-Oriented Programming. OOP is by far the best way to create large, complicated apps. It uses classes to make code seem more like the real world.
For example, for material purchases, our accounting software has a CMaterialPurchase class. It stores all the data for purchases. The class also has functional code: to calculate sales tax, post job costs, and handle accounts payable, time & materials billing and price updating.
When you open a screen to work with purchases, the CMaterialPurchaseViewer class makes the fields and buttons work properly. Every other data entry window has a similar pair of classes: one to store the data and business logic, and one for screen appearance.
Classes usually have parents. For purchases, it’s a CExpenseTransaction, which also includes subcontractor and other costs. That inherits from CBreakdownTransaction, used for everything with a breakdown table. Its parent is a CTransaction, for all types of business transactions. There are a few more layers above that.
We started programming Goldenseal in the early 90s. Back then, C++ was just starting to become popular, and OOP was a recent invention. GUI frameworks existed, but they were immature. Our programmers had to design many things from scratch.
Sometimes we made things too complicated, with too many classes. That was definitely the case for the eight action commands: Reconcile, Pay Bills, Deposit Funds, Project Billing, Sales Billing, Rental Billing, Write Payroll and Job Costs.
We just finished rewriting the last of those. One reason it went slowly is because everything needed a huge amount of refactoring. Project Billing was the hardest. It slimmed down from 24 classes to 5. Write Payroll was also difficult. It dropped from 16 to 5. Job Costing pared down from 11 to 5. The others went from 8 to 5. It also was a chance to redesign and improve a few things.
Refactoring is quite a process. Sometimes we copy code and paste it elsewhere, then tweak and rewrite until it works again. Sometimes we delete obsolete code, then clean up the mess left behind. Sometimes we rename things, just to see how they work. Along the way we try to figure out the quirks.
Goldenseal has all sorts of weird code for retainage, money paid on account, different types of change orders, salaries vs hourly, yada yada. Running a business is complicated. All those business eccentricities seep into the interface, and it takes effort to move them to a new framework.
Most likely we missed some things, or messed up code that we didn’t understand. The same applies for everything else that our staff has done in the past 15 months. The good news is that we have finished at least a first pass through all parts of Goldenseal. Everything is doable, even if it’s not perfect yet.
So, it’s finally time to move on to the next phase for TurtleSoft Pro. Testing, and retesting, and fixing everything that isn’t right. I’m sure it will take all winter.
At least we have a well-tested app to compare it with. We don’t have to think through all that logic again, or fix 20 years of bug reports from users. We just need to make TurtleSoft Pro act the same as Goldenseal.
Dennis Kolva
Programming Director
TurtleSoft.com
