Miscellaneous Musings from the Technical Director
Primum non nocere. “First, do no harm.”
This phrase is a basic principle of the medical profession. The practitioner is reminded to carefully consider if the application of their craft might do more harm than good.
I wish that university professors and administrators would keep this phrase in mind when deciding on how to implement commercial software in the academic setting. The software must never be a barrier to learning, and I fear that it too often is just that. (I had much the same opinion about programming curriculum in engineering education a couple of years ago.)
Just because a commercial developer makes software available free or at low cost to schools does not necessarily mean that a school should adopt it. Just because a developer creates nicely packaged workbooks does not make for a successful academic experience. What is absolutely fabulous in a commercial setting may not be suitable at all for education. There is no guarantee that the skills spent in learning one flavor of software in college will be applicable in their employment. (Much the same can be said for freeware. Simply because it is free does not necessarily make it any more appropriate for students.)
In my opinion – and I am certain there are many who would disagree – the first criteria for “academic-friendly” software is not accessibility, but a “zero learning curve”. The first criterion must be: “Can a student do real productive work to learn the principles and concepts of the software in an appropriately small amount of time?”
Any time spent in learning a software’s unique interface and processes is wasted. It does nothing to promote learning. I would rather see student use a tool with 50% of the features, but also with 50% of the learning curve and tech support.
Now, some might think that I am being a bit hypocritical. After all, HydroComp sells discounted academic “lab kits” of our software to schools. True. Unlike CAD software, however, the functional processes of NavCad, SwiftCraft, even PropCad, are really very easy. You have a reasonably linear process of data entry, definition of analysis parameters, running the analysis, and displaying reports. Once through the tutorial, a user will have learned the “screens, fields, and clicks”.
The new-user challenge – and the learning – comes not from figuring out how to use the software, but in the hydrodynamic principles that are supported by the software. The educational value is not in knowing how to select a CF line and enter a form factor, for example, but in learning what these things actually do and their implications in the expansion of a drag curve to full scale. We also provide extensive technical development of the methodology in our User’s Guides. (I know of at least one school that is using our NavCad User’s Guide as curriculum reading for their resistance and propulsion classes.) In addition, schools can start with our more fundamental tool, SwiftCraft, and then proceed onto NavCad when the projects – and the students – become more sophisticated in their relationship to applied hydrodynamics. As you might guess, I am very sensitive to new-user learning and we try as best we can to make the tools have as close to a “zero learning curve” as possible.
So, how do we as educators, commercial software developers, and prospective employers respond to this? I believe that “academic-specific” software is the high-value solution (from the student’s perspective), although wise implementation of commercial software is the easy path (from the school’s perspective).
Does spending time developing a unique skill set within a particular brand of commercial software make students better engineers, or even make them more marketable? I would submit that the answer is “no”. On the other hand, would using that time in a simpler setting to learn the common themes across commercial software achieve this end? A slam-dunk “yes”.
“First, do no harm.”
“Second, provide the tools that will help make them the best engineers they can be.”
I would particularly love to hear from anyone teaching introductory naval architecture or boat design. What do you think? Do you agree? Am I completely off-base? (Wouldn’t be the first time…)
Filed under: Engineering, Software
