Rewriting software
I once attended a conference in Santa Fe and met a very interesting fellow who wrote particle simulation software. He had a very interesting perspective on software development. He told they would sweat bullets writing the best software they could, because they knew they were going to have to rewrite it. In fact, he told me that their usual trajectory was three rewrites before they felt they had a really good grip on the application domain. That’s rewrites. In other words, 4th time was the charm. He did assert the third rewrite generally went really fast.
Compare this with an actual statement from a peer engineer at a previous company (paraphrasing): “It’s not worth putting much effort into it because the whole thing will need to be rewritten in a few years anyway.”
I’m not advocating for multiple rewrites of software. Unless there is a compelling business case and a crack team, rewrite typically end in tears.
But, who learns more?
The question gnaws at me. What if rewriting was a skill which could be mastered? What would that look like? And how best to develop such a skill?
Update: I found this quote from Ryan Bergman’s interview on StaffEng:
You really don’t get a system right until the 4th time.