Anatomy of a Crash (Jan 10)

Goldenseal accounting software rarely crashes, thanks to lots and lots of sanity-checking code. If something isn’t kosher, it gives an error message with the exact source code line that failed. That makes it easy for us to find and fix the bug. Then it exits to the event loop, so you can keep working.

The approach works well, but it does have a cost. Of the 26 megabytes in the Goldenseal app, almost half is just text for error messages. 99% of them will never be triggered, but it’s worth the weight to get quick fixes for the naughty 1%.

Programming the new accounting software works the same way. We rarely see crashes: just error messages and things that don’t work right. However, this week there was an actual crash. It happened after using the Link button to see the bank transaction that pays for a purchase. The dialog worked OK, but the app crashed later.

The bug turned out to be a dangling pointer in the bank transaction. We can’t test for those, so we must never let them dangle.

The accounting app has to keep track of which records are visible, so the screen will update if one is changed remotely. For example, changing payment status also changes the purchase status. In Goldenseal, each record keeps a pointer to the viewer it’s in (or null if not visible). When we post to the record, its viewer is also reloaded (if it exists).

The code is efficient, but a design flaw. A risky way to do the job. This wasn’t the first time the app has crashed there. Rather than slap on a quick fix, we decided to scrub it clean. The new app now checks every tab and window to see if the record is showing. No need for a pointer at all. It’s slower, but only by microseconds.

During the rewrite, a couple other possible bugs turned up, deep in the guts. To fix those, we need to understand the old code better. That means running current Goldenseal in the debugger, to make sure the new app does the same things at the same times. Linking records to the screen is complicated.

Setting up an old machine to run version 4.96 was a challenge. Because of the tough real estate market, TurtleSoft was in two temporary offices in 2023, plus the original and the new. Many chances for important stuff to be tucked away in a miscellaneous box. Some are still unopened.

We finally found an older Mac Mini with proper setup, plus all the wiring and converters it needs. Weather sucks, so app development is moving right along.

Dennis Kolva
Programming Director
TurtleSoft.com

Payroll Precision (Jan 1)

Thanks to readers who emailed! It’s very helpful to get feedback.

To save programmer time, updates for our payroll software will change this year. We’ll make new withholding tables only if they will be used, or if they are easy. We just uploaded the 7 US states with no income tax, plus user requests so far. Users from other states will need to contact us to get 2024 tables. Ditto for Canada. Click here for more info.

Turn-around time won’t be long for custom tables: it takes 20 to 30 minutes to fetch data, enter new numbers, double-check, and update the website. Even quicker if nothing changed this year.

Full-size annual updates for our payroll software are a real chore, and there are three reasons for it. One is just simple math: multiply that prep time by 50 US states + DC + 10 Canada provinces + 3 territories.

Secondly, every year one or two states make big changes that take hours to figure out. Maybe longer. Some tax departments invent amazingly bad ways to calculate withholding. Utah is so weird, it takes a special spreadsheet to convert their numbers. Connecticut added so many tables that we had to skip some of them.

Finally, many states are precise when they should just aim to be accurate.

An example of too much precision: California withholds exactly $115,488.06 per year for a single person making $1 million. Round it to $115,500, and nobody will even notice on their pay stub. Withholding is just an estimate of next year’s payment, anyhow. Our staff must type in and double-check hundreds of numbers each year. Futzing with pennies per million makes it harder. More chance of error by us, tax agencies and users.

Flat taxes are often pushed as a simpler tax system, and every year another state or two switch to them. They are precise and easy: same tax rate for everyone. Problem is, they increase inequality. It’s mostly because of marginal utility. Take 10% of income from a poor person, and they need to give up food, clothing, shelter or health care. Take 10% from a rich person and they can only buy 9 Picassos instead of 10.

Some people who make tax policy and tax tables don’t seem to understand math very well. Seems like a good topic for a future post.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

 

Obsession, Invention & State Payroll (Dec 18)

In the previous post I blamed some big rocks for slow progress on our new accounting software. But I think the problem is deeper.

Programming requires intense focus. In fact, it works best with more than that. Every new product we’ve made took a spell of total obsession. TurtleSoft’s history has a few of those, interspersed with low-focus coasting.

The first batch of software obsession was a couple months in Winter 1986. It built spreadsheets and macros for estimating and accounting. The second was five years, 1988 to 1993, as TurtleSoft grew exponentially. Then another five, 1997 to 2002, to finish and polish Goldenseal.

