> The problem with doing something right the first time is nobody appreciates how hard it was. Sometimes if you do put in quality and do it right in developmen

> The problem with doing something right the first time is nobody appreciates how hard it was. Sometimes if you do put in quality and do it right in development it costs you in time and then by perception. When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally. The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones. Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product. I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready. [1] https://developer.valvesoftware.com/wiki/Valve_Time https://developer.valvesoftware.com/wiki/Valve_Time