Change Order Billing & Debugging (May 13)

A long-time user of our accounting software called in recently with a problem in their change order billing. There was a mystery retainage amount that showed up when they billed for the project.

It turned out to be a bug in the printed form. Goldenseal does not track retainage on change orders, but it’s on the printed bill layout. The amount comes from the main project: that works fine for regular project billing, but it is just confusing for change orders. The solution is to use Custom Layouts, and remove that field from the form. Here are instructions to remove it.

This bug has been around for almost 20 years. It’s only a problem for users who create change orders, and also do projects with retainage. Otherwise it just shows zero. That may be why nobody has reported it until now.

For some reason, Change Orders have always been difficult.

Our C++ source code uses object-oriented programming (OOP). Everything is an object, usually inheriting code from parent objects. Allowances, Change Orders, Sales and Rental Transactions all generate income, so they have the same parent. The problem is that some people want change orders to act like miniature projects. Those are job accounts, which have very different parents. There’s no good place to put code that both can use.

For a while, we addressed user requests by duplicating Project code into Change Orders. It became more and more difficult. We finally backed off and decided that Change Orders just need to be their own thing. If you withhold retainage on one, it’s complicated enough to be a separate project. Likewise, if you want a detailed change estimate, create an Estimate record. Those have fancier breakdowns that handle all sorts of estimating quirks. You can link the Change Order to it.

There are some deeper reasons for the bug.

Our estimating and accounting software started out as simple spreadsheets created to run Turtle Creek Carpentry. It was a small remodeling company that didn’t need much paperwork. After computerizing, we took on bigger projects that sometimes involved change orders, retainage, and other fancy stuff. But that only lasted a couple years before the software business took over from construction contracting.

Many of the features in Goldenseal come from user requests, rather than our own needs. Sometimes the programmers must guess how the code should be set up. Sometimes the guesses are wrong. Most programmers do not have in-depth knowledge of estimating, accounting or whatever. There’s a certain amount of faking involved.

We listen to tech calls and user feedback, then fix the bugs to get everything working properly in the next update. It’s something that every software company must do.

Even worse, there is a huge range of construction business types and sizes. They all have different needs. When we add new features, it’s important to not make things more confusing for the users who don’t need them. That takes some judgement and design skill. Sometimes we need to back-track or remove features that are too confusing.

Meanwhile, the past couple months I’ve been wrapped up in real estate selling and buying. It has been interesting, but it’s winding down. More details in the next post.

Dennis Kolva
Programming Director
TurtleSoft.com

File Formats (Apr 23)

Back in 1994 I made detailed blueprints for my current house: enough to get a building permit for the rehab work. Now that it’s for sale, I wanted to show the plans as a selling aid. All the construction project files were still there in an old backup, but nothing would open the drawings.

I don’t even remember which app created the plans. Maybe MacDraw II, maybe MiniCAD. Definitely nothing that runs on current Macs. There is still one laptop here from the early 2000s, but nothing on it would open the files. All the older hardware died years ago.

As developers, Turtlesoft has had a hard time keeping up with changes on the Macintosh. It’s also a problem for plain old users. When an app dies, so does all the data that it knows how to unlock.

I’ve tried out a few simple CAD programs to whip out plans, both for the current house and the probable next one. FloorDesign2 seems like the best so far. However, it uses its own file format. You can print and then save as pdf, but the details won’t transfer to any other CAD apps.

Some types of data do have universal formats. For text, there is plain text (.txt) and rich text (.rtf), which many apps can read. Spreadsheet data translates well as either tabbed text, or comma separated values (.csv). Page layouts can use either .pdf or .html. Databases often uses SQL.

In addition, some apps are so dominant that other software is forced to support their file format. Excel and MS Word are that way. QuickBooks aspires to that role, at least for add-ons. AutoCAD may do it for higher-end CAD. Unfortunately, many apps have their own unique data formats, and it’s difficult or impossible to move it elsewhere.

I don’t know if there is any good solution for this, except for keeping old computers around. They seem to last longer if used regularly.

These struggles also apply to our Goldenseal software. You can export any data to a text file and then open it in Excel. However, there’s no easy way to move all the accounting details to some other app in a single step.

The transfer problem works both ways. We wrote code to import from QuickBooks, but it can only translate some of the data from their export file. The translator brings in all the account setup details, but not purchases, bank transactions or job costing. The two formats are too different. Importing from any other accounting software would be even harder.

One issue for accounting software like ours is security. Having the file format be too accessible is not a good idea. Too much risk that data will be changed or stolen. The Goldenseal file format is not encrypted, but viewing the raw file data is not very useful. Even if someone clever had access to your computer, it would take many hours for them to figure out how to, say, find and change a paycheck amount.

If you are really worried about that risk, you can encrypt the whole hard drive, and protect everything on it. All of the fraud problems we’ve heard about from users have come from employees who could just sign on and enter stuff the usual way. Preventing that kind of fraud requires careful use of password access, and occasional audits by the owner or their accountant.

An employee who enters data should not also be reconciling bank statements. Having a second set of eyeballs on the money adds a ton of security.

Dennis Kolva
Programming Director
TurtleSoft.com

Goldenseal Pro

The bad news is that the Kickstarter did not reach its goal.  There were 23 backers and $7000 pledged.

The good news is that bids for the programming work came in lower than expected.  Two freelancers from Sweden & India respectively, have already done Carbon to Cocoa conversions, and seemed very competent from our message exchange.

