Goldenseal Pro Progress Report- Printing (Mar 27)

Tables are far enough along that we are now working on the remaining parts of the interface for Goldenseal Pro. The short-term goal is to finish enough to start using it for our own business.  Using ‘beta’ software is painful at times, but it’s the quickest way to test our new estimating and accounting software.

For big projects, we usually work on the hardest parts first, since they need the most time to learn, build and debug. Printing is the next most difficult task after tables, so we read Apple’s printing guide last Friday. Turns out that it only requires one line of code. We added it, clicked the Print button, and whoosh, a printed form came out! Here’s the code in all its glory:

[[NSPrintOperation printOperationWithView:[currentPrintController view]] runOperation];

The brackets mean it’s Objective-C, and the NS prefix is short for NextStep, first developed for Steve Job’s Next computer in the 1990s.

The current/old version of Goldenseal has hundreds of lines of C++ code for printing. It deals with margins, landscape vs portrait, different paper sizes, and many other trivial details. We spent months getting it to work right. When Apple updated to OS X, it took another month to update the printing, which still isn’t perfect. That printing code is so complex that every bug fix just broke something else.

In the previous post I complained about how complex NSTableView is, but NSPrintOperation and NSPrintInfo sure do it right. There’s setOrientation for landscape/portrait, and setTopMargin for the top margin, etc. It even does pagination, which saves 100+ lines of code right there.

Both of the project estimates for Goldenseal Pro figured a month apiece for printing on Mac and Windows. At least on the Mac, it will take much less time than that. Estimates that go under budget are always very pleasant!

One thing different in Goldenseal Pro is that we show a Print Preview window right at the beginning. That way you know exactly what you’re getting, before you print a form. As a bonus, the new interface helps us to debug the appearance without printing reams of paper. We couldn’t do it that way in the original Goldenseal, simply because processors were too slow back then. The several-second delay would have been too annoying.  Now, it’s just milliseconds.

Dennis Kolva
Programming Director


Goldenseal Pro Progress Report- Tables (Mar 22)

Accounting software helps tame the complex parts of running a business. Putting data into rows and columns is a good way to accomplish that, so our software uses spreadsheet-like tables almost everywhere.

When we first wrote Goldenseal in the mid to late 1990s, we had to build the table interface completely from scratch. There is code that fills in text, draws lines between cells, handles clicks and double-clicks, and deals with all the other little details. Altogether, it took about 2 programmer-years to write all the C++ code that runs Goldenseal’s tables.

Those handmade tables have not aged very well. Despite a few appearance updates, they still look “old”. On Windows, they flicker and flash. Even worse, it’s complicated code that is hard to maintain.

For Goldenseal Pro on Macintosh, we use Apple’s Cocoa library, which already contains a complete table system (NSTableView and helpers). That’s good news, and bad news.

The good news is that Cocoa table views handle most of the nitty-gritty details for drawing and behavior. It only takes a few lines of code to get a functioning table. Even better, when future OS updates change the interface appearance, the built-in tables will update too. 5 years from now, the tables in Goldenseal Pro for Mac won’t look like the spreadsheet equivalent of bell-bottom jeans.

The bad news is that Apple built Cocoa mostly to support their own apps, and they rarely make it easy for other programmers to understand and use. It’s kinda like buying something from Ikea, but without step-by-step instructions. Instead, there’s just a nice picture of the end product, and a list of parts. Where and how to use them? You need to figure that out on your own.

Usually there are sample apps, from Apple and others. Often they are outdated, but it still helps to see a working example. Stack Overflow usually has answers for specific error messages or problems. Still, getting Cocoa tables to work has required much trial-and-error.

Despite the obstacles, we’re making decent progress on the tables for the Macintosh version of Goldenseal Pro. Last week, they started showing columns and titles. This week they are filling in data, and giving a data entry field when you click on a cell. They look and act like tables now.  Still some formatting and other details to finish, but it’s moving ahead at a decent pace.

The MFC library for Windows does not include a table class. That has the same good news/bad news as Cocoa, only reversed.  Other people have put a few projects online that may work. We’re looking at them now. Also, we already have working table code, and maybe it just needs some updating.

Dennis Kolva
Programming Director


32-Bit vs 64-Bit (Mar 15)

The current version of Goldenseal is a 32-bit app. Goldenseal Pro is 64-bit. You might wonder why that makes a difference. So, let’s look closer at computer bits, and how they affect our accounting and estimating software.

First of all, a bit is just a yes/no choice. It’s the smallest possible unit of data. Numerically, a bit is usually considered a 1 or 0. Physically, it may be a tiny magnetic spot, or a tiny laser-etched dot, or a tiny transistor’s state.

