OOP (Dec 1)

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

Zeros & Ones (Nov 19)

You probably start with number one whenever you list things. Generally that is what the Goldenseal code does, too. 1, 2, 3, 4, 5… The current version is based on a framework called PowerPlant, which also starts lists and table rows at number 1.

The C++ language starts lists at zero. 0, 1, 2, 3, 4… Hard-core programmers will give you all sorts of reasons why zero is better than one. The Cocoa framework that we used for 3 frustrating years is also zero-based. So is the Qt framework that we use now.

When two number systems collide, it is very easy to get “off by one” bugs. There are many ways to make those even when you don’t have two different numbering systems, but a mix of 1-lists and 0-lists makes it extremely easy to err that way.

When we set up breakdown tables last spring, our staff solved the conflict by using 0-based rows and columns in the Qt tables that are visible on the screen, with a conversion when they talk to the original Goldenseal tables that lurk in the background. Add one when going down, subtract it when going back. That way the existing business logic still worked OK.

For action commands, it wasn’t worth keeping the original Goldenseal tables. Not enough code in them to justify their existence. So, those dialogs do everything with 0-based tables. Unfortunately, it created many off-by-one errors. Even worse, they often are the nastiest kind of bug. Fix one, and it breaks something else.

It finally was time to refactor the code and make it less prone to off-by-ones. We did that this week. To start, we added a Q to the name of everything that is 0-based. That didn’t solve any problems by itself, but when we fix bugs, now they stay fixed and don’t break something else. It’s more obvious what needs a 0 and what needs a 1.

The deep, deep root of the problem is that computer languages evolved. They are the result of many small short-sighted decisions, rather than a master design. Many details seemed like good ideas at the time. Then they turned out to be monsters later.

It’s kinda like what you face as a vertical human. The standard mammal body plan has four feet on the ground, so your hips and neck each had to rotate 90° to make the new posture work. Backbones were forced into a tight curve, with a painful change of loading direction. Necks rammed into where teeth used to be, pushed them together and made them crooked. For the most part the design works, but it’s buggy.

This is a roundabout way of saying that we are still working on the action commands for TurtleSoft Pro. They are more difficult than expected. We’re making progress, but it’s slower than we’d like.

Dennis Kolva
Programming Director
TurtleSoft.com

Project Billing & Payroll (Nov 10)

Our staff is gradually finishing the action commands that make accounting easier.

One of the hardest is Project Billing. Goldenseal currently has five different menu commands for it. They handle three ways to bill for projects (draw schedules, progress payments or time & materials), plus allowances and change orders.

In TurtleSoft Pro there is just one Project Billing command. After you open the window, you can switch to each type of billing. It’s easier, especially if you don’t remember how a project was set up.

A few weeks ago, we took a huge, cluttered data structure for Deposit Funds and whittled it down. For Project Billing, things went in the opposite direction. Each type of billing used its own data structure that was passed around to all sorts of places. They were similar, but each had its quirks. We merged them all into one.

Another tough one is the Write Payroll command. In fact, payroll is probably the most complicated thing in our accounting software. The window shows a list of employees, with payroll info for one pay period. That’s not hard, but looking at the details is the opposite. Depending on where you click, it will show employee hours, commissions, deductions, employer taxes, benefits, or holiday/vacation pay. There’s also a breakdown for category taxes, mostly used in states that base worker’s comp on the type of work done.

Goldenseal uses seven different breakdown windows for Write Payroll, one for each type of details. TurtleSoft Pro has just one window for everything. It fills in different table columns and different data for each type of display. The data structure didn’t change, but we had to do a lot of copy/paste to get all the code into the same place.

We aren’t yet finished with Write Payroll. Fortunately, once the interface works, it links into well-tested business logic that does not need to change. That’s also the case for the other action commands. Mostly we have to futz with the text for table cells.

Dennis Kolva
Programming Director
TurtleSoft.com

Text & Tabs (Oct 30)

Recently I set up online accounts for a new dentist, Covid/flu booster shots, and a couple other things. Most of the interfaces were terrible. For example, one date field kept saying “incorrect format”. It took several tries to find the only acceptable way to enter dates (03/09/2021). Phone numbers and passwords also were much too fussy about punctuation. Likewise, when we ship via PayPal, it complains if you enter the ounces but leave pounds blank.