So, we are now accepting pre-orders for Goldenseal Pro, and the project can probably still proceed on the original schedule.

If you have questions, please contact us by email or phone (607 220-4514).

Thanks,

Dennis Kolva
Programming Director
Turtle Creek Software

 

Goldenseal Access from Anywhere #2

These days, almost everyone carries some sort of mobile device. The big question is, how do you connect it to your business computer(s) when away from the office?

Questions 2 to 4 from yesterday are:  where is the application located?  What runs the user interface?  And, how do the devices communicate?  I’ll try to cover them all at once.  This will get pretty technical, and if you want the short answer, you might better just skip to the end!

APP DEVELOPMENT ABCs

We consumer software developers have three basic choices.  We can create desktop apps that run on Mac, Windows or Linux.  We can write mobile apps for iOS or Android.  Or we can build a web app, which runs inside a browser.

Desktop and mobile apps run code on the local machine.  Apple pushes Objective-C (and soon, Swift) as a programming language for both Macs & iOS (iPhone, iPad).  Android pushes Java.  However, C++ (the language we use for Goldenseal) is popular and very solid, and all platforms support it.  It gives excellent performance with high reliability (if you use it right!), and is probably what is used most often for “serious” software.

Web apps are probably the hottest thing to program, these days.  They need a “back end” server app running on the website hosting machine– most often written in PHP with a MySQL database, but there are many other choices.  For interface, they may also use a “front end” app that loads along with the web page html, usually written in Java or JavaScript, with many other choices.

WHERE WE ARE HEADED

I spent a few months last winter, learning new languages and considering a switch to web app development.  Unfortunately, http and web protocols were designed primarily as a page-rendering system, not for secure business use.  Many programmers are valiantly making banking & e-commerce work on the web, but it’s an  ugly process, and there are many ways to fail badly.  Languages and standards are also rapidly evolving, so code has about a 5 year lifetime before it needs a total rewrite.  Maybe web development will be mature in 10 years, but right now it’s a tough environment.

On the other hand, desktop apps are stodgy but stable.  Yes, Apple has gone through 3 OS designs, 4 basic languages, 3 hardware chips and 3 development platforms since we first prototyped Goldenseal, but that is still a much slower pace than the current WWWeb.  Our 14-year-old Goldenseal code still runs OK, and it doesn’t need a ton of work to last another 14 years.  In general, we have well-tested, stable, reliable code that would be nice to keep using.

A few Goldenseal users already have managed to connect remote laptops to their offices via a VPN (Virtual Private Network).  VPN a feature built into all modern desktop and mobile devices, which lets you use the Internet to hook into a wireless or Ethernet network.  However, it’s not very easy to set up, and we currently use a server-discovery process (broadcast UDP) that is blocked by many VPN routers.

CONCLUSION

VPN seems like the way to go, and we can rework the network code in Goldenseal Pro, to make it easier to connect.

For laptops, that would mean signing on to your office server, from anywhere that has a decent Internet connection.  It would look exactly the same as if you were in the office, with acceptable speed.

For phones and pads, we can write new mobile apps that would let you do the same thing– but it will need a much simpler interface, designed for small screens.  It may work best to have separate small apps with just one function:  enter an expense, view an estimate, enter a customer contact.  Android & iOS are really not well-suited for complex business apps.

We have been playing with designs for an on-site pocket estimator, using inteface that we first developed for BidMagic and its precursors.  Estimating will work better on pads than phones, since it is really tough to do much on a screen with only 6 square inches.

Comments appreciated!

Dennis Kolva
Programming Director
Turtle Creek Software

Goldenseal Access from Anywhere

We just received this question by email, in response to the announcement for Goldenseal Pro:

Hi this is fascinating.  But are you ever going to build something that can be web hosted? I need a solution that I can use at two locations- working on files with my business partner.   –Pierre
I think it’s fair to say that almost all of our users want something similar.  We need something similar ourselves, to run our increasingly mobile software business!  However it’s a complicated topic, and probably should be split into 4 smaller questions:

  1. Where is the data stored?
  2. Where is the application that accesses it?
  3. What runs the user interface?
  4. How do the different devices communicate?
I’ll answer #1 now, and need to think a bit, for good answers for the others.

Our current model is to store your company data on your own, local hard drive.  It’s secure, convenient, and can be automatically backed up by the OS (Mac: Time Machine, Win: Control Panel -> Backup and Restore).  You can put a copy on your laptop, and access your data even where there is no phone or Internet connection.  Files are not very big, so it’s not a burden to store them.

Quickbooks Online offers a web interface and convenient storage of your data on their servers.  That approach is great for Intuit, since they kind of hold your data hostage.  It locks you into their service, and gives them a regular monthly income pretty much forever.  We have definitely considered doing something similar.

However, quite frankly, we don’t have the balls to go that route.  It would require a lot of web programming and interface compromises, and there are many, many security issues that we surely would not get completely right.  Web security is extremely hard.  Some day, Intuit will probably have a huge hacker breach and/or loss of many people’s data, but they are big enough to survive it.  We’re too small to take on that kind of risk and responsibility.

So, we will probably stick with our current model of local data storage.  Since most users do not host a website from a local computer, we can’t get that data into an http/website stream easily.  However, we already have multi-user code to share data on a local network, and just need to improve our VPN (Virtual Private Network) interface so you can connect securely over the Internet.

That’s one of many things we can do better after we get out of our old PowerPlant/Carbon/QuickTime code, and into modern frameworks.

Dennis Kolva
Programming Director
Turtle Creek Software