Author: Dennis Kolva

We recently tested Goldenseal 4.96 with the new Mac OS version 10.13, High Sierra. It worked properly, with one possible exception.

High Sierra uses a new file system called APFS (Apple File System). It is optimized to run on SSD drives, as well as hard drives. We were concerned about how well the original Goldenseal would handle it, but the results were uncertain. The first time we used the Save As Text button to create a file, it gave an error message and did not save. That also happened a second time. After that, it worked fine, and the problem did not repeat again for any of the file-save operations.

The error message sounded like it was related to user permissions or app code signing, rather than a file system error. Unfortunately we did not write down the exact text (and then never saw it again). The error occurred with a fresh install of the OS and a freshly downloaded copy of the Goldenseal app, so it may have been related to some quirk in Apple’s code-signing system. Whatever it was, it went away on its own.

We decided to try testing with a fresh install on a different computer, with hopes of seeing the error message again, and actually writing it down. Unfortunately, High Sierra would not install on an external drive, and we didn’t want to replace the OS on the internal. People are reporting freezes and other problems with High Sierra 10.13.0, and we don’t want to get too committed to the new OS until 10.13.1 or later.

So, there may be obscure problems when the current Goldenseal app first saves files on Mac High Sierra, or there may not be. We will appreciate hearing from any users about this possible problem, whether or not it occurs.

Meanwhile, we installed the latest Mac development software (Xcode 9.0) and used it to build Goldenseal Pro. That went smoothly, and it ran fine on High Sierra after zero changes.

When we build any version of Goldenseal, we use something called an SDK (Software Development Kit). The Mac SDK includes Cocoa and other Apple code. Newer SDK versions add features, but also prevent the app from running on older OS versions. For each release we need to decide which SDK to use, since it limits the range of computers that can run the final product.

For now, we will continue to build Goldenseal Pro on slightly faster machines running OS 10.11 El Capitan. Before releasing Pro, there will be a user survey, to help make a better decision on which SDK to use.

Dennis Kolva
Programming Director
TurtleSoft.com

For each Goldenseal software update, we use a fairly standardized development flow. At the beginning, we schedule large changes and major redesigns. Those are most likely to add subtle new bugs, and it’s good to have plenty of time to catch them before users do. As work progresses, we gradually become less daring. Near the end, we only make the smallest of changes, proceeding with extreme caution.

Goldenseal Pro is by far our biggest upgrade to date, so it has been an opportunity to make very large changes to the guts of the software. Some are fixes for design choices that we later regretted. Some is refactoring, to take advantage of modern C++ and modern hardware. Some is just rewriting mediocre code so it is simpler, more reliable, better organized, and/or easier to maintain.

Last week, we merged the two classes that managed the basic data entry interface, and then split off five helper classes. It took some futzing to get everything working together, but by mid-week the code ran just like it did before. The new setup will be much easier for our staff to navigate, over the next few months.

After that, we started on the Windows interface, which was soon ready to load record data onto the screen. It then needed some real data so we could actually run the code and see something.

More than a year ago, we wrote a translator that converts existing Mac files to the new Pro format. It is mostly there so users can transfer their existing data, but it also helps us. We use a converted version of the Sample Company File for testing, which is much easier than creating temporary records. So, we ran the translator code on Windows for the first time, but it gave a zillion errors.

Goldenseal Pro uses a new database system to manage records. However, the translator still uses NeoAccess (our former database engine) to read existing data files. It is old, 1980s-style code that is the C++ equivalent to a crawl space filled with spider webs and mummified rodents. Sadly, that’s what was breaking. Our staff spent a couple days slithering around in the murk, converting obscure 32-bit code to 64-bit. Fortunately, that was all it needed, and the Windows translator now runs OK.

With the prep work finished, we can move on to interface programming. It is a lot more fun! There are frequent small triumphs and visible changes, which makes the effort seem more rewarding. The past few months have mostly been spent slogging through libraries and groundwork, so it’s a treat to switch to more tangible work.

Dennis Kolva
Programming Director
TurtleSoft.com

Goldenseal’s source code uses object-oriented programming (OOP). That means its C++ code is divided into about 600 object classes, each in separate text files. For example, CEstimate manages all the data for estimates, and CEstimateViewer handles their screen display. Those files are the first places to look, when fixing a bug in Estimates or adding a feature.