Guys, it’s not that hard to program data entry fields to be tolerant. The approach we use in Goldenseal is to accept any text, then fix it into the correct format. Usually the conversion is pretty obvious. Blank pounds are zero pounds, duh.

Sometimes the code has to guess. Enter a number with two decimal points and we skip the second one. Half the time that will be wrong, but it’s still better than nagging you about it every time. Dates are the hardest. They have many ways to go wrong, but we try hard to make sense of anything that users type in. Worst case, we guess it’s today.

For TurtleSoft Pro, it didn’t take much to get the same behavior. Every field in TurtleSoft Pro is linked to an old-style Goldenseal field, which already knows how to fix text. Just one line of code, and it worked fine for the new data entry screens.

It wasn’t as easy for breakdown tables. They don’t have a link to an old-style field. This week we moved the text-fixing code so it works for table cells also.

Another convenience: if you are good at typing, then you probably like the Tab key. It’s a quick jump to the next field, with your hands still on the keyboard. The Qt framework that we use for TurtleSoft Pro “just works” for tabbing, based on the order you add fields. Sadly, it starts with the first field and goes down the list. Our code loads fields back-to-front, so their automatic tabbing goes backwards.

It was easier to rewrite tabbing from scratch, rather than reversing the order. It meant adding event filters to every type of field. They grab all mouse, keyboard and scroll wheel inputs. Eventually the event filters will do more than just listen for the tab key. For example, it’s how we can enter today’s date automatically with command-hyphen.

We also just installed a second machine that can run the current Goldenseal in the debugger. Thank you Carbon Copy Cloner for making it easy.

Dennis Kolva
Programming Director
TurtleSoft.com

Piece Work (Oct 20)

I dropped out of Cornell in 1971, bought some empty land and moved there. It was something that people did at the time. The house started out weird and cheap: plywood, fresh-cut maple poles, tar paper, pentagonal. A dirt floor to start but soon, concrete. Wood stove for heat and cooking.

From there, I gradually learned real construction. Partly from turning the shack into a saleable home, and partly from handyman work for new professors and anyone else willing to hire me. The most helpful was a cranky old ex-do-it-yourselfer, wheelchair-bound from a stroke. He talked me through all sorts of stuff, and complained about his wife and kids a lot.

Eventually, I was experienced enough to start quoting fixed-price jobs rather than hourly. First painting, then concrete slabs, then roofing, then full-scale remodeling. Working that way was riskier, but more lucrative. The rules of thumb for those estimates later became MacNail estimating software.

When you work for a fixed amount, you soon get very efficient at cranking stuff out as fast as possible. Save a few seconds here and there, and there will be more $$ at the end of the day. The same math applies to software projects also.

Our staff did the first 3 action dialogs one at a time. That kinda made sense. Reconcile is not like the others. Pay Bills was the first to have a separate window that pops up when you double-click on a line. Deposit Funds needed drastic surgery.

For the rest, it was time to treat them as piece work, and speed things up.

There are 10 or 15 steps needed to format each dialog in Qt, then link it to the existing Goldenseal code. We did step 1 for all of them. Pretty much the same stuff over and over, so it went much faster. After that, on to step 2 for every dialog. Etcetera. Most of it is just copy/paste of existing code, then rewriting what’s different. Already the work is almost half done.

There’s also a new workstation, set up with shelves and two monitors. The current Goldenseal is on the right, and TurtleSoft Pro runs the same file on the left. The process of testing and fixing has begun.

There still is much work left to do. In some areas we finished barely enough to make sure the interface was possible in Qt. Now it’s time to get all the small details working.

How long will it take to finish? It’s still too hard to estimate that. A year with Qt has given more progress than the 3 years spent with Cocoa and Objective-C. And that happened during a pandemic, with an office move in the middle. So it probably will be a matter of months, not years.

As we get further along, it will grow easier to predict a completion date.

Dennis Kolva
Programming Director
TurtleSoft.com

Deposit Funds (Oct 13)

