In engineering, optimization can be your worst enemy

There are three aphorisms concerning optimization that everyone should know. More computing sins are comitted in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.                                                                                                                                                                                - William A. Wulf We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.                                                                                                                                                                       - Donald E. Knuth   We follow two rules in the matter of optimization:      Rule 1. Don't do it      Rule 2. (for experts only).  Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.                                                                                                                                                                        -M. A. Jackson I always felt it was best that I did not turn into a full fledged programmer as a career path.  Because even to this day, its very hard to be "done" with a program.  There are always ways to make it better, refactor code into less lines, make an iteration run faster, or even just come up with a more clever way of solving a problem.  In most cases, these "improvements" are not ever necessary, they lead to nothing actually working better in the eyes of the client, they serve as nothing more than self satisfaction. Although Wulf, Knuth and Jackson were speaking in the context of Computer Programming, their advice can be applied across almost any discipline.  Can you imagine a surgeon working on you trying to come up with a faster or more clever way of removing your diseased gall bladder?  Yeah, probably not a good idea. Taking the path of optimization can certainly lead to an over engineered solution.  One that is both overly complex, difficult to troubleshoot, difficult for others to work on, and as Wulf points out, often does not actually lead to any sort of optimization.  I think this happens a lot in technology, optimizations take hold and drive projects to areas they perhaps should not go, often to their detriment.  I recall a customer that once had me lay out their VLAN structure based on the operating system of the servers.  So there was say VLAN100 Linux, VLAN110 Windows, VLAN120 HP-UX, etc.  They thought this to be very logical and actually took things even a step further, attempting to correlate octets of IP addressing back to the VLAN.  Unhappy to accept that VLANs like IP addresses are arbitrary labels.  It does not mean we can't do cool things to make efficient logical use of them, but don't try to turn them into something they are not - they are NOT operating system labels. The natural design process should instead look very high level at a problem.  Each entity within the system should be assigned its basic behaviors that it needs to do.  Abstract drawings and designs should be made to show the intercommunication of these objects.  This is done many times in programming using things like UML, or in network design using high level Visio diagrams.  To Jackson's point, if you try to optimize to early, you are simply building constraints into the system which may ultimately lead to a less ideal solution.  It is best to wait until you have a fully baked unoptimized solution. The main point is that as engineers, we can be our own worst enemy.  We are taught to improve things, to make them better, faster, and more innovative.  You always have to come back to the true task at hand, what is the core problem and are you doing something that is solving that problem?  Don't allow yourself to get hung up on optimization.