Coding Philosophy

I found a good chunk of potent wisdom on Bruce Eckel's website:

• It seems I have to struggle with a problem for awhile before "the simplest thing" begins to occur to me. It's also helpful to study solutions that other people have developed, to see what works and what doesn't. Perhaps there is a maxim "you can't be both simplest and first." Corrolaries would be "don't make it so perfect you can never deliver it," "worse is better," "stop after the first 90% (because the last 10% will take the other 90% of the time)," or simply "just solve the core problem." I guess that's the thing, though: knowing what the core problem is can be the major part of your struggle (This is certainly the case with design patterns). Elegance is inversely proportional to sweat. Because elegance is difficult and time to market is crucial, many have come to believe that the former should be sacrificed for the latter. It's hard to argue against this. The rabbits that rush a half-working piece of garbage to market are usually the ones that are wildly successful, whereas the careful tortoises are never noticed. Of course, this is a description of an industry that is fueled with startups and innovation, rather than a mature industry. You're probably not going to make a dent in the world of tires or tv dinners without a lot of up-front research and investment. Perhaps there are businesses other than software with enough wildcards that it's possible to get a brainstorm and suddenly create a breakthrough product with very little investment, but I can't think of any. My belief is still that "Elegance always pays off." The payoff comes after the initial flush of market success, when you are improving the product and making it more complex. The architecture and implementation techniques will then either spur you on to more greatness, or sink you. But it seems rare for a company to become successful with a bad design and implementation, and then stop and refactor the whole thing rather than rushing to add more features. So from the acorn grows the oak. What is the balance between simplicity and expedience? "Do the simplest thing that could possibly work" is certainly not saying "do the most elegant thing" because the goal is to get something working, without too much effort, so that you can try it out and see if it solves any portion of the problem. "Trying it out" is what will produce the valuable information that can be fed back into the next iteration, and will also begin to tell you what's most important about the problem.