4 ms·

> That's boring, and there are no incentives for fixing bugs in obscure features because only launching successful new features gains visibility from higher-ups

> That's boring, and there are no incentives for fixing bugs in obscure features because only launching successful new features gains visibility from higher-ups. Companies really should find a way to incentivize this. Rewrites are about as silly. "Write the next generation xyz." Translates to "No one here has any idea how xyz was written, so it's being rewritten instead of modified. We look forward to rediscovering the same problems we did the first time."

jacques_chester 14y ago
> Companies really should find a way to incentivize this. It can't be done from the top. You need to start with engineers who care about quality over the long term. It has to come from within each engineer. When Zuckerberg talked about younger programmers being "better", he probably meant "more like me". But old farts are just young farts with expensively-acquired scar tissue. Most of our most treasured software development lore comes from the lesson that "move fast, break things" just devolves into "fuck, everything is broken, fix it fast".
josteink 14y ago
"Write the next generation xyz." Translates to "No one here has any idea how xyz was written, so it's being rewritten instead of modified. Sometimes, when software has been around for 10+ years, stuff does get too old. It happens. For real. I know people seem to forget that here with startups having been around for less than a year being "old players" and all that, but common. Software may have been written with a bunch of presumptions which was valid when the project was initially started, but no longer are that. Maybe it was written on top of a platform which is no longer as productive as it was when the project was initiated. Nothing kills enthusiasm and productivity like working on a platform no longer deemed modern. And then you have technical limitations and pre-conditions. Once, servers was expensive and you wanted your solution to distribute it's load to clients so that you could save on servers. Once servers was the only machines powerful enough to complete time-critical tasks within reasonable time-frames, so you architected the software accordingly. Now, we suddenly have HTML5 and webworkers and shit, so you probably want your solution to be a web-solution with a distributed computation model. I.e. full-circle. Full rewrite. Twice. What's next, I don't know. Sometimes a rewrite is just right. Saying that every rewrite is based in incompetence is simplistic.

jacques_chester 14y ago

> Companies really should find a way to incentivize this. It can't be done from the top. You need to start with engineers who care about quality over the long term. It has to come from within each engineer. When Zuckerberg talked about younger programmers being "better", he probably meant "more like me". But old farts are just young farts with expensively-acquired scar tissue. Most of our most treasured software development lore comes from the lesson that "move fast, break things" just devolves into "fuck, everything is broken, fix it fast".

josteink 14y ago

"Write the next generation xyz." Translates to "No one here has any idea how xyz was written, so it's being rewritten instead of modified. Sometimes, when software has been around for 10+ years, stuff does get too old. It happens. For real. I know people seem to forget that here with startups having been around for less than a year being "old players" and all that, but common. Software may have been written with a bunch of presumptions which was valid when the project was initially started, but no longer are that. Maybe it was written on top of a platform which is no longer as productive as it was when the project was initiated. Nothing kills enthusiasm and productivity like working on a platform no longer deemed modern. And then you have technical limitations and pre-conditions. Once, servers was expensive and you wanted your solution to distribute it's load to clients so that you could save on servers. Once servers was the only machines powerful enough to complete time-critical tasks within reasonable time-frames, so you architected the software accordingly. Now, we suddenly have HTML5 and webworkers and shit, so you probably want your solution to be a web-solution with a distributed computation model. I.e. full-circle. Full rewrite. Twice. What's next, I don't know. Sometimes a rewrite is just right. Saying that every rewrite is based in incompetence is simplistic.