OOP is a fantastic organizational tool, akin to sorting your construction stuff into tool boxes, bags, buckets and totes. Goldenseal Pro’s source code contains over 350,000 lines of C++ code, and 150,000 lines of comments. There is no way we could ever navigate it all, without OOP.

Inside the original Goldenseal software, we had two main controller classes to run data entry windows. DB_Editor handled basic window functions, and  everything in the gray regions on the left and top. DB_RecordViewer managed everything in the big colored rectangle on the right. They worked together for loading, scrolling, editing, saving, finding, and anything else involving data records.

Last Spring we connected DB_RecordViewer to the Cocoa and MFC interfaces, and it went very smoothly. We started on DB_Editor a couple weeks ago, but it proved to be more complicated. We fought with it for a while, then decided that the editor class really isn’t needed for Goldenseal Pro. All of its functions can be handled just as easily by other classes, and its basic concept doesn’t make sense any more.

We gradually moved all the code out of DB_Editor last week, but soon discovered a deeper problem. The best place to put most of its code is in the record viewer, since they already work together to manage the data entry process. Unfortunately, DB_RecordViewer is an enormous file. It  had 275 functions, when the ideal is more like 10 or 20. If OOP classes are tool boxes, this is a van stuffed solid with equipment and construction materials. It needs less clutter, not more.

To accomplish that, we will split the record viewer class into smaller pieces. All the find/skip/replace code is now in a new DB_RecordFinder class, and we are starting on others. It’s mostly just copying and pasting code from one file to another, but we will also reorganize and modernize as we go along. The design may evolve.

This code is pretty much the heart of our software, so it’s worth taking some time to make it more understandable. Linking in the new interfaces will be much easier if they connect to a structure that is solidly built, and well prepared. Spending a week or two now can easily save us many weeks of work, later on.

Dennis Kolva
Programming Director
TurtleSoft.com

At heart, Goldenseal is a database program. It shows you screens to enter different types of company info, which it then saves to your hard drive. After that, Goldenseal helps you to use all that hard-earned data. You can look up past records, print business forms, view reports, reconcile bank statements, run special operations like Pay Bills and Write Payroll, etc.

Business data is more complicated than your usual address book database, because it is very interrelated. For example, when you enter a material purchase, it needs to link with a vendor account (for Accounts Payable), a project account (for job costing and T&M billing), and a bank account (when you pay for it, now or later). It may also link to Cost Items and Assembles, to update their prices for future estimates.

When you save a new record, we also update all the related records. That process is called posting. It happens during the “thunk” sound you hear, after a save. During posting, we first open and revise all the linked items. Then we write everything to disk at the same time, to reduce the risk they get out of sync.

Goldenseal currently posts and saves whenever you close a window, print it, or move to a different record. You also can force a save when you hit the Enter key, or choose Save Record from the Edit menu. Before the save happens, we check to make sure everything makes sense. If important data is missing, you’ll see a warning message. That prevents half-finished records that won’t post properly.

When you switch from one window to another, we don’t post or save. That way, if you are in the middle of an estimate and the phone rings, you can just leave it unfinished, and go look at something else. It can stay that way until you switch estimates, close that window, or quit/exit.

Goldenseal Pro uses a single-window interface, with each type of record in a tab, rather than a separate window. The saving and posting process is exactly the same. We probably can mark the tabs that have unfinished records.

We are currently working on the code that saves data from new or changed records. We wrote that part of Goldenseal almost 20 years ago, so half the battle is remembering how the current version does it. At the moment we are stepping through the code, simultaneously and slowly, on an old Mac, a new Mac and a Windows machine. It could easily take another week or two to fully understand the old system, so we can write new ones.

Fortunately, the existing database ‘back end’ and the posting process still work fine, and won’t need any changes.

Dennis Kolva
Programming Director
TurtleSoft.com

Our main programming season runs September to June, so it’s ramping up now. First thing on the agenda is the user interface for Windows.

Last January, we built a single-window version for Windows that we really liked. It has a ribbon at the top, an outline view on the left, and a main data entry area on the right. No menu bar at all: everything happens by clicking in the ribbon. We were very excited about the improvement. It condensed the current 200+ menu commands into a much simpler layout. Much more understandable, and easier to use.

