Month: September 2018

Software developers have to worry about something called technical debt. It’s all the mediocre code and bad designs that happen because someone is too tired, or too rushed, or too inexperienced to do it right. The result is code that is buggy, or hard to maintain. Large projects will always have some technical debt. It’s just a matter of how much.

Construction contractors face their own versions of technical debt. It accrues when equipment isn’t maintained properly, or when stuff is not built quite to spec. Technical debt isn’t a problem right this minute, but it probably will bite you on the a** someday.

In construction, the cure for technical debt is regular equipment maintenance, plus quality control inspections to catch small problems before they snowball into disasters. In the software world, the cure is about the same: testing, training, code reviews. Because software is easy to revise, another debt-reduction tool is refactoring: rewriting old code so it makes more sense. We have been doing a lot of that since we started on Goldenseal Pro.

Tables are a fairly complicated part of Goldenseal, so they have plenty of potential debt. This week we rewrote the way they store data, so it is simpler. There is much less code now to do the same thing.

The clairvoyant fields that show lists of items are another complexity. We already rewrote the ones in data entry layouts (and renamed them to smart fields). Now we are working on the smart fields in tables. They look a little different, and have many complications. For example, the Cost Item column in an estimate breakdown needs to adjust what it shows, depending on three different columns to its left (Cost Area, Category and Subcategory). 

Goldenseal currently uses popup buttons to enter data from lists that don’t ever change. For example, any transaction involved in job costing has a Job Class popup to allocate to overhead or projects. Popup buttons require a mouse click, which can be annoying when doing data entry. For everything else you can type and hit the tab key to move on, but popups require you to use the mouse. Not great for two-handed typists.

In tables, we already use smart fields instead of popups, so it would not be hard to do the same thing for all popup buttons.  We are also working on that now.

Dennis Kolva
Programming Director
TurtleSoft.com

Tables are an important part of the Goldenseal interface. They are spreadsheet-like rectangles with a list of details, arranged into rows and columns. Many accounting transactions include breakdown tables. There are similar tables in some types of accounts, and many of the setup lists. Almost all reports use a table. So do the action commands like Pay Bills and Write Payroll.

When we started on Goldenseal back in the mid-90s, computers only had 1 to 4 megabytes of RAM. A construction estimate might have many hundreds of rows in its breakdown table. Multiply that by 18 columns, and a table could take up a significant chunk of available memory.

We built Goldenseal using the CodeWarrior compiler. It included an LTable class in its framework, to manage the rows and columns in a table. LTable was designed to be very frugal with RAM. It did not include much code to manage table appearance or behavior. As a result, Goldenseal has thousands of code lines to handle all the nitty-gritties of tables.

This week, we got far enough along on breakdown tables in the Mac update, to realize that the raw table code is due for a major overhaul.

For one thing, we now have plenty of RAM available. No need to be frugal, so we can redesign table data storage so it’s easier to understand and maintain. On the Mac, we also need to do less. NSTableView (the Cocoa table class for Mac) is already a full-fledged table maker. It handles most of the interface, so our code only needs to store data, and handle the business-specific details. More than half our existing code is unnecessary on the Mac.

We started to delete stuff, but then reverted. It seemed wise to double-check the Windows version, first. Since February our staff has only worked on the Mac version, so there were many changes to sync before we could run the Windows version again.

It turns out that Windows does not have a table class  in their MFC framework. That was surprising, since Excel was the main reason that Windows succeeded, and it is just one big table. There are some open-source table libraries out there, but when we checked them, none seemed worth adopting.

Fortunately, we already have code to draw and manage tables. For the Mac, we will bypass it, but for Windows we’ll still use it. What we can still do for both platforms is improve the basic code that manages tables.

Goldenseal uses object-oriented programming, but for some reasons our tables did not use objects for rows, columns and cells. NSTableView has them, and it makes everything much easier to understand.  Our staff is about half-way done with rehab work, to add them.

Dennis Kolva
Programming Director
TurtleSoft.com

 

In the past couple weeks, our staff has been working on bank transactions, the Find command, and breakdown tables.  No major snags. Progress has been steady. It’s mostly just a constant process of testing, finding bugs, and fixing them. Rinse, repeat.