More recently, it took a year of obsession circa 2015 to update to 64 bit and rewrite the database engine. Only shorter spurts since then. Most creative binges were interrupted by something: noisy neighbors, Covid, moving, need for other work to pay bills. A few years of effort were wasted on platforms that didn’t work out.

In between the creative bursts, small stuff still gets done. But most energy goes to other interests. One can only stay focused on one thing for so long. Obsession is draining, and not healthy. Sitting for many hours at a computer add 2 or 3 pounds of body fat per month.

Software is not the only thing that requires obsession. It applies to anything big and new. I just watched The Wind Rises, a Studio Ghibli film about aircraft design. In it, Count Caproni says you only get ten years in the sun, for that level of creativity. Hayao Miyazaki may speak from his own experience.

The new accounting app is close to completion, but it’s hard to find motivation to work on it. My ten years are up. Work is getting done, but it’s moving very slowly. The rocks, yard and house are too enticing.

I don’t know how many people still use the current Goldenseal. Most of our users started in the 1980s to 00s, and probably retired by now. Construction has similar creative burn-out issues (plus Carpal Tunnel Syndrome and back pain).

There’s a bit of a turning point for TurtleSoft, right now. It’s almost time to make payroll tax tables for 51 US states/DC, plus 13 provinces and territories in Canada. Skipping it this year is an effective way to count the surviving Goldenseal user base (at least for the payroll software). If nobody squeaks, a tedious week will be avoided. Something else can get accomplished instead.

I don’t know how many people read this blog. Usually that doesn’t matter, since I enjoy writing it. It’s a good way to gain clarity. Maybe Google likes it, and sends searches our way. However, hearing from readers who still want the new accounting/estimating software will be useful. An aid to motivation. Send a hello to support@turtlesoft.com.

Since 2015, the project has been a long, long slog with zero financial reward. It will finish just out of sheer inertia and guilt, but completion will be quicker if there’s a better reason in sight.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

Rocks (Dec 7)

Progress on our new accounting software is still going slowly. It’s mostly because of large rocks.

Our new office has a triple-size lot at the urban edge of suburbia. It’s on a slope which was bulldozed into flat sections, with steeper bits in between. Those were covered with black plastic and small stones, held by rock walls at the bottom. 25 years of frost expansion and gravity caused the stones to slide down, collapsing the walls. In places, the soil itself shifted. The steepest bank is 7 feet vertical and only 7 feet horizontal. That’s challenging, even in glacial till.

Repairs must be done before spring, to get it ready for plantings that will hold the slopes better. So, until there’s snow or frozen ground, this is the most urgent project.

I’ve done plenty of stone work over the years, but never with such big rocks. Some wiggle an inch at a time, with leverage from a long pry bar. One moved faster thanks to a come-along tied to an upslope tree. Too bad there aren’t more of those.

I’m sure the stones were originally set with heavy equipment, but this project is too small to be worth the rental/delivery/pickup cost. Anyhow it’s a good way to lose weight.

The damaged walls are about 80% done. Weather will get worse soon enough, so there will be more reason to sit at the computer and build software.

Dennis Kolva
Programming Director
TurtleSoft.com

Complexity (Nov 30)

Our accounting/estimating software is complex. There are all sorts of weird details that it must deal with: project dimensions, retainage, material returns, subcontractor insurance, plus a thousand other business quirks.

Fortunately, once we write code for those things, it stays put. No need to rewrite them as computers evolve.

Sometimes there are bugs: usually because we forgot to handle some specific situation. Those are easy fixes. It’s usually just a few lines of new code, with little risk that it will break something else.

Sadly, to make our accounting work, we need a GUI framework (Graphic User Interface) to handle mouse/keyboard inputs and screen display. The app also needs an OS (Operating System) to manage the GUI, memory, and hardware. Plus an IDE (Integrated Develop Environment) to compile and link our code into something you can download and use.

All those are way more complex. Our software is made up of about 2,000 files: source code, images, layout resources. The Qt GUI framework and IDE have about 400,000 files. For Mac, Qt uses Xcode with another 500,000 files.  There’s no easy way to count the OS code bases from Apple and Microsoft, but they must be in the millions. Probably tens of millions. Maybe even hundred millions.

