Smart fields are a big part of our estimating/accounting software. They let you choose from a list of customers, suppliers or whatever. Breakdown tables are also important. They show details for estimates, purchases or sales. Both of them are complicated, especially when there’s a smart field inside a table.
Most complex of all? The Item column. It is bonkers, especially in estimate breakdowns. The cell may show a smart field to choose something: a list of materials, labor, construction assemblies, subcontractor bids, etc. Or, it may just let you type in some text: for a random material, a percentage adjustment, or a comment. Each option has different impacts on the rest of the table.
Last week, our staff got into an infinite loop while fixing a problem in Item cells. Sometimes they were empty, but every time we fixed it for one case, it broke for something else. That’s a sign that code is just too danged complicated. Time for a better design.
Each row in a breakdown table is stored as a breakdown object inside the database. To fill the table row, we loop through the columns, fetch a chunk of text from the object, and pop it into the cell. The process works great for most things, but some cells need to know more than just their text.
The current Goldenseal code gets the extra info from other columns in the row. We have to be careful about their order, since we fill from left to right. It may also mean converting text back to numbers. One of those probably caused all the problems.
While trying to rewrite it, our staff had a d’oh moment. Why not just get everything all at once from the object? That would make it a one step process, instead of two.
We whipped up some trial code to make a one-step transfer for the Item column. It worked great. The new approach is simpler. It will be easier to maintain.
For now, the new system only applies to the one column. However, if anything else misbehaves, it can get the same fix. Some day we may rewrite everything with the new code.
In programming, there’s something called “technical debt”. It’s all the hacks, bugs, and bad design decisions that staff made years ago. It’s code that works, but it ain’t great. It’s the door framing without headers, the joist that the plumber cut to a ribbon, the gap that got a dab of caulk.
Sometimes TurtleSoft has the chance to fix technical debt. This was one of them. The code base will never be perfect, but at least it can improve with time.
Dennis Kolva
Programming Director
TurtleSoft.com
