undefined

points

[-]

For this command in particular, one can add a cheap bar chart with awk:

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c | awk '{printf $2" "; for (i=1;i<=$1;i++){printf "-";} print ""; }'

by zikani_034 hours ago|

parent|

[-]

This is a neat trick for a quick visual presentation, thanks!

by goosejuice6 hours ago|

prev|

[-]

Yeah, this one demonstrates a particularly pernicious view of software development. One where growth, no matter how artificial, is the only sign of success.

If you work with service oriented software, the projects that are "dying" may very well be the most successful if it's a key component. Even from a business perspective having to write less code can also be a sign of success.

I don't know why this was overlooked when the churn metric is right there.

by BeetleB6 hours ago|

parent|

[-]

Bad memories at my former big tech company.

Whenever we initiated a new (internal) SW project, it had to go through an audit. One of the items in the checklist for any dependency was "Must have releases in the last 2 years"

I think the rationale was the risk of security vulnerabilities not being addressed, but still ...

by ziml777 hours ago|

prev|

[-]

That was my question too. I have plenty of projects I've worked on where they rarely get touched anymore. They don't need new features and nothing is broken.

by SoftTalker6 hours ago|

parent|

[-]

Is it fair to say they are being "worked on" if nothing is being done?

by duckmysick5 hours ago|

parent|

[-]

Sometimes you need to bump a dependency version, adjust the code to a changed API endpoint, or update a schema. Even if the core features stay the same, there's some expected maintenance. I'd still call that being worked on, in a sense that someone has to do it.

by onion2k8 hours ago|

prev|

[-]

Technically you're correct that change frequency doesn't necessarily mean dead, but the number of projects that are receiving very few updates because they're 'done' is a fraction of a fraction of a percent compared to the number that are just plain dead. I'm certain you can use change frequency as a proxy and never be wrong.

by Supermancho8 hours ago|

parent|

[-]

> I'm certain you can use change frequency as a proxy and never be wrong.

I (largely) wrote a corporate application 8 years ago, with 2 others. There was one change 2 years ago from another dev.

Lots of programs are functionally done in a relatively short amount of time.

"Accelerating or Dying" sounds like private equity's lazy way to describe opportunity, not as a metric to describe software.

by onion2k7 hours ago|

parent|

[-]

That sort of project exists in an ocean of abandoned and dead projects though. For every app that's finished and getting one update every few years there are thousands of projects that are utterly broken and undeployable, or abandoned on Github in an unfinished state, or sitting on someone's HDD never be to touched again. Assuming a low change frequency is a proxy for 'dead' is almost always correct, to the extent that it's a reasonable proxy for dead.

I know people win the lottery every week, but I also believe that buying a lottery ticket is essentially the same as losing. It's the same principle.

by goosejuice6 hours ago|

parent|

[-]

With respect, this is a myopic view. Not all software is an "app" or a monolith. If you use a terminal, you are directly using many utilities that by this metric are considered dying or dead.

by dan-bailey8 hours ago|

prev|

[-]

Projects become more stable with time? Since when?

by Sharlin8 hours ago|

prev|

[-]

Something something Red Queen's race

by stackedinserter8 hours ago|

prev|

[-]

Or you hired someone who squashes or doesn't commit every single change.