Paul Price

Premature optimization is a topic that most software developers have heard about, but I've recently been thinking about how applicable it is to other disciplines.  I'm not going to try and explain the connection to your line of work - as a practitioner in your own field you are best suited to do that yourself.  I'll just toss a few words at you to get you thinking about it.

A long time ago (in computer industry years) Donald Knuth warned that "premature optimization is the root of all evil".  Software optimization is the process of modifying a software system to make some aspect of it work more efficiently or use fewer resources.  Some lazy programmers use this statement as their maxim to justify writing slow, resource hogging code that never gets improved until someone else does it for them (usually after they have moved on to another project or company).  They entirely missed (or ignored) the point.

Optimization itself is not evil - doing it too early is what gets us in trouble.  If you haven't yet proven the relevance, usefulness, correctness or marketability of your application - you should be developing it in prototype mode until those things have been confirmed.  Most people would be surprised at how much code gets tossed out or at least heavily refactored as a product matures.  The first iteration is always a prototype, wether you are willing to admit that or not.  If your software team isn't tossing out code then I guaruntee that you have a lot of nasty legacy code and your product is evolving about as slowly as a fossil.

I used to work for a guy that was so hung up on performance and memory optimization that he was willing to sacrifice correctness and maintainability in order to eek out a couple more milliseconds and bytes of savings.  I don't think he conciously decided that those extra tidbits were worth messing up one thousandth of a penny in a treasury bond pricing model (which is a big deal when your talking about many large transactions).  He was just so focused on performance that everything else (correctness, maintainability, time to market) became secondary.  He was too proud of his code's performance to see the obvious flaws.
Franchise Marketing - Channel marketing software - Local internet Marketing
This principle is magnified at a startup.  You don't have the time, human resources or capital to try and perfect a product or feature that has never been tested in the market.  You have to learn to identify "good enough (for now)".  You have to get it in front of real users who really use it - or at least figure out why they refuse to us it.  For example, our print ad builder has been through countless iterations.  The first version wasn't too pretty, fast, or even very well thought through.  The fact that it kicks the tail of every other local marketing platform out there is because we were willing to admit that we wouldn't get it right the first time.  We have relentlessly refactored and modified it.

Think about how this principle applies to you and feel free to shoot me some comments (especially if you disagree with me on any of my points).