Functionality Over Elegance

I'm reading Where Wizards Stay Up Late which is a book about the people that invented the internet.  It's the story of ARPA and BBN and the creation of essentially the first computer network.  I ran across an interesting quote from one of the programmers of the first networking gear (the IMP).  Dave Walden said, "There was an infinity of ways we could go wrong, and a substantials number of ways to go right.  Good engineers find one of the ways of going right."  He was pointing out the difference between a computer scientist and a computer engineer.  The scientist looks for the ultimate way of doing things.  The one that trumps all others.  The engineer just looks for a way.*

This isn't to say that all ways are equal.  There are tradeoffs that must be made and their consequences considered.  However, given a time budget, reliability requirements, and performance metrics, a number of solutions often make the grade.  A scientist might continue to investigate which one is best whereas an engineer picks one and moves on. 

The author says it this way:  "At its core, all engineering comes down to making tradeoffs between the perfect and the workable."  He makes the point that when you are trying to ship a product, functionality trumps beauty and elegance. 

As I stated in my essay on the subject of design, sometimes you just need to go with a solution.  It is the job of those of us in the trenches to find a solution and make it work.  It is all too easy to continue to pursue the better in the face of the adequate.  More often than not, doing so leads to overdesign and missed deadlines.  The place where this bites most engineers is in the desire to rewrite.  How often have you heard someone say "This whole module needs to be rewritten."?  Sometimes it really does but more often it comes from a sense of aesthetics.  The code isn't written the way we would have done it or it isn't written as optimally as possible. 

As software engineers, we must remember that the ultimate goal is the shipping of a product.  We must make decisions with that goal in mind.  When faced with the temptation to rewrite a whole section of code, we must resist.  If a simple patch will solve the problem, go with the patch.  The product will thank you.

 

* The use of engineer and scientist here is my choice, not necessarily Walden's.