I’ve ranted about this before, but modern computers and internet have become too complex. TurtleSoft is built like a comfy little house made of C++ text, but it sits atop a deep bed of quicksand. Apple and other huge companies make their living by adding pilings, posts, chains and matting to it, but the whole mess still is intrinsically unstable. There are too many layers of old code. Nobody understands more than a small slice of it.

Our staff ran into that fragility this week when we updated to the newest version of Qt. It gave a mystery error message when trying to build the new accounting app: “No rule to make target. Stop.”

We fiddled with things, to no avail. Posted to the Qt list. Tried various suggestions from other developers: some gave different error messages, but none worked. Finally we heard from someone else with the exact same problem. They fixed it with an update to the latest Xcode. We already did that, but a new version of Apple’s command-line tools solved it for us.

Desktop development is complex, but website development is even worse. It has just as many layers, but worse code in all of them.

Dennis Kolva
Programming Director
TurtleSoft.com

Software Progress (Nov 22)

Our staff is finally back at work on the new accounting software. The move to our new location took longer than expected: mostly because the weather stayed nice. It was too tempting to work outside, thank you climate change. This property is almost a half acre, and it was very overgrown. Now there’s less to do come Spring.

The first task is to fix about 20 small bugs that turned up from testing over the past few years. For example, one happens if you enter a purchase refund, then void the deposit, then change the amount on both, then un-void the deposit. It handles the money OK and it marks the purchase as Paid, but it shows the wrong payment method. Regular purchases work OK so we just need to put the same code into voided/unvoided refunds.

We’re tackling bugs first because the programming is in familiar code. It’s a good way to get back in the groove after a two-month absence. So much evaporates in that much time. Especially during the stress of house-hunting, closing and moving.

During the gap, I realized that the end results will be very hard to market. The project has taken far too long. It will be like trying to sell a ghost.

We are finishing the new software because we need it for our own bookkeeping, and because some users already paid for it long ago. But that doesn’t even come close to paying for the many programmer-hours we’ve invested over the past six years. It’s not obvious how to recoup that, let along become profitable again.

I think we will have a free beta version, then keep it free for a while. When there are folks using it and happy, then we can figure how to make money from the app. There are many possible options.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

Desks (Oct 28)

Everything is now moved into our new location. Desks and file cabinets are in their long-term homes. It’ll take a few more days to unpack boxes, then TurtleSoft will be back in business. Progress reports on our new accounting software will be coming soon.

I personally work at two desks, and often swivel between them. On top are four monitors and about 10 desktop machines: two Windows and the rest Mac Minis. Some of it is because of old software that needs older machines. It’s the only way to run Adobe apps on the desktop. Some is so we can test the new software in any recent OS. The setup also makes it easy to do something else during downloads, compiles or other lengthy operations.

When it came time to start restocking desk drawers, I realized something. At least 90% of the stuff sat there untouched since the last move. It’s currently in boxes with labels linked to a spreadsheet, and they might as well stay there. Maybe all the clutter on top of the desks can go into the empty slots, now. That makes room for new and improved clutter!

Dennis Kolva
Programming Director
TurtleSoft.com

 

Programming Seasons (Oct 9)

Our first estimating/accounting software began in Winter 1985/6, during a slow spell with only a couple indoor construction projects lined up. It finally seemed time to computerize and make the business more professional.

The original plan was MS/DOS and Lotus 1-2-3, but the Mac Plus changed that. It just seemed a better business machine, especially thanks to Microsoft Excel. With printer, hard drive and software, the whole package cost over $20K in current dollars. Luckily, the investment paid for itself within a year or two.

TurtleSoft started to sell home-grown Excel templates in 1987. By ’89, more money came in from software sales than from construction work. From then on, we were a real software company, focused on developing apps for accounting and other business needs.

Except, well, sometimes we weren’t. Programming is creative work. It doesn’t fit well into a 40 hr/52 week routine. Our staff took plenty of breaks for spring planting, travel, fall harvest, etc. Productivity was best during the gray winter months. Almost as good during sweltering summers. Often neglected in between.

Right now is one of those seasonal breaks. Still moving stuff into the new house and organizing the new office. It should taper off by the end of October.

Dennis Kolva
Programming Director
TurtleSoft.com

Undo & CAD (Sept 25)

