Month: February 2018

At Turtle Creek Carpentry, our first construction estimates were based on simple rules of thumb. E.g. for house painting in the mid-1970s, we figured $100 per side (labor only), $10 per window or door, and scratch-your-head extra for wide eaves, porches, and anything else unusual. That kind of math was reasonably accurate, quick to calculate, and easy to remember. It worked well enough for estimating simple construction projects like painting, roofing, storm windows, and the like.

Unfortunately, rules of thumb didn’t scale up so well for larger, more complex projects. Those required much more time and math. Bids took days or even weeks to prepare.

When Turtle Creek computerized in 1986, the first task was to set up construction estimating templates. It took a few months to assemble rules of thumbs and actual calculations into a spreadsheet. When it was done, the results were amazing. Bids took 1/5 the time to prepare, and they were much more accurate. It probably worked so well because construction work is tangible and repeatable. That makes it relatively easy to turn construction details into data and formulas.

Unfortunately, many other project types are not so tangible, or not so repeatable. For those, it is much harder to calculate time or cost in advance.

For example, in 2011 the SpaceX Falcon Heavy was first predicted to launch in late 2013. It actually flew in early 2018. Completely-new stuff is just plain harder to estimate. We face the same uncertainty when trying to estimate  our own software projects. It’s also an issue when we try to expand our estimating approach to industries other than construction.

Since we evolved from rules of thumb to serious math in our construction estimates, maybe it’s worth following the same path for less tangible estimating. For “fuzzy” projects, there do exist some “fuzzy” rules of thumb.

On the pessimistic side, one rule is “it always costs twice as much/ takes twice as long as you expect”.  Or even more pessimistically, you can add “even when you figure it will take twice as long as you expect”.  That rule certainly applies to my bold prediction on Jan 11 that we could start using a beta version to run TurtleSoft in “a month or possibly two”.  Doubling that seems much more reasonable.  Quadrupling it?  Probably not, but it’s certainly possible.

For software, a similar rule of thumb is the 90/90 rule. It goes “the first 90% of the project takes 90% of the time.  The last 10% of the project takes the other 90% of the time.” This definitely applies to the layout view. After 2 weeks work, it’s now doing most of what a simple drawing program needs. It looks pretty far along, but there are many small details that will easily take another 2 or 3 more weeks. The original estimate was a month for the Mac version, and so far that looks accurate.

On the optimistic side, sometimes projects go faster at the end. It certainly applies to jigsaw puzzles, Sudoku, and computer sorting algorithms. To some extent, it also applies to software projects like Goldenseal Pro. Our work started out very slowly, because of the ‘learning curve’ for new languages and libraries. Productivity has increased dramatically since then, and will keep increasing as we near the end.

There are also sound mathematical reasons to plod at the beginning, and rush at the end. You can use the same math as for project financing. Interest cost = amount * duration * rate. The more spending you can delay to the end, the shorter the duration, and the cheaper it is.

Similar logic applies to risk and the ‘opportunity cost’ of labor. Procrastination pays off, if applied correctly. For just that reason, our staff will be increasingly motivated, as we get closer to finishing. When the end is in sight, it’s easier to put in extra hours.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

Our staff is making progress on tables, and also starting work on the layout view. It replaces the Custom Layouts command that sets up data entry screens, printed forms and reports in the current version of Goldenseal accounting software.  The layout view is essentially a drawing program. It has a tool palette, and graphic objects that you can click on and drag to new locations. We use it to set up most of the appearance in our estimating and accounting software. It also allows users to change things.

Apple has sample code for a simple drawing app, which makes our life easier. But not that much easier, since the sample was written in 1998, and its code is very outdated. It’s a helpful start, but we end up rewriting most of it.

The Objective-C language that Apple uses for Cocoa is even older.  Both Objective-C and C++ evolved in the early ’80s as enhancements to the venerable C language (origins mid ’70s). However, C++ has been updated frequently since then, while Objective-C has lagged. Almost nobody uses it except for Apple.

The little boxes that you drag around in the layout view are a perfect example of how difficult it is to migrate a large app like ours from C++ to Cocoa. In our existing code, each box is a C++ object. The object responds to mouse clicks, updates the screen display, and stores its new position when you stop dragging it. When you save, it writes changes to the database. The code is not trivial, but it’s all in one place. For the new Windows version, we can still use the current code with only minor changes.

The 64-bit Mac version still needs that C++ object to read and write data. It also needs a “linker” object (written in a hybrid language called Objective-C++). The linker connects with an Objective-C object which knows how layouts work, and that in turn contains a Cocoa control object that responds to mouse clicks and draws on the screen. Four classes instead of one. To make things work, we either have to pass messages back and forth through 3 layers, or write it from scratch in Cocoa.

This is a general problem that all software developers must face. Objective-C is not bad for small apps, but for a large app like ours it would be horrendous. Objective-C is creaky and cranky and decrepit. Then, the end result would be code that only runs on Apple hardware. It would require a complete rewrite for Windows, with two code bases to manage. Mixing C++ and Objective-C is possible, but challenging. We are doing that now, but it pretty much added a year to the development time for Goldenseal Pro.

