I've had the opportunity to work with lots of teams on lots of different platforms in lots of different languages and frameworks. This has been great educationally for me, being able to see more than just two or three pictures. One thing that I have noticed regardless of project, platform or language is the idea of "refactor later."

I think that it's redundant to say that there is value in properly written code, but I'll say it anyway. There is value in properly written code. In an interview one time, I was asked the question "What if I [the project manager] asked you to implement a feature in a given time frame, and you could either do it the 'right' way and miss the deadline, or implement a hack to come back to when there was time and deliver it on time." My naivete got the better of me, and I answered the question the way I thought the interviewer wanted it. "Well, I'd write a test case, implement the hack, and then come back, and using the test case to make sure code didn't get broken, do it the right way." I got the job, and one month into it, I regretted it. The entire attitude of implementing the hack to get out the door was what the whole company was founded under. On the tail end of the job, I was blamed for IMPORTANT code being rolled to production commented out, functionality that only appeared to work being pushed to production, and spending too much time developing what was "simple functionality." Yea, if the code wasn't breaking every time I added a new line...

The "refactor later" pattern plagues so many projects for no reason. From my experience, it stems from a desire to design properly, only to have an issue come up that was unforeseen. The solution is throw something together that works, and "refactor later." I would say, though, that the "later" never comes, and the "refactor" never happens. This amounts to bad things like repeated code, inefficient code, and even unused code.

When I first started getting into electronics and gadgets, I learned a valuable lesson: "Buy cheap, buy twice." I would like to create a similar stigma to a similar situation of cutting corners to cut costs in software development. While I'm not good with the clever wording, it would be something to the effect of "every line of corner cutting code exponentially effects your ability to refactor later." By writing "refactor later" code, you're increasing the threshold on when that "later" happens from maybe a few minutes to days and weeks (and maybe months) refactoring code that, having been written cleaner before, would have been more maintainable, and easier to add functionality to later on.