Then we switched over to Macintosh, and spent a couple months developing a similar window layout. The first attempt was almost identical. Then we removed most of the clutter from the top, and found that it worked the same, but looked even better.

So we went back to Windows, planning to revise it to look the same as the Mac version. We spent a couple months futzing with toolbars, tear-off windows, and different styles of ribbons. Unfortunately, every attempt failed miserably. Many would crash with mystery error messages. The rest just plain didn’t work.

Software design is hard. There are many ways to fail at it, and over the years we have failed many, many times. Often in new and creative ways.  Throwing things out and starting over is a normal part of the software design process. So is giving up for a while, then coming back later. Sometimes inspiration strikes during the gap.

So, in May we decided to work on other things, and postponed the Windows ribbon problem until September.

Well, now it’s September. We still haven’t discovered how to make the Windows and Mac versions look the same, and still work well. There may be an answer lurking in some hidden nook or cranny of the MFC library, but our time is finite, and it’s time to stop looking. They will just be different.

Goldenseal Pro for Windows will have a ribbon at the top, similar to Microsoft Excel or Word. It will be easier for us to program it that way, and Windows users will already be familiar with the appearance. On Mac, Goldenseal will have a simpler, cleaner, more elegant design. That’s what Mac users expect.

The bottom 90% of the Goldenseal Pro window will look the same on both platforms. The top 10% of the window will be different, even though it does the same stuff. Windows will have tabs and labels for each of the ribbon sections, and the Mac won’t.

For most users, this is probably the ideal solution. However, anyone who switches platforms will find there are slightly different instructions for Mac vs Windows. It will be a slight nuisance for those users, and a much bigger nuisance for our tech writing staff. They will be explaining everything twice.

Now that we’ve settled on the basic appearance, it’s just a matter of getting many small things to work, one by one. At the moment, it feels as if the current Goldenseal code is a living and breathing organism, and MFC is a giant and rather clunky mechanical robot. “All” we need to do is hook up electrodes in the right places, so they can work together.

We will post screen shots and pre-release apps, once progress gets further along.

Dennis Kolva
Programming Director
TurtleSoft.com

Over the next few days, we will be switching the entire TurtleSoft website over to https. Using https instead of http means there is encryption on all Internet traffic to and from our website’s server. When the process is completed, you will probably see a green padlock next to the page link at the top of your browser. Otherwise, the change has no visible effect. 

Using encryption gives you a little bit more privacy and security. For that reason, https is gradually becoming the standard for all websites (even ones like ours, that don’t process credit card numbers or other sensitive data).

Once we make the switch, some page links may become unavailable for a short while.

Meanwhile, our main programming season has begun again, and we are currently working on the Windows interface code. More about that later.

FRIDAY 9/8 UPDATE:  All pages on turtlesoft.com now use https. Please let us know if you find any bad links.

Dennis Kolva
Programming Director
TurtleSoft.com

Every week or two, we get unsolicited phone calls from companies that migrate desktop apps to “the cloud”. It’s known as SAAS (Software as a Service). Usually they ask a lot of questions and try to sound like buyers, before revealing the real reason they called. However, still not as annoying as the almost daily “Hi, this is Heather…” scam calls.

Basically, SAAS means that the Goldenseal app will run on a server somewhere, instead of on your own computer. Your company file will also be stored on a server somewhere, and you’ll run it over the Internet. It’s pretty much like using a website.

The plus side for you is that you can access your data from any desktop or laptop computer that has an Internet connection, and you don’t even need to install Goldenseal. Up-front costs are also lower. The plus side for us is steadier cash flow, since it’s a monthly payment instead of a one-time fee. It’s why QuickBooks is aggressively moving all users to their monthly cloud-based service, and gradually abandoning their desktop apps. A monthly fee is more lucrative than forcing people into upgrades.

The minus side for you is that you can’t access your data if you don’t have an Internet connection (or stop paying the monthly fee). It’s also more expensive in the long run. The minus side for both you and us is that your data is totally dependent on someone maintaining those servers properly. One potential problem is plain old data loss, if there is an unfortunate sequence of events that kills both their main data storage, and the backups. A more subtle (and more common) problem is a data breach, where some stranger suddenly has all your company records.