Most big companies like Microsoft and Adobe only converted their Mac apps to Cocoa in the past few years. That’s very slow, considering that Mac OS X and Cocoa first appeared in 2001. Apple’s apps are written almost entirely in Cocoa, but they’ve had the benefit of adding Cocoa classes that specifically suit their own needs. Apple pretty much programmed their apps with a lot of C language code, and just a little Objective-C.

The new Swift language may some day make Mac programming easier, but it’s still immature. It also does not connect with C++ at all. Developers either need to write in pure Swift, or have two linkers (one from C++ to Objective-C, then another from Objective-C to Swift). It’s doable, but not fun.

Even more worrying, the usage rate for both Apple languages has been dropping, rather than expanding. Swift’s percentage in the TIOBE index declined from 2.1% to 1.8% over the past year, while Obj-C fell from 1.5% to 1.1%. That compares to 15% for Java, 11.9% for C, and 5.7% for C++. Programmers really don’t like either Apple language. Meanwhile, C and C++ are growing.

This coming Fall, the newest Mac OS 10.14 will start to give a warning when you run older 32-bit apps written with the C++ Carbon library. In the Fall 2019 release, Mac OS 10.15 will not run them at all. That change will affect the current Goldenseal software, but not Goldenseal Pro. Right now it’s looking pretty good for getting the Pro update out before this September.

Many good apps disappeared during the conversion from OS 9 to OS X in the early 2000s, and many more vanished after the conversion from PPC to Intel in the late 2000s. Most likely, in a couple years there will be similar carnage.

We actually find this bad news to be rather cheering.  TurtleSoft has already outlasted many competitors, and having to slog through (metaphorical) knee-deep mud means a few more will be left behind. Already, QuickBooks for Mac desktop is officially doomed after May 2019. It will be interesting to see if AccountEdge (currently 32-bit) can make the switch. They may be surprised at how hard it is. Chances are good that there will be a lot more room for other accounting programs such as ours.

We keep that in mind, every time that Cocoa programming goes #%@⊗!# or %!$♣~#(øΣ or &U+1F4A9;.  Fortunately, we are still ascending the learning curve, and it keeps getting easier.

Dennis Kolva
Programming Director
TurtleSoft.com

.

You probably have had one of those days when you go to the garage to fetch a screwdriver, but the light is burned out. So you head to the kitchen for a new bulb, but they’re all gone. So you drive to the store to pick up more, but while you are there, you accidentally lock the keys inside your vehicle. You try to pry the door open with a credit card, but what you really need is a screwdriver.

Anyhow, it has felt that way with the tables in our new accounting software. They are a major part of the interface, showing rows and columns of info much like a spreadsheet.

Back in December, breakdown tables were just starting to display in a cute pop-out drawer on the side. It filled in the correct columns, but needed an overhaul to the layouts before proceeding further.  Before doing that, it made sense to get all of the mode-switching to work for everything, not just layouts. That led to still further rabbit holes.

After 7 weeks of digressions, we are now back in the garage (metaphorically speaking) to fetch a screwdriver for Goldenseal Pro.

Since tables are present in all 6 basic modes, it makes sense to do them all at the same time. Print and report tables are easiest.  They are now filling in data, and looking pretty good. We’re currently working on the small tables found in lists, and some accounts. Then we’ll futz with layouts, then finish off the breakdown tables found in estimates, material purchases, and other business transactions.  Last and most difficult are the ‘action’ tables in Reconcile, Pay Bills and similar commands. The current app has an entirely different way to create them. Getting it to be more similar to the other tables has always been on the to-do list. That will happen soon.  It will make setup easier for us, and will allow users to modify them (slightly).

In an attempt to get a completion estimate for Goldenseal Pro, we looked at the draw schedules in the programming contracts from a couple years ago. Unfortunately, those were based on which menu commands worked. The actual project is proceeding more ‘horizontally’ than ‘vertically’. The current work on tables is spread out in 3 different project phases. It’s a lot like the difference between a ‘room by room’ estimate, and an estimate based on categories of work. They both get to the same place, but it’s hard to compare them.

About half the work we have done so far has been on major improvements to the basic interface. Those don’t show on the draw schedules at all.

The original plan was to start with a duplicate of the existing app (because easier to spec it that way for subcontractors). Once we had a working version, we would have made improvements in later updates. However, now that our staff is programming the whole project, it’s far more efficient to design and build a better interface, right from the beginning.  Doing it that way is slower to get to the first release, but faster to get to a really good version.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Our estimating software has its roots in an Excel spreadsheet started in Winter ’86. It was just a list of construction items and prices, with formulas to do math on them.  The first unit costs were the “rules of thumb” that we already used for our construction estimates.