Undo support is a real PITA for programmers: it makes everything 2 or 3 times harder. Luckily, we don’t need it for many things in our accounting software.

Undo is most useful while you edit text, but the OS and frameworks already handle that for us. We just inherit from QTextEdit or QLineEdit, and it works. Popups and other data entry fields are easy to change, so they have little need for undo. Worst case, you can Revert Record and go back to the last saved version.

Custom Layouts is the only place that needs lots of Undo code. It’s a drawing environment that lets users change the appearance of data entry screens, printed forms and reports. While tweaking layouts, you’ll often want to reverse small changes.

Programming Undo often requires sneaky tricks. For example, when you delete something, it just becomes invisible. Undo the delete and it appears again. The actual deletion happens later.

Goldenseal has single Undo. You can reverse the most recent action, but that’s it. The new accounting app is a bit better, with multiple Undo. You can go back step by step and undo each action since the last Save.

To figure out how much to undo, our staff has been checking other graphics apps. It’s good timing, since we just closed on a new house last week. We need to make floor plans for future rehabs, and to help decide on office layout before lugging desks and file cabinets.

When Turtle Creek Carpentry first computerized, MacDraft was the best app for blueprints, even though it crashed frequently. Eventually MacDraw improved enough to be a more reliable replacement. That worked great for a decade or so.

Sadly, most of Apple’s apps did not survive the switch to OS X. We still have all sorts of handy data that can only be seen on antique machines running OS 9.

These days, we have yet to find a decent, simple CAD app to replace MacDraw. Some apps are awkward. Some lack important features. Some are way too complicated. So far, LibreOffice Draw and FloorDesign2 seem the best of the lot, but neither is as functional as stuff from 25 years ago. Many innovations from the early Macintosh just faded away.

When it’s finished, Custom Layouts will have about 1/3 of the code needed to recreate MacDraw Pro. It will be very tempting to spin off a simple CAD app, some day. However, we do have more important things to work on right now.

Dennis Kolva
Programming Director
TurtleSoft.com

Colors (Sep 15)

Our new estimating/accounting software still had one unfinished data entry field: a color picker. It’s only used in Cost Categories, for Estimate breakdowns. Colors make it easier to see which items belong to each project phase.

Getting the picker to work was easy: just a few lines of code. Tidying up the source code for colors took longer. Some parts are as cluttered as an attic or garage. Kinda like a 30-year time machine, showing the evolution of PCs.

Goldenseal began when most personal computers used 1-bit monitors. Back then, there simply wasn’t enough memory for more than one bit per pixel. Black & white for Macs, various pairs for MS/DOS.

As RAM increased, colors crept onto the scene. The earliest used just 3 bits: six colors plus black and white. Later, Macs upgraded to 4-bit colors: twice as many choices. There was pink! Light blue! More than just Roy G. Bv. Later, 6-bit and 8-bit became common, expanding the gamut even further.

All those were indexed colors. Each pixel chose from a palette of 8, 16, 64 or 256 shades. For anything in between, you dithered two colors in a pattern. OK when viewed from a distance, but pixelated in close view.

By the time Goldenseal shipped, nobody used less than 8-bit colors (256 choices). Our code supported five different bit depths, but ignored four of them. The system palette was too garish, so we made a custom version that was mostly light tints (for backgrounds) and dark shades (for text).  Data entry backgrounds used 24-bit true colors to get more pastels.

Twenty years later, RAM is cheap. Nearly everyone uses 32-bit colors. Rather than a palette, those have 8 bits apiece for red, green, blue and alpha (transparancy). That’s 16 million shades, good enough for most uses. It’s what we use everywhere in the new accounting app.

Apple goes deluxe, with 64-bit colors in their Cocoa framework. The extra depth is a slight improvement for high-quality photo editing, but overkill otherwise. Few users will notice the difference.

Sadly, for a few years we used Cocoa for the new accounting app. Some of our color code is still 64-bit. Switching between the two sizes sometimes causes bugs, but at least they are obvious and easy to fix. If Qt ever enhances their color setup, we’ll be ready.

For business forms and data entry screens, the old 8-bit palette was perfectly fine. Colors aren’t any better in the new system. In fact, the pickers are more complicated now. Too many choices. However, we updated to full color despite that, because it’s easier. Our staff has better things to work on than a retro popup of 256 color squares, made from scratch.

Dennis Kolva
Programming Director
TurtleSoft.com