I love developing software.
I tell everybody that this profession is the new artistic frontier; with the software developer being the creative successor to the cave painter, Michelangelo, Picasso, and so forth. Anything we can imagine, we can create – and with the tools available today, we can create quickly. On a typical day I might wake up with new inspiration — some amazing new graphic trick, some slick tweak to the UI, or a game-changing feature; have it incorporated into CloudCalc by noon; show it off to – and get some wows from — a couple of lay people (who have no idea what engineers actually do); run it through some testing; and then release it to the world in time to knock off work around mid-to-late evening.
Sometimes the process may take a little bit more thought and work, especially if it requires solving a knotty problem that I (or maybe anybody else in the world) have not solved before. But in my mind software development always provides the quickest possible route from creative inspiration to realization. And inspiration is of paramount importance in software design – the creativity of the app, the flow of the UI, the elegance of the architecture, the efficiency of the algorithm is what determines if the product goes viral or stagnates or dies.
But in the end, to be successful, the software has to work. What that actually means depends on the particular app. For an app like YO (www.justyo.co), all that means is it has to be able to send the one-word message “Yo” to somebody. For an app like CloudCalc, it means that each of those thousands and thousands of little numbers that it spits out have to be exactly what they are supposed to be. If the numbers are wrong, then the software is not only without value, but worse, potentially dangerous. So therein comes the less fun, but more necessary, part of the software development process – the validation.
For a structural engineering program like CloudCalc, the validation process first had to ensure that the program was calculating the correct displacements, forces, moments, and reactions and secondly was using those forces, moments, etc. correctly in the code compliance equations. That meant painstakingly checking every type of loading (there are seven of them, for you non-engineers in the audience) in various combinations, acting on eight different types of steel section, each with various permutations of compactness, non-compactness, or slenderness.
Most of this validation was done against contents of the AISC’s book of Design Examples (which shows engineers how to solve each of these different types of calculation). But even with this 900-page crib sheet in hand, it meant thousands and thousands of individual calculations, done the old fashioned way — manually. The occasionally-detected error required making a change to the software – to be sure a welcome break from the validation chore – but sometimes also meant having to go back and re-validate to make sure that the fix didn’t break anything else.
Very few suspect the iceberg of validation beneath the tip of the software, nor the drudgery involved. If creating software is like being Michelangelo, the validation process is like the 16 years Michelangelo spent lying on his back looking up at the ceiling of the Sistine Chapel. This part of the software development cycle can definitely make any Picasso feel like a paint-by-number hack.
But once finished, we “artists” are still proud of our drudge work, since that drudge work is what ultimately gives value to the software. So CloudCalc is releasing the documentation produced during its validation process. Get your copy of Part 1, covering AISC Design Example C-1.A (addressing structural stability and second-order effects), from the CloudCalc Support Forum, accessible once you have logged into www.cloudcalc.com. Subsequent releases will be coming soon, and will be announced here.