Comparing Form/Function to Program/Algorithm

In product design, striking a balance between form and function is constant struggle.   I ascribe to the philosophy that when faced with a design decision, it is better to given precedence to function over the form.  I say that not just because it’s better for something to work well vice looking good, but rather by keeping function front and center you keep your mind open to possibilities.  When you become “married” to particular implementation or design you tend to unconsciously cutoff other designs that could meet the functional requirements in a more effective/efficient manner.

This can be extrapolated to other facets of modern life including business processes and software engineering.  In some ways, software designers are some of the most adept and separating form and function.  I draw a parallel of form and function to programs and algorithms in the software world.  In the world of software, an algorithm is simply a recipe or set of instruction to complete computational task.  There are many different types of algorithms within each family of algorithms.  For example there are a family of algorithms are geared towards sorting data, these include bubble sort, merge sort, and quicksort to name just a few.  At the end of the day though, they each sort.  But a good software designer knows that each has their own pros and cons in terms of memory and execution time to complete.  So when they go about writing a particular piece of software they taken into account the data structures before deciding to which sorting algorithm (or any other algorithm for that matter) to implement in code.  In short, they put the algorithm (function) first in their mind before building the program (form).