We do not want to get into the server maintenance business. Even if we have incredibly smart people tending things, there are always smarter people with more time on their hands, trying to breach whatever security we have. It’s just too risky. We don’t want to be worrying all the time about losing or spilling other people’s vital data.

Likewise, we don’t want to be trusting all those small companies who are calling to offer SAAS services. It just adds one more layer of risk, since we don’t know how good they are at security. If they fail, we and our users are the ones that suffer, while they can quietly disappear.

There are a few larger companies that offer SAAS. So far we haven’t done much investigating of their services. It doesn’t make sense to do so before Goldenseal Pro is out the door. The computer industry in general has been very sloppy about data breaches, so even the biggest providers will have some risk. SAAS sounds great in theory, but it adds more failure points.

Our vision for Goldenseal Pro is to let you run your own data server. It will still depend on regular backups and decent network security. Fortunately, both Windows and Mac OS provide those features, without much effort. You really should use Time Machine (Mac) or File History and Windows Backup/Restore (Windows) for all your data, not just ours.

Despite the problems, it still may make sense for us to offer a cloud-based SAAS service, if only because it’s becoming so popular. We’d appreciate hearing opinions about it from users, and potential users.

Dennis Kolva
Programming Director
TurtleSoft.com

Many people have asked if we can put Goldenseal Pro on a smartphone. Unfortunately, the answer is a resounding “no”.  The hardware is too underpowered, the screen is too small, and the operating systems (iOS and Android) are simply not designed for building complex desktop apps.

However, what we can do is build multiple small smartphone apps that each do one thing, and “talk” with the home company file back on your desktop.

Android and Cocoa Touch (the Apple framework for mobile) both have excellent support for communicating via html. We can package our data easily into something called JSON, for sending between devices. The hard part will be getting the desktop version of Goldenseal Pro to act as a web server, so the mobile apps can connect to it via html. If that isn’t possible, we can use a VPN (virtual private network) or something else.

We already need to rewrite our current desktop networking code to run under Cocoa and MFC, and it would sure be nice if we can use the same code to connect all types of devices.  Right now Goldenseal uses TCP/IP sockets to communicate between desktops, but it’s time to consider other approaches. To test them, we’ll need at least a prototype version of a smartphone app. The best tool for that will be an app for iPhone and iPad, using the new Swift programming language. We will start with something very simple, like entering a purchase or viewing the contact log.

Prototyping is a gradual process, so we’ve started on it now, and will mosey along on it over the next year or so.  The goal will be to have it functional by the time we start work on networking, which is probably a year off. 

Networking code is very hard to write. In the past we subcontracted most of it. However, if we can use something that is built into the operating systems, we may not need to.

Dennis Kolva
Programming Director
Turtlesoft.com

For the code that runs Goldenseal, we use the C++ programming language. C++ was first developed in the early 1980s as an object-oriented extension of the C language, which was introduced itself in the early 1970s.

C is currently the second most popular programming language (behind Java). It’s often used to write operating systems (Windows, Unix, Mac OS), code libraries, and imbedded systems like the one that runs your car or truck. C++ is the third most popular language (per Wikipedia). It is better suited for large desktop apps like Goldenseal. The object-oriented features make it a teeny bit slower, but they also make it much, much easier to program big projects.

C++ was first “standardized” in 1998, with a set of “standard libraries” for handling many basic programming tasks. At that time, we were already using PowerPlant, a similar framework written in the mid-1990s. We used a few of the new C++ standard library features, but for most, we already had a decent version from PowerPlant.

Since then, C++ had a minor update in 2004, and then big upgrades in 2011 and 2014. Another is due this year. Unfortunately, we couldn’t use the many new features and improvements in the C++ language until we updated from 32-bit to 64-bit. That broke most of PowerPlant, so we started using a few of the new C++ features two years ago, to replace the old PowerPlant code.

Some programming work requires intense “focus”. Basically, the programmer needs to immerse in the entire system for days on end, and not think about much else. It’s similar to what you need when working around high-voltage electricity, or on steep roofs. But it goes on for weeks, not hours. It takes a day or two to rev up.

