2 ms·
The frustrating thing is when only the first half of this philosophy (ship now, fix/polish later) is adhered to, where things get shipped frequently but seldom
by kitsunesoba 5y ago
The frustrating thing is when only the first half of this philosophy (ship now, fix/polish later) is adhered to, where things get shipped frequently but seldom followed up on. The incentive to finish things needs to be strong for not only the engineers but also for the product teams and managers directing them, but as far as I can observe this is exceptionally rare — in fact it almost seems like the norm for non-engineers to push for shipping new features over polishing older ones. A lot of the engineers I know would love nothing more than the opportunity to polish the project they’re responsible for to perfection, but are never given the chance.
- danielmarkbruce 5y agoIf you can present a metric which shows that said thing is bad on some dimension, and explain why it's bad for the customer (/business) and why what you will fix will improve it, and how much work is involved, you'll have a better chance of moving it through.
- sdoering 5y agoI agree. I know that the freedom to create sensible architecture is a privilege. Even if other things may not be perfect (but what job is perfect in all areas), my boss knows the value of refactoring towards a stable and maintainable architecture while keeping a reasonable schedule for shipping.
- aimor 5y agoI agree, but I've also tried to polish things without a strong need and it's difficult. The work can feel burdensome, useless, undirected, and sometimes requires major changes that can't be done (without inflating the scope of the work).