What a fun welcome to work this morning! SpecsIntact was crashing every time our Specs Coordinator tried to run the submittal register for a large project we are working on. There are 115 spec sections in this volume, so it took a considerable process of elimination to see just which section(s) were the culprit. To narrow it down, she and another specifier tried running the register on the first half of the volume. No crash! So they knew the offending section(s) had to be somewhere in the second half of the book. Guess what - it crashed when running the second half - so now they worked from the other direction - adding more and more sections to the mix, until when they eventually added 26 56 00 EXTERIOR LIGHTING it crashed again. As a final test, they ran a register with all the sections EXCEPT 26 56 00. No crash!
Here's where I came in. What was causing this mysterious behavior, and how could we correct it in time to get a complete submittal register to the printing company in time, including the exterior lighting submittals? I set to work with a clean section from the UFGS master in a sandbox SpecsIntact project folder, editing only the submittals Article... interesting little discovery:
The consultant had used <SUB> tags around a whole paragraph in one of the submittals! I think there must be a character limit for a submittal description, and we were majorly exceeding it. Like Buster in the movie Groundhog Day, we were trying to make it eat the whole cow, instead of bite sized pieces! Unfortunately, there was no warning or opportunity to do the Heimlich maneuver - maybe SpecsIntact's cholesterol was a little high or something because it seemed to have suffered an immediate heart attack. Software coroners, thankfully, unlike coroners for humans, have some more chances to analyze what happened and try to get it right.
After deleting the <SUB> tags around this paragraph, touching up the reviewer designations, and reassuring SpecsIntact that it would all be ok, I ran a complete submittal register without crashing! :-)
Chris
Chris,
ReplyDeleteThank you for the great tip (and blog). I am terribly sorry for the inconvenience that this software bug caused you and anyone else who experienced it. We on the SpecsIntact team take this kind of problem (software heart attack) extremely seriously, to the point where I usually drop what I am doing when I hear about anything like this. Indeed, that is what happened today when I read your blog entry.
I am pleased to report that you won't have to call out the coroner or perform the Heimlich Maneuver for this one much longer: We have corrected this problem in SpecsIntact 4.4, which we hope to release any day now. In my testing today, I was able to reproduce the problem you describe using SpecsIntact 4.3, but not in SI 4.4. Instead of crashing with the bad submittal markup, SpecsIntact 4.4 processes the Section normally. As you might expect, the bad markup is then readily apparent from a cursory glance at our Submittal Verification Report.
SpecsIntact 4.4 will have a substantial number of enhancements and corrections, with more documented software changes than any prior SpecsIntact release but one in the past couple of decades. We have completed all work on SI 4.4, and we would normally have released it by now, but we are currently waiting for STS-128 to launch. On a Tuesday or Thursday after the Shuttle goes, we plan to release SI 4.4.
Again, we are sorry for the inconvenience this caused to you or anyone who encountered it.
Please keep those tips coming!
Regards,
Jim Whitehead
Lead SpecsIntact Developer
Jim,
ReplyDeleteThanks so much for your response, and we look forward to the new release! Being 2nd in line after the Shuttle launch is not bad :-)
Chris