Computers have gradually increased the number of bits they can handle. Early PCs used 16-bit addressing for RAM, which meant a limit of 64K (65,536 bytes).  Early Macs increased that to 24-bit (16 megabyte limit). In the 1990s, PCs switched to 32-bit addressing, with a 4 gigabyte limit. In the 2010s they’ve moved to 64-bit, with a theoretical limit of 16 billion gigabytes (=16  million terabytes =16,000 petabytes =16 exabytes).

Our accounting software is not likely to ever need more RAM than the 32-bit limit. Likewise, file sizes will also stay comfortably below 4 gigabytes. However, there are other reasons why 32-bit apps will become obsolete, relatively soon.

On the Macintosh, that impending obsolescence is obvious. Starting in Fall 2019, Mac OS will only run 64-bit apps. Apple has not updated its Carbon library to 64-bit, and does not plan to. That means all software must switch to Cocoa, which requires either Objective-C or Swift as a programming language.

As we have painfully discovered, converting from Carbon to Cocoa is not trivial. Existing C++ code can connect to Objective-C, but it’s a pain. Replacing old interface code is an even bigger pain. The Goldenseal Pro update is less work than the original programming for Goldenseal, but far more than any previous upgrade.

On Windows, the situation is less dire, because Microsoft takes great pains to support older software. However, 32-bit apps are already starting to be cranky, on newer versions of Windows. They often require special installations of older libraries and DLLs, and they may not be compatible with newer printers or other hardware. Running 32-bit apps is already a nuisance, and it will only get worse.

Updating our own programming code from 32-bit to 64-bit was not difficult. Memory addresses changed from 4 bytes to 8 bytes, but it’s rare for code to care about their length. There were other small changes to make, but nothing overwhelming. That prep work only took a few weeks.

Unfortunately, that’s not all that is required to get from 32-bit to 64-bit. Problem is, it’s not practical to write everything needed for a full-sized app, so we rely on libraries written by other people to handle “the basics”. Some are system libraries from Apple or Microsoft, some are open-source, and some are third-party code. Many of those libraries don’t work in a 64-bit world, and will never be updated by their authors.

We faced that situation with the NeoAccess code that runs Goldenseal’s database. It was so old and so badly written that a rewrite would have been a soul-sucking task. Replacing their code completely was faster, and less frustrating. It was a half-year project, but at least the new code will be more reliable, and easier to maintain.

We also had to toss most of the PowerPlant library, and a few smaller 32-bit libraries from the 1990s and 2000s. This massive conversion is something that every software company will have to deal with, if they want to stay viable.

Of course, there are many gains that come from the upgrade. For example, PowerPlant (and the original Macintosh) drew on a 16-bit “canvas”. As a result, reports with more than 1,500 lines were too long to display on the screen (though it was still possible to save them as text, and open in Excel). We tried to rewrite that code to 32-bit, but never got far. By going “native” with the screen drawing, Goldenseal Pro gets a huge canvas for free. It also gets better looking graphics, support for UniCode text, and many other improvements.

Dennis Kolva
Programming Director

Estimating Categories & Comparisons (Mar 8)

Any estimating software needs to divide projects into smaller pieces. It helps mathematically: if you split the estimate into many smaller calculations, the errors will usually cancel out. It also helps prevent errors: when we did construction estimates by hand, it was very easy to forget a few things. Categorizing also specifies the project in detail: clients know exactly what they are getting, and the building crew know what they’re building. As a bonus, a good category system integrates estimates with accounting software, so you can compare ‘estimated vs actual’ costs in a useful way.

Most construction projects can be sliced in at least two different ways. You can divide by categories of work: foundations, framing, roofing, trim and so on. Or you can divide physically by rooms, units, buildings, stories or whatever. There probably are other ways to slice up a construction project, but those are the most common.

For our own programming projects, it has been a challenge finding ways to categorize the work, for both estimating and job costing.

When we first started to program Goldenseal in the mid-1990s, project management consisted of a print-out of all the menus, with ‘completion bars’ drawn in atop each command. It was a nice, tangible way to see progress, but it also made the work seem like it was moving faster than it was. About 80% of the commands were easy, and each took only a few hours to complete. Some commands like Estimates and Print Forms took months. A couple (Write Payroll and Custom Layouts) took almost a year each. The chart looked like 90% done, when it was more like 50%. I guess that’s proof of the 90/90 rule. You can make the same mistake on a room-by-room construction estimate, if you count the kitchen and bath the same as other rooms.

A few years ago, we listed the Goldenseal Pro update on eLance, UpWork and Over 100 subcontractors gave price quotes. Most just guessed or tried to talk us into T&M, but some sent detailed bids. Since we are still exploring the best category system for our own projects, it was interesting to dig them up and see how other programmers divided the work.

Several had a few broad, chronological phases. For example, one had 25% (prepaid) for ‘team selection’, 25% for ‘evaluate code’, 25% for ‘alpha version’ and 25% for ‘bug fixes’.  Basically, they wanted half prepaid before even starting. A few counted windows or menu commands, similar to our first method. The rest sliced the project into 10 to 25 categories, similar to our approach last year.

