I appreciate the thought behind this post and I wish this mantra could be applied in every situation but I don't think we should all now "Just code to get it out there". It is sound advice for developing the login screen functionality on your website, but when it comes to larger backend systems, a flawed or unoptimised initial design can't just be optimised when it is discovered it isn't working as required. The cost correcting a flawed design, post delivery, could cripple a business. Even in the case where the product is functioning as required, if OOP principles were not applied in initial design, enhancements to that product would most likely be much more difficult to implement. So, as with most things in life, consider the consequences before taking action.
The situation depends also on the team. I've been on teams with sloppy programmers and efficient programmers. What I've learned personally is that efficient programmers who plan things out and focus on best practice tend to keep their code very DRY and understandable for others to catch onto. The sloppy programmers end up having to race to the deadline in order to refactor and sometimes redo their code because the end result was close but not correct enough for passing to a client. While I like the idea of saying "f-it" let me program I love thinking about efficient problem solving, it actually makes me continue to think and IMHO makes me a better programmer.
I have worked on projects which are developed against stupid deadlines where getting the code out is all that matters. These projects are always doomed to maintenance overheads and cost.<p>I agree with the comments below that state code the simplest solution to make your tests pass but learn the best approach to tackle given problems so they are second nature.<p>My experience has shown me that learning various principles and pattens results in smaller code bases that make maintenance and refactoring easy. In turn you are able to deliver quicker.<p>That being said, its not always so easy to achieve with established code bases.
<a href="http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast" rel="nofollow">http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast</a> is wisdom that all software engineers should adopt and internalize.
I agree with the basic idea behind this post. But most of the worrying over architecture and paradigms should be done at the preliminary design stage, which should happen before you even think about coding.<p>It doesn't have to be a polished, detailed, or even good design, but it does need to be something that you can at LEAST loosely stick to initially and have faith in. If the design is flawed enough that coding progress is halted, stop coding and revisit your design.
I think this principle is best applied in personal projects where you are not even sure if your idea will catch on. But for client projects with buckets and deadlines this is a terrible idea. In my experience clients only decide what they want after they see what you have done based on what you asked for. At this point if you are rewriting entire modules then you did not design and plan properly.
How did we get to the point that code became writ, too holy to change?<p>Throw some paint on the canvas. Make it <i>do</i> something, good, bad, or ugly. Then, pay attention to what works under the covers. What's hard to change, what's risky, what your team loves to work with.<p>But, remember and <i>apply</i> those things -- they are some of the best whetstones for a developer's skill.
Actually you need to stop earlier, I've found that quite a bit of the stuff that people think they need to have built isn't even close to needed in reality. In fact, building it and shipping it can be a major mistake itself.<p>So I completely agree on the underlying principle:
Dont to _anything_ prematurely, and that first and foremost includes actually writing any code at all.
I don't know about other companies, but we very rarely get the budget to go back and optimise code which has been tested and released. We are expected to meet the task's requirements under time pressure and if there are performance issues down the line, red flags are raised - often with the blame resting on the offending developer.
When I develop, I don't think about that stuff not because I ignore it but because it's ingrained.
I don't think "Should this be a factory? A decorator?" I just tend to notice opportunities to use these and other patterns.
The reasons you shouldn't think about it is because it's an instinct, not because you're ignoring it.
This is why I love TDD: the only code I need to think about are the tests that implement my expectations. Writing the code itself is easy, I just have to write the dumbest thing that will make the tests pass.<p>Of course, this all assumes you've got the right architecture for the job.
"Make it work, make it work right, make it work fast"
or
"Premature optimization is the root of all evil"<p>This is where it starts for me - <a href="http://www.faqs.org/docs/artu/ch01s06.html" rel="nofollow">http://www.faqs.org/docs/artu/ch01s06.html</a>
I just consider what code would be correct. Does it do the right thing? Is it concise and clear? Is it stable, given all expected inputs?<p>I worry about optimization and all of the other details later.
Whenever I feel this way, I just open <a href="http://programming-motherfucker.com" rel="nofollow">http://programming-motherfucker.com</a><p>And I just start writing code.
Step 1) Do the dumbest possible thing that will solve your current problem. Try to explain it clearly so that other people will understand what you did and why, but don't spend effort on being clever.<p>Step 2) Assess whether this is good enough, if so, move on to the next problem. If not, think hard and do something smarter.