Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

medium.freecodecamp.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#11

Post by _asummers »

Cynddl wrote: post #2

Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…

At work, we've been using Elixir. Because of the Erlang interop, I find myself looking at a lot of Erlang code that hasn't really had any reason to be touched in years. It's really bizarre seeing a project with no commits in the last few years and having to decide if it's abandoned or feature complete.

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#12

Post by falcolas »

insulanian wrote: post #4
Cynddl wrote: post #2

Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…

Old last commit date could mean two things: 1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it. 2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future. I thin…

A project could be effectively both - the developer still wants (wanted?) to add more features, but what's there is complete and stable.

Word of mouth and some good old experimentation seem to be your best options for identifying solid tooling.

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#15

Post by kuzimoto »

insulanian wrote: post #4
Cynddl wrote: post #2

Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…

Old last commit date could mean two things: 1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it. 2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future. I thin…

I think most of the time I just assume it's #1 and then check into the issues to see the number/severity of the current problems and if any important things are being neglected.

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#17

Post by nerdponx »

But after looking at the source code we found a fatal flaw in this tool: it used Graphviz — a decades old tool written in plain C and compiled to unreadable JavaScript using Emscripten.

Are the "decades old" and "plain C" aspects supposed to be bad things? It seems like the real problem is "compiled to unreadable JavaScript". Graphviz is a great example of "if it ain't broke, don't fix it".

Re: How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI

#20

Post by crdoconnor »

Cynddl wrote: post #2

Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects. > Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons…

>I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.

I do it because of code rot. The environment you will surround the project with (runtimes, libraries, frameworks) has often changed enough in 2-4 years to render it unusuable.

Additionally a recent commit implies regular maintenance which implies that if you report it will get fixed.

Also, projects are often abandoned because there is a clearly better version out there.

Post reply on HN