Deposit Funds now works properly. Another task done in the big accounting software rewrite. The action commands seem to take about a week apiece. There are five left to do, so they probably will take another month to finish.

The original Deposit Funds code dates from the late 1990s. It’s complicated. Deposits can come from projects, cash sales or billed sales. Later we added rental transactions. Still later we added events (used for our training classes). Sales branches also play a part.

Deposit Funds has a big data structure that gets passed around to each of those classes. It includes a list of accounts, each with their own list of details. Afterwards, the whole mess travels to a bank transaction to actually create a deposit. The code is scattered all over the place.

Bach then, our staff figured things out as we went along. Several people worked on Deposit Funds, spread out over several years. The code ended up as a bit of a Frankenstein. Revisiting it twenty years later, it was baffling. Construction accounting software will always be complicated, but this was much worse.

On top of all that, for the first few years Goldenseal had Payment Receipts. They were intermediate transactions in between sales or project bills, and deposits. Having them made everything twice as complicated and twice as confusing. We finally removed them, and used printed forms instead. Sadly, the code still lived on inside Deposit Funds. Payment Receipts were a bad idea, and it’s time to escape them.

One way to improve software is something called refactoring. Its goal is to make code less confusing and more reliable. To refactor you first break things, then fix them. It’s kinda like doing a gut/rehab construction project, except that the gutting part has to be gradual.

Step one is to remove one bit of code that doesn’t make sense. The compiler then complains, with a list of other code that it breaks. Step two, our staff looks at each error to figure out where and how the mystery code is used. Sometimes it isn’t even needed, so we can delete it. If not, step three is to rename the data and methods to make more sense. Maybe add some comments to explain the quirks. Get the compiler happy again. Then repeat for the next bit that’s confusing.

After a few days of refactoring, the Deposit Funds data structure was about half as big, and the code explained itself. It also was more similar to Pay Bills and Reconcile. That made it easier to connect to the Qt interface.

Sometimes refactoring fixes bugs. Sometimes it adds new ones. Ditto for a major rewrite like TurtleSoft Pro. So, we still need to test everything with real-world data. That phase is coming up soon.

The best way to alpha-test TurtleSoft Pro will be to run the TurtleSoft business with it. Right now is too early to switch over completely, but we’ll run the new code in parallel with the current Goldenseal for a while, and make sure they both act the same. Or in some cases, similar but improved.

It’s ready for that kind of testing now. But the process will work best by having two monitors and two mice/keyboards side by side. To accomplish that requires serious desk de-cluttering, or maybe another desk. Still figuring that out. It may mean moving some file cabinets.

Meanwhile, our programmers have moved on to Project Billing. In Goldenseal that is split up into five different menu commands. We probably can merge them in TurtleSoft Pro.

Dennis Kolva
Programming Director
TurtleSoft.com

Resources (Oct 5)

Our accounting app has tons of C++ programming code for the business logic, data storage and human interface. However, there are places where C++ is the wrong tool for the job.

For example, it takes specialized apps to make sounds and pictures. Screen layouts are possible to build in code, but it’s much easier to design them in a drawing environment. Likewise, the text for menus, buttons and messages is better to store outside the source code. That way it’s easier to tweak them later, or translate them into other languages. All those extra details need to be attached to the software somehow.

During the first few years of Goldenseal development, I didn’t write any C++ code. It was a full-time job designing the estimating/accounting software, and creating icons, layouts, text, etc. At the time, Mac OS used an app called ResEdit to manage non-code resources. They were stored in a separate “resource fork” inside the app.

Mac users could change some details in Goldenseal with the help of ResEdit. It was a way to fix small bugs or customize features. One user translated all the Goldenseal text into Spanish with it. ResEdit died along with OS 9, but there is a free 32-bit app called Rezilla that also can modify Goldenseal resources. Use it at your own risk, and be sure to work on a copy of the app!

These days, software still has resources. Usually they are stored in many little files buried inside the app. Part of our work over the past five years has been converting old resources to new formats. A lot of them migrated into plain text files. We used XML for a while because that’s the current data fad, but simple tabbed text turned out to be easier to maintain, and faster to load.

The past few weeks our staff tackled the last few resource stragglers.