We left some of the interface work unfinished in May. The weather probably won’t suck enough until October, to start back on it again. Dealing with the quirks of Cocoa, MFC and Objective-C require lots and lots of focus. However, there are simpler things our staff can work on, even with summer’s distractions. Some programming is fairly routine, and can start and stop at will. It’s more like, say, painting walls or mowing grass.

We are currently going through the C++ 2014 standards, and picking out things we can use now, to improve Goldenseal Pro. There is some really nifty stuff in there.

Some of the features will help us do a better job with the networked apps. Some will help support multiple threads (e.g. use the Find command, and then do something in another window while it runs).

Many of the improvements are “safety” features, which allow code to not crash or run out of memory. We already have ways to accomplish that, but modern C++ does it better, and more concisely. Some things make the code stricter, so the compiler will point out stupid errors. Using the new C++ libraries means we will accidentally fix a few bugs, and prevent more in the future.

There are a few things we can probably change with a huge text-replace. Most will require looking at hundreds or thousands of code bits, and deciding what to change. It is all stuff than can be done gradually. We’ll work on it now, and probably will be doing it for many summers to come.

It’s invisible work, but it will make Goldenseal Pro more reliable, and easier to program and maintain.

Dennis Kolva
Programming Director
Turtlesoft.com

The cash flow for creating software is a lot like building a spec house. Income only happens when the project is finished, so the builder needs some way to finance labor and materials along the way.

TurtleSoft started out very, very easily. The first estimating template only took a month or two to write, during a slow winter spell in early 1986. Sitting at the computer was a welcome relief from swinging a hammer. Turtle Creek Carpentry made enough extra profits the rest of the year to pay for the time. In March 1987 we ran an ad in Fine Homebuilding to sell it, and the software business rocket-launched from there. You might say that the initial development costs were almost free.

As we expanded, each new MacNail module took about 1 year of programmer time. HyperEstimator took a year. BidMagic took 2 or 3. Those were good times, when a small investment in programming could create a massive amount of income. It wasn’t hard at all to finance new product development. The hardest part was dealing with exponential growth, and then, dealing with the plateau when it ended.

We wrote the first prototypes for Goldenseal in 1993, and started writing C++ code in earnest two years later. It was our first ‘real’ app, and a much bigger project than anything we had done before. The first estimates were 5 or 6 programmer-years. It eventually took almost twice that to get to version 1.0.

The first half went smoothly, with plenty of income from our older software to pay for the work. Then, in early 1997, Apple announced a $708 million-dollar quarterly loss. There was speculation the company would be swallowed by IBM or Sun, and Macintosh sales dropped almost to zero. More than half our sales were on Mac, and those disappeared.

The good times were over, and the second half of the Goldenseal programming happened on a shoestring. We couldn’t have finished it without loyal MacNail users who purchased pre-release versions (plus a lot of credit card debt).

Cash flow was tight at Turtlesoft until the release of Goldenseal for Windows in 2002. Then, for the next five years, net income became rosier than ever. Sales were better than the MacNail days, and support costs were smaller. Those were boom years for construction, and it flowed down to construction software.

However, we had learned a lesson about sudden loss of cash flow, and decided in 2005 to start a ‘backup’ business with steadier income, to offset the ups and downs of construction software. The result was SmartKnives, which sells Swiss Army knives and Leatherman tools (mostly purchased from airport auctions). It started out mostly as entertainment for the programmers, but as software sales declined post-recession, we ramped up knife sales.

Right now, SmartKnives is paying most of the bills, and funding the programming work on Goldenseal Pro. Running a second business does slow things down. However, programming work can be very draining (and fattening). There’s a lot to be said for doing it part-time. Cleaning and photographing vintage knives is a pleasant break from hours at the computer. 

Ever since the beginnings 30 years ago, our programming efforts have been very seasonal. October to April is the main programming season. We usually slack off or take a full break in the summer, and do outdoor things. Difficult problems often become so much easier after a couple months of being ignored.

As we did with the original Goldenseal, we have an option to pre-order Goldenseal Pro. It’s cheaper than the final upgrade price, and it helps prod us (and finance us) to work slightly faster. Most likely we will publicize it more (and probably raise the price) as we get closer to completion.

Dennis Kolva
Programming Director
TurtleSoft.com