Long before the √-button on calculators, and the now-antique slide rules and logarithm tables, people actually had to calculate square roots by hand. Like so many other pre-Computer Age tasks, square root calculation isn’t really complicated, it’s just tedious. The simplest – and, as it happens, the oldest – technique for this the Babylonian method: guess the square root of a number and then continually refine the result by taking the arithmetic mean of the result and the quotient of the number and the result, until you’re satisfied with the precision. In other words:

<script type="text/JavaScript">
  var numbr = 5, guess = 2;

  do { guess = 0.5 * (guess + numbr/guess); }
  while (confirm('Refine Further? ' + guess));
</script>

run script

There are several other methods for approximating square roots, but they all work in a similar manner: start with a seed number, run it through a formula or two, and keep going until you’re satisfied with the result. This approach is known as iterative approximation, and is not used all that often in software development. Engineers, on the other hand, tend to solve problems with physical matter and other analog things, and consequently find iterative methods invaluable.

As a structural engineer, Gabe is very familiar with the iterative methods used in his field to solve common problems such as tensile-stress variance and lateral-torsion resistance. Like the square root example, most of these calculations are simple arithmetic. The complexity, however, comes in the variables that are adjusted in each iteration, which can be anything from peak wind velocity to project cost to the metallurgic makeup of building materials.

Fortunately for Gabe’s firm, the advent of GWBASIC meant that these common problems could be solved in seconds rather than hours with simple programs that any of the engineers could hack together. By the time the 1990’s came around, the firm had developed an impressive collection of GWBASIC programs that solved many of their specific problems.

The programs didn’t change a whole lot over the next two decades. Some were upgraded to QBasic, others were created in Visual Basic 3, a handful were VB6-based, and at least one was developed in VisualBasic.NET. With lots of hacky code stored on a network drive with no version control, it was the kind of environment that would make a software developer scream W-T-F!. But for the engineers, it wasn’t all that bad. It wasn’t all that good either, which was why they were very receptive when a software vendor approached them with a “comprehensive suite of engineering tools.”

The Pitch

“Our software has become a de-facto industry standard,” the sales rep proudly declared in his presentation, “in fact, city building departments come to us for help in developing codes and standards for the computer age.”

“A few other firms have gone the same, ‘in-house tools’ route that you have,” the presenter continued, advancing to a slide with a picture of a demolished building, “but remember that engineers aren’t programmers, don’t want to be programmers, and don’t particularly like programming. When your competition uses software built by programmers and has their staff focus on engineering, they’ll leave you in the dust.”

The engineers certainly didn’t disagree. Program maintenance always took longer than it should, and the prospect of having programs that worked better and were easier to use was certainly enticing.

“And just to make decision even easier, we’re offering a free, three-day trial” he cheerfully added, winking “but I suspect you’ll make your mind up after the first day! I think it’s finally time to join 2008 and wave goodbye to your old GWBASIC programs!”

With nothing to lose, the engineers agreed to give the software a shot.

The Swing

As it turned out, Gabe was in the middle of a project that needed some serious help from software. He was tasked with figuring out what type of steel beams to use on a bridge they were designing.

It’s always a challenge to determine what steel beams should be used in a structure. Even the basics like load and torsion can be a pain to calculate. The more load that’s needed, the heavier the beam needs to be, which means the greater the load becomes, which means an heavier beam may be needed, which means it may not support the overall structure’s torsion requirements. And, with a range of only sixty or so widths of beams to choose from, switching from one size to another can change things dramatically.

Many years back, someone at the firm had written a simple GWBASIC program to help with this problem. Given an input of about twenty different variables, the program would try every beam size available, calculating and recalculating with each iteration, and eventually spit out a small list of suitable beams. The engineer would then make his choice based other considerations such as cost.

When Gabe fired up the new software, he was quite impressed with its interface. Instead of non-validating input prompts and obscure codes that the GWBASIC program utilized, the new application allowed such luxuries as tabbing between fields and dropdown boxes. Gabe spent about five minutes filling out various variables and then pressed “FIND BEAMS.”

The Miss

Instead of seeing a small number of beam types come up, the application presented him with a monstrous dropdown list of beam choices and a label that read: please select the beam that you’d like to use.

Gabe wasn’t quite sure what the program meant, so he picked W10x22 and then clicked submit. After a few seconds of a flashy “calculating” animation, the program popped-up another message: Calculation Complete! The beam you selected (W10x22) will not be suitable for the specified conditions.

After closing the pop-up, the program then returned to the main menu. Figuring that he miss-keyed something, Gabe went back into the Beam Selector screen and spent another five minutes entering data. He hit submit, was prompted to select a beam, and then told that the beam he picked didn’t work. He tried once again, only to have to-reenter data, re-select, and then learn his selection was incorrect.

“I guess I don’t really understand the problem,” the vendor said in response to Gabe’s inquiry, “the method for designing beams calls for the engineer to guess a beam size and then run it through the appropriate calculations. That’s what we’re doing, only we’ve made it much easier.”

Gabe explained that their twenty-year-old GWBASIC program didn’t require the engineer to guess different beam sizes, and that it simply output the beams that were appropriate.

“That just doesn’t make sense,” the vendor responded, “the reason you guess first is so that all of those calculations on all of the different beams don’t have to be run. Why bother calculating all that for something – like, say, a W4x10 against a 100K – when you know it’ll always fail. That’s just a waste to calculate.”

In the end, the vendor was right on one thing. Within a day, Gabe’s company made their decision: they stuck with their old, wasteful, GWBASIC programs.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!