Many Goldenseal layouts have icon buttons. I drew some of them, pixel by pixel. Others were scanned in from a local artist’s ink sketches. They were “icon families” with 2 sizes and 3 color depths (1-bit, 4-bit and 8-bit). It was a relic of the early transition from black & white to color. There also were a few bigger graphics stored as PICT. Both those formats are long gone.

For Turtlesoft Pro, we converted the icons and other graphics via screen shots, cropped in Preview. They now are a couple hundred named files embedded inside the app. When we finish Custom Layouts, there will be an Icon Chooser so folks can add them to screen layouts.

The various clunk and bip and boop sounds were SND resources, also a dead format. There were how-to instructions for the conversion online. It required three different apps: one to read the raw data, one to move it to an in-between format, then a third to edit it into final form. Most survived the update, but a couple will need to be re-recorded.

Screen layouts for Reconcile, Pay Bills and other action commands were stored in yet another format. It was exclusive to CodeWarrior, the app first used to build Goldenseal. It also died twenty years ago. Our staff added code to Goldenseal so it would export layout specs into a text file. Then we edited it down to just table info: column widths, titles and other details. Now it’s much easier to maintain than the old system.

Will users be able to edit the new resources and customize Turtlesoft Pro? Maybe. There are two problems.

First of all, Qt has its own resource manager. It will be a while before we know whether it allows user access. Their final build system is very complicated, and we probably will hire a Qt expert to set it up.

Even worse, both Apple and Microsoft have increased app security. To run on newer OS versions, apps must be authorized and signed, or they won’t even run. Any user changes to the app would probably look like hacking, and be blocked as a security risk. We’ll know more about that after we start making release versions.

Meanwhile, Reconcile and Pay Bills look pretty good. We’re working on Deposit Funds now.

Dennis Kolva
Programming Director
TurtleSoft.com

Money, Progress Bars & Old Macs (Sep 22)

Our staff has gradually been getting the Reconcile and Pay Bills commands to work. It has taken us down many different rabbit holes. Working on very old parts of the accounting software code.

When we started to program Goldenseal, the C++ language was young. Things like dates, time, currency and text required long stretches of home-made code to function. They are not simple.

Take money, for example. First of all, it’s important how you store it. Computers have “float” values for decimals, but they are dangerous for money amounts. The problem is, floats can’t store cents and other fractions precisely. It’s a basic number problem. 1/100 is not an even number of binary bits, so you can only get close to it, never exact. If you ever see something like $99.999999997 or $100.0000000013 on a website, their programmers used floats for money and forgot to round them.

For Goldenseal accounting, we wrote a CMoney class that stores dollars in 32-bit integers, and pennies in 16-bits. That way it’s exact. CMoney can handle up to $4 billion, and down to 1/100th of a penny. No risk of weird rounding errors. Some day we probably will switch to 64-bit integers and extend the ranges, but it will mean a ton of rewriting and testing, for not much gain.

Money has more quirks. There are dozens of currency symbols. Some are on the left, and some on the right. The decimal point may be a period, or a comma. The thousands separator may be a comma, period, something else, or nothing. In some countries the separators aren’t every 3 digits.

Back in the early 90s, we wrote a lot of raw C++ code to handle all that. Then Apple released easier ways to localize for different countries- money, dates, other stuff. We rewrote some of the interface to use that. Then rewrote it again for Cocoa. Now we are rewriting yet again to use Qt.

Each framework does basically the same stuff, but always with quirks and gotchas. For example, Qt has built-in currency formatting, but it only accepts floats. No option for integer dollars and pennies. It probably has built-in rounding to avoid the $99.999999997 problem, but maybe it doesn’t. We’ll have to test it to find out.

It’s also time to redo progress bars. When tasks take a long time, the current Goldenseal puts up a small window with a moving bar. Sometimes it has a Stop button. Everything runs faster now, so TurtleSoft Pro will just have a small built-in progress bar at the bottom of the window. Most of the time it will just flash by, and a pop-up box would be annoying. The new method is simpler, but it means rewriting about 100 different places that show the bar.

