Hacker News new | ask | show | jobs
by hinkley 955 days ago
These are the wrong yard sticks.

Here's another person making a dangerous analogy between code and a goal with a fixed end date. A paper that has been graded is done. A book that has been published is 99.9% done.

Code that is no longer being touched is not done; it's dead.

I have a five year plan for every tree in my yard. You can't rewrite trees, and there's a maximum rate at which you can refactor them. So there's what you can do now, what you will do next, and everything beyond that is educated speculation. You can't control it. You can't control the elements or disease or accidents.

So I know what I want to do, and I know how much I will do in the spring, and how much I'll have to delay until next year. And next year, or the year after, I'll step back, look at the whole thing again, and make a new plan, that might not look too much like my current plan. It all depends on what the other forces acting on my projects get up to in the meantime.

Like the trees, you can't control your coworkers, you can only influence, steer and remove. If you try to exert more control, you end up with a tiny little tree. And the dirty little secret with those is that the tree still does largely what it wants, and the skill is in making what actually happened look like it was on purpose.

If you want a big happy tree, you have to focus on the irreversible decisions, and let a lot of the little shit go (for now), and sometimes try again later. If all goes well, the only person who thinks the end result is a mess will be you. A layperson will think it was all going according to your plan.

2 comments

> Code that is no longer being touched is not done; it's dead.

Scripting code I wrote in 1998 worked in 2005 and still works today. Javascript I wrote 5 years ago, works today. Language choice matters as much as how it's executed. I assume VMware running a vm from 2008 is still running somewhere.

If it's not being executed, it's dead. There's a big difference from the "always needs to be maintained" assumption.

> Code that is no longer being touched is not done; it's dead.

The goal should be to write code not needing maintenance.

Four weeks ago I contacted a coworker to ask about some routines he wrote 5 years ago. He said he hadn't touched them in 5 years. The code has been tested continuously in the interim. His old code worked perfectly for me the first time and it saved me hours.

Code that hasn’t been touched gets forgotten. Even if it’s not accumulating new known security holes, and new performance or correctness deficits from not leveraging newer APIs.

It’s basically abandonware that is waiting for one major problem to render it obsolete. I don’t entirely agree with npm and GitHub ranking projects by recent activity, but they’re not entirely wrong either.

You can always be clarifying variable names or shoring up docs. Updating dependencies and keeping track of APIs without necessarily changing the fundamentals of the project.