4 ms·

I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous an

I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous and almost ridiculous when you compare them to how quarterly or even bi-quarterly planing cycles look.

hinkley 8y ago
Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed. Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts. The problem with doing something right the first time is nobody appreciates how hard it was.
- deleted 8y ago
  [deleted]
- drawkbox 8y ago
  > 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

hinkley 8y ago

Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed. Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts. The problem with doing something right the first time is nobody appreciates how hard it was.

deleted 8y ago
[deleted]
drawkbox 8y ago
> 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