For the actual accounting work, the new interface connects with Reconcile and Pay Bills business logic that is 20 years old. To understand how those work, we use the debugger to step through the current Goldenseal source code. 32-bit Goldenseal runs on anything pre-2019, but the Xcode project that builds it requires pre-2009.

We were down to just two older Macs able to build the app, then one of those died. It’s getting too risky. Fortunately, there is plenty of older hardware on eBay. The challenge is to set them up with MacOS Leopard. Or else figure how to update the project so it runs on Snow Leopard, which is easier to find and install.

Fun trips down memory lane…

Dennis Kolva
Programming Director
TurtleSoft.com

Bank Reconciling (Sep 3)

In our current accounting software, it takes several steps to reconcile a bank account. First, you open the window for the account or its transactions. Then you choose Reconcile from the Bank menu. It shows a modal dialog: you can’t do anything else until it’s closed. You fill in a reconcile period, then click a button to load items that haven’t yet cleared.

To get the list, the app must check every bank transaction. It may take minutes if it reads them from a hard disk. Even with an SSD it may take many seconds.

One the list is filled, you mark off items that have cleared. The screen calculates an end balance. Most likely you didn’t enter everything that’s on the statement. So, you hit the Reconcile button to save current changes. Close the dialog and add more stuff. Then repeat until the end balance matches the bank statement.

When we wrote that code in the 90s, 9″ to 13″ screens were still the norm. Not many pixels to work with. Computers had 4 to 16 megabytes of RAM: also pretty tight. We used a framework (PowerPlant) which was very limited. We did what we could, using the tools at hand.

TurtleSoft Pro is a chance to redesign the entire interface, thanks to a better framework and much better hardware. Reconciling bank statements will be a whole lot easier.

The Reconcile dialog is now non-modal. If you’re interrupted, you can do something else and come back to finish later. You can reconcile several statements at once without closing the dialog. Just switch to a different period, or hit the Bank Account popup and switch over to a different account.

We also improved the way bank accounts store their data. It makes record loading much faster.

Right now, the new Reconcile dialog is close to completion. It probably needs a couple more days work to finish off all the details.

There are a eleven more action dialogs to do, but most them are very similar. They’ll go faster. The first is always the hardest.

Once Pay Bills and Deposit Funds are working, we can start to use TurtleSoft Pro for our own accounting. At first, we’ll run it side-by-side with the current Goldenseal. It’s a good way to test the app. We can see whether both versions produce the same numbers, and act the same.

Dennis Kolva
Programming Director
TurtleSoft.com

Modern C++ and Compilers (Aug 27)

Goldenseal estimating/accounting software is built from about 1,000 text files. TurtleSoft Pro is similar in size.

To convert all that text into a final app, we use an IDE (Integrated Development Environment). First it was CodeWarrior, then Xcode, then Visual Studio, and now Qt Creator. The most important part of every IDE is the compiler. It checks for errors, then turns the C++ into machine language for the final app.

Compilers are excellent helpers. They catch most stupid typos and fatal errors. They also give warnings for code that is legal, but possibly risky or confusing. Compilers keep getting stricter, which is fine with us.

Meanwhile, the C++ language is also improving. The 2011 and 2014 updates added many features that help make code safer and faster. Unfortunately, the changes caused our code to give over 70,000 warnings: mostly for lack of the new override keyword in our pre-2011 code. It’s one of those changes that makes code a bit clearer.

The huge list of warnings slowed down compile times, and made it hard to see the ones that are most useful. We could have turned off some of the warnings, but it’s good to get them when writing new code. So we just spent a few days to update all the files. Thousands of copy-pastes. Most of the changes were benign, but we did catch a couple of potential bugs in the process.

The warning list is now down to 430 items, and shrinking gradually. Ideally we’ll get it close to zero soon. Anything that’s left will act as a to-do list.

Meanwhile, the estimating interface now looks good. Our staff has moved on to bank transactions and the Reconcile command. Reconcile, Pay Bills and other action commands are the last big and unfinished interface chunk. Once we figure out how to do those, it’ll be down to smaller details. Many, many of them.

Our staff has worked with Qt for about a year now. We’re becoming more fluent with it. Programming is fun when you can whip out a few lines of code and make something happen.

Dennis Kolva
Programming Director
TurtleSoft.com