The spreadsheet improved gradually, as we duplicated it for each new job. Its first big test was a $100K remodeling project in a log house that summer (about $250K today). There were many complications, so the estimate ran to 200+ line items. The work was so unusual that nobody else bid on it. Our price was significantly over their planning budget, but we got it anyhow.

It was the biggest project ever, for Turtle Creek Carpentry. We were nervous about the size, so we built another new spreadsheet to track expenses. It later grew into our current accounting software.

Real-time job costing was a roller-coaster. For the new log garage, the estimate had a *12/5 formula to convert square feet of wall to lineal feet of log. Unfortunately, it was zapped by a later copy/paste, so expenses were suddenly $4,000 higher than expected. Then, oops, interior paneling was listed twice. That put it back close to estimate.  Other errors turned up, but in the end, final costs matched the estimate within 2%.

The lessons learned from that job still apply to our current construction estimating software.

1). it’s possible to get surprisingly good accuracy, even when the data is imperfect. The trick is to split the project into small pieces, and calculate each separately. The small errors will nearly always cancel out. It’s important to avoid systematic errors (everything wrong in the same direction). However, that is much easier than getting everything perfect.

2). Having a detailed breakdown of every item is impressive. Later on, we won bids even as high bidder, just because the list was so complete. Detailed printouts are an excellent marketing tool. In those days, it wasn’t hard to look better than everyone else. Now, it’s almost a requirement.

3). Matching actual expenses to the estimate really helps improve accuracy. The better you track job costs, the more accurate your estimates become.

4). It’s important to group things. That first big estimate had a huge list of items with no subdivisions. It was overwhelming, and hard to see errors. We overlooked the doubly-listed paneling. So did the architect, and the client. Seeing subtotals for different categories is a good ‘sanity check’ that we added to later estimates. As a bonus, it’s much easier to track job costing by category, rather than by item. Then you don’t need to ask where every 2×4 went.

5). Don’t rely on hidden math. As the spreadsheets and software evolved, we gradually found ways to make the cost calculations more visible and obvious. It’s an ongoing process that we still are improving.

We seem to be thinking more about estimating basics lately, as work progresses on Goldenseal Pro. Some of that is because the rewrite stirs up ideas for how to improve the software. Some is because we still aren’t very good at estimating the time it takes for our programming work. Ideally, it would sure be nice to calculate in advance, exactly how long each new product or upgrade will take.

Anyhow, 4 of the 6 basic modes in Goldenseal Pro are now functioning moderately well, and the 5th is getting there. Still many small details to finish, but it’s progressing at a steady pace.

Dennis Kolva
Programming Director
TurtleSoft.com

We just added color lookup tables to Goldenseal Pro (the coming update to our accounting and estimating software). They are the last of the resources that needed updating.

Color lookup tables (aka CLUTs) are pretty much a vestige of 1990s computing. To save space, 8-bit colors were common back then. To choose an 8-bit color, you select from a palette of 256 choices, rather than click on a full 32-bit color wheel. 

In the current version of Goldenseal accounting software, we use an 8-bit color palette for text and graphics in data entry layouts, printed forms and reports.  The system CLUT is mostly bright colors, so we replaced it with a custom version that includes more pastels (for field backgrounds) and dark colors (for text and borders).

32-bit color is close to the limits for human vision, and it’s worth having for photographs and videos. However it’s overkill for tiny color blobs like text and field borders. For those, 8-bit is perfectly fine. For example, Microsoft Excel shows a limited palette of colors for text and cell backgrounds. It’s easier to use than the full color wheel.

However, these days it is easier to program the standard color-choosers, rather than write custom code to show a palette. Goldenseal Pro still needs to support 8-bit colors so existing layouts read in correctly, but we will convert them to 32-bit colors when saved in the new format. It does mean you’ll have more choices for colors, especially if you want bright ones.

As for resources, they are a design feature that was first made common in the early Macintosh. Resources store program data that can be changed without any coding. It means that programmers (or users) can switch text to a different language, change field details, or add keyboard shortcuts to menus, without needing to rebuild the source code.

Mac OS 9 and earlier used a program called ResEdit to modify resources. It let users “hack” app resources, so they could change certain details of their software. We also used resources to set up most of the interface for Goldenseal.

Unfortunately, there is no equivalent resource editor for Windows, nor for current Mac OS. To update resources in the current version of Goldenseal, we actually have to go back and run Mac OS 9 on ancient hardware.

Goldenseal Pro uses modern Cocoa and MFC resources. That means they are user-accessible again, in both Mac and Windows version. Users or developers can translate the text to a different language, fiddle with colors, or tweak a small detail for a data field. Most of the resources are simple text files, but some use XML (eXtended Markup Language, similar to the HTML language used for websites).

It takes some effort to change resources, but that is how it should be. We don’t want it to be too easy for inexperienced users to accidentally mangle something important within the software.

The update to Goldenseal Pro is a long slog, but it does bring significant improvements. Better colors and resources are just a small part of that.

Dennis Kolva
Programming Director
TurtleSoft.com