top | item 38692856

(no title)

inDigiNeous | 2 years ago

Good article on the basic nature of software projects, they never seem to end unless you decide them to end. When to do that ? Who the hell knows, it took me about 10 years for my own project to reach a state where I could say "This is done now, I am satisfied with the goals I set to reach 10 years ago".. And even that came through because I was exhausted working on the project, spending so much time on it.

I think you have to decide at some point: "This is done."

Maybe it requires stripping out some parts, or major parts, of the software you had in mind to reach that, but I feel it has to be done at some point, the feature creep will settle in otherwise and you will never be done.

discuss

order

atoav|2 years ago

It might be even worse — let's try to answer one question: Can software ever be finished?

And if it was finished, what would people think about it? No commits since a year? Dead!

Jokes aside, I think software can be finished in the same way you finish building a house. Sure it built now, but that doesn't mean that maybe in a year or ten something major has to be done because the components that make the house changed, the environment changed, the requirements changed etc.

hobofan|2 years ago

What has helped me (and this may sound like an absurd suggestion as it creates even more work) is to split up all my projects into a public- and a private-facing part, and trying to follow the UNIX principle ("Write programs that do one thing and do it well.").

For all the things I want to share to the world, I'll make it into a small project that from the start has stated goals and non-goals. If there is some divergence from what I need personally from it, I'll have private fork (sometimes also just so I can work on it in a "fast and ugly" manner). By splitting them up consciously, the public and the private part can fulfill their individual goals a lot better ("polished"+finishable public shared part; tailored to my needs perpetual imperfect private part).

That also works surprisingly well for non-code things, like blog posts, where my private versions have a lot more references and detail tidbits sprinkled in, that would overwhelm the target audience of the public version of the post (mostly because it would take too much time to work it into the post in a good way). I guess that's also not a too uncommon phenomenon in the arts, with director's cuts of movies and additional mixes of music existing parallel to the commercially published version.

Tor3|2 years ago

I did a 'git log' of my emulator project.. the first entry is from December 1998, so 25 years by now.. (I used CVS back then, thus the early timestamp. It was converted to Git some years later). I still fiddle with it now and then.

Edit: That's not my oldest project, I may have some older ones still going but there's one with an initial commit from 1994, the last time I updated that one was in 2019 (in 1994 that would be SCCS, later converted to CVS, and after that to git)

Cthulhu_|2 years ago

In my professional experience, software is never finished, it's just that at some point it's decided to rewrite or replace a piece of software and decomission the old.