When writing new software, you might say that the code starts out as 100% bugs. Nothing works at all. Then, it gradually shrinks down to near 0%. For a major upgrade like this one, maybe it starts at 60% bugs.

Similar to construction projects, software has its phases as the structure gradually approaches completion. Most things move in spurts, often with months between them.

For example, the current version of Goldenseal accounting software uses four different types of bank transactions to handle checkbooks, cash, loans and credit cards. We decided to combine them into one. There are currently five different layouts for checks, payments, deposits, and transfers in/out. Those will also combine into one. The change is good for the long term. There will be less code to contain bugs, and a simpler interface for users. In the short term it means extra work.

Our staff finished the database changes for bank transactions more than two years ago.

Bank transactions are unusual, because each window shows transactions for just one bank account. Everything else groups all accounts together. That means some fancy coding for the menus in Goldenseal. We’ll still keep that setup for Goldenseal Pro, since most people work with one bank account at a time. But the accounts will now show individually in the outline view instead of in pull-down menus. We finished that work more than a year ago.

Current users have data that they’ll want to keep using. That means we need to convert it to the new format for Goldenseal Pro.  It’s complicated because expenses and income transactions link to the bank transaction that paid for them, and they also need converting. We finished that last Winter.

Goldenseal currently uses a special window layout for banking, but we wanted to simplify that. We moved fields around and got the new windows working last week.

The basics now work for bank transactions, but some bugs probably still lurk. We will meet and conquer them as we finish banking reports and the Reconcile command, and start using it with our own data.

A similar spurty development process is happening for the Find command, breakdown tables, and every other aspect of Goldenseal Pro.

Dennis Kolva
Programming Director
TurtleSoft.com

 

As mentioned in the last post, we recently switched to a newer memory management system (ARC). That caused a crash after opening list windows. Switching back fixed it temporarily, but we want to use the newer system. Unfortunately, there weren’t many clues to help solve the problem.

One good approach for mystery errors is to eliminate details, and make the setup as simple as possible. We gradually removed everything from the window, but even when completely empty, it still crashed. A brand new empty window also crashed. That was good progress, actually, since it eliminated many possible culprits.

Many of the accounting screens have More Info buttons that show a smaller window that contains more fields. It uses very similar code, and it still works fine. We copied that window, but it crashed. Then we copied all the code that creates it, and it worked OK. Yesterday we changed that working version bit by bit, until it crashed. Then went back a step, and finally got lists working again. It’s not 100% clear why it was breaking, but at least we know approximately how to fix the error, if it happens again.

We use C++ for most of our programming. It’s a programming language with a reputation for being very hard. One reason for that is because the programmer needs to manage memory. It requires care and skill to avoid crashes and memory leaks.

Many newer languages are ‘easier’, thanks to built-in memory management. The Cocoa library also does that with ARC.  It sounds great in theory, to have software that manages memory for you.

I think the best analogy here is that C++ is like a regular car or truck with a stick shift. Hard to learn, but reliable once you learn it. It does what you expect. Cocoa, Java, and other modern languages are like a self-driving car. It’s way easier, and practically lets you snooze while on the road. But occasionally the system won’t see a stationary bus, and you’ll drive into it at full speed. That’s pretty much what happened, the past couple weeks.

I think we will stick with ARC, because it is working fine otherwise. Maybe we won’t hit many more stationary buses.  Or we will get good at spotting buses on the horizon.

The Cocoa library for Macintosh can be extremely frustrating, but sometimes it works like a dream. For example, Interface Preferences has a couple of popup buttons that show a lists of fonts. It took about 30 lines of code to get it working in the original Goldenseal. We did a quick search, and copy/pasted two lines of code. It now shows a standard font dialog. Cool!

Meanwhile, we are going through each data entry window, and fixing the occasional problem or missing feature. For example, bank transactions currently shows a running total on the left side of the window. Goldenseal Pro uses that space for the outline view, so it can’t go there. However, we have a bottom bar similar to Excel’s, and it’s the perfect place for that kind of text. It has been empty for quite a while, but now it shows useful text. We also added a built-in progress bar to replace the current window.

Running a construction business is complicated. Estimating and accounting are complicated. That makes Goldenseal a complicated program. There are many quirks to get working again. The good news is that most of them are easy to convert. They are close to instant gratification.

Dennis Kolva
Programming Director
TurtleSoft.com