< Restlessness

~brightblue

When I was young in the software craft I was asked to repair an old, creaky app written by a developer long gone. Thinking I knew better, I ripped it apart and started over from the ground up. Two months later I realized I was painfully and slowly following in my predecessor's footsteps.

It's been interesting during my career to watch people leave stable products like Apache for the new hotness of node or nginx or whatever. And while we shouldn't be hidebound into using what daddy used for his websites, I do agree that the new servers seem to make a lot of the mistakes that Apache figured out twenty-five years ago. Seems like there should be a way to move forward without losing the past in the process.

Write a reply

Replies

~kyle wrote:

> Two months later I realized I was painfully and slowly following in my predecessor's footsteps.

Absolutely true: there's often some pearl of hidden wisdom that justifies a software being perceived as bad. If it is you who wrote the software in the first place, you might be able to fix it the right way, or at least to leave tracks (comments?) for the ones who come after you. If you're not the one who wrote it, and there's no track, you are pretty much doomed to realize the hard way.

On the lucky case, the ugly part is covering some issue which is no longer a problem nowadays. I'm now thinking about, autoconf, that makes sure you've got uint32_t defined: what libc doesn't come with uint32_t defined nowadays? Yet, replacing autoconf means you've got to ensure portability yourself: good luck with that! Or get rid of portability entirely: thank you very much for restricting those who have a different system than yours.