Looking at other people’s cost estimates is also useful. It’s similar to ‘comparison estimating’, where you start with a similar project and then calculate the differences. It’s a good approach if you know the total cost of past jobs, but don’t have enough detailed job cost data to calculate unit costs.

About 2/3 of the bidders planned to use QT, a popular library that builds code for both Mac and Windows.  Those estimates ranged from 40 to 150 programmer-days, or from $7,000 to $60,000 in cost.

We hired one of those in early 2015. The project started well, but ground to a halt after a few months. Then we discovered the contractor had used many shortcuts to get to the first draw payment, and we probably shouldn’t have paid for that. At least we learned that QT was the wrong tool for the job. The code was just too ugly.

About 1/3 of the bidders planned to convert Goldenseal the way we are doing it now: on the Mac, from Carbon to Cocoa; on Windows, from QuickTime to MFC; on both platforms, from 32-bit to 64-bit. Very few of those were willing to give a firm price, and none gave a detailed breakdown.  We hired two contractors who gave up almost immediately, and one who worked part-time for a few months before “getting stuck”. At that point, our staff had finished the back-end work, so we just started the interface code in-house.

Looking back through the list of bids, it’s clear that almost nobody understood how difficult the work would be. At the time, we assumed that tons of other software apps would already have made a similar conversion: meaning that there would be scads of subcontractors experienced at it. Reality is, those 64-bit updates never happened. Most business apps are still 32-bit, up to and including the big boys like QuickBooks and Sage.

Meanwhile, work proceeds on tables. Our estimate says they’ll take 2 months, but we aren’t far enough along yet to know how accurate that is.

Dennis Kolva
Programming Director

Goldenseal Completion Estimate (Mar 1)

Last June, we made a quick spreadsheet to estimate completion time for Goldenseal Pro. The math predicted completion in late May or June 2018, but it was very uncertain. Since we write construction estimating software, you’d think we could make highly accurate estimates for our own programming projects.  Unfortunately, that has never happened. Software is less predictable than construction, and harder to specify.

Work on Goldenseal Pro has progressed enough that it’s a good time to recalculate a completion date.  Unfortunately, updating last year’s spreadsheet did not go very well. Its category breakdowns just don’t line up with the actual work we’ve done. That estimate sliced things vertically, but progress has been more horizontal instead.

The calculation method we used was also inferior. It started with a guess of total work needed for each category, and a guess at the percent completed so far. Then, a formula to calculate work remaining. The problem is, multiply two guesses, and it just makes an even worse guess.

For what it’s worth, we did the best we could with that spreadsheet, and it calculated 7.9 months until completion. Probably plus or minus a few months.

Now that we are further along, the calculation will be more accurate if it starts with the time spent to date, then extrapolates from there. We just looked at source control comments, to get a general idea of how much time has been spent on each area, so far.

The MVC (model-view-controller) system is a reasonable way to slice the new code in Goldenseal Pro, horizontally.

At the bottom, the model layer includes business logic, database code, and basic stuff that connects to memory and the OS. Half of the model layer is the business logic that runs our estimating and accounting software: that does not need to change at all. It’s about the only thing that doesn’t. During 2015 and 2016 we did an extensive ‘gut rehab’, and replaced all of the other half (including a complete database rewrite).  The model layer is pretty much finished now, but it probably still needs a few days, here and there.

At the top, the view layer handles what you see on the screen, and what happens when you click a mouse or type on the keyboard. For Goldenseal Pro, we need to replace 100% of that code on Mac, and about 75% on Windows. About 1/3 of the view layer programming is for basic windowing, and ‘mode shifting’ between data entry, find commands, layouts, printing and reports. That portion is mostly finished on Mac, and half-done on Windows. Another 1/3 is buttons, fields, and other small interface. Most of it works now, but there are many small details still unfinished. This portion is probably at 50%.  The final 1/3 is tables and other complexities, which we are only just starting.

In the middle, the controller layer coordinates the model and view, and also links between C++ and Objective-C. It applies almost exclusively to the Mac version. The MFC library for Windows does not use MVC, possibly because the acronyms might interact and explode. Generally, the controller layer just makes life more complicated at every turn. It’s hard to itemize the effort it takes, but it’s a good place to throw in 2 or 3 months for forgotten complications and unexpected cruft.

Before using math on programming work to date, we really need to adjust for the learning curve. Productivity was close to zero when we started using Cocoa and MFC, and it ramped up from there.  Smooshing the first 6 months into 2 productive months seems about right.

Throwing all that into a spreadsheet says 7.3 months to first release. It’s several months later than last year’s estimate: October instead of June. No surprise, given the many uncertainties, and the extra work we’ve added since then.

The estimate will grow more accurate, as we move further along.

Dennis Kolva
Programming Director