Finish your stuff
250bpm.com
Finish your stuff
1–10 of 104 posts
Re: Finish your stuff
#2"You bought a chair."
Re: Finish your stuff
#3Great software projects are never finished; instead they always evolve and improved similarly to living organisms and unsimilar to material things.
I completely disagree with your analogy to a carpenter who builds a chair, this metaphor is wrong and responsible for a lot of misunderstandings when it comes to software development.
Re: Finish your stuff
#4What would that look like?
Consider an example:
You have made a little web app that beeps at certain times of the day to remind me to do something.
Is it complete?
Oh, you want a calendar integration. That makes sense. You add it. Is it complete?
Oh, you say you want to release mobile versions? Okay, now is it complete?
Sorry, but the iOS version needs to be updated to remain compatible. Now is it complete?
There is a new popular cal app that everyone uses. Should you update it to work with that?
The problem isn't that the software is incomplete. The "problem" is that the world keeps changing.
To the extent that the environment doesn't change (unix), you can "complete" your tool.
Re: Finish your stuff
#5This sounded oddly familiar, until I read about the projects Libmill and Ribosome. And yeah it's a post already submitted in 2015 and should be labeled 2015.
Re: Finish your stuff
#6Great software projects are never finished; instead they always evolve and improved similarly to living organisms and unsimilar to material things. I completely disagree with your analogy to a carpenter who builds a chair, this metaphor is wrong and responsible for a lot of misunderstandings when it comes to software development.
How about the words "fully baked"?
I also don't agree that "finish your program" needs to be added to the unix philosophy because a tool that does one thing and does it well is finished by definition.
Re: Finish your stuff
#7What would that look like? Consider an example: You have made a little web app that beeps at certain times of the day to remind me to do something. Is it complete? Oh, you want a calendar integration. That makes sense. You add it. Is it complete? Oh, you say you want to release mobile versions? Okay, now is it complete? Sorry, but the iOS version needs to be updated to remain compatible. Now is it complete? There is…
I guess it depends on what granularity you are viewing your project at. Your beep app could be complete and if you want calendar integration, that's a new project that takes input that is somehow piped into it from the beep app. The ios version is a new project that imports beep as a lib..
It's one way to look at things anyway.
Re: Finish your stuff
#8> it's almost impossible to find anyting that's truly finished, not simply abandoned.
This goes far beyond programming. "completeness" is nice but is highly subjective. For work that can be infinitely revised, refactored, recut, "finished" is an idea you impose from the outside, in relation to specific criteria.
The author seems to be saying that there is value in creating smaller, independent modules of things that can be said to be "finished" when they do their thing and no further functionality is added or expected to be added. Further functionality, if needed, would come from connecting "finished" things together, I suppose, or making new things- not over extending a component to handle all cases.
This moves the complexity around a bit and maybe it's more efficient and easier to handle this way.
Artists have a similar problem. It's hard to know when a poem or a song is "functionally complete" but eventually you have to let them go or you never get anything out there.
I'm all for conscientiously abandoning work, especially if the state of the work is well documented so that somebody else could, in theory, pick it up.
Re: Finish your stuff
#9Great software projects are never finished; instead they always evolve and improved similarly to living organisms and unsimilar to material things. I completely disagree with your analogy to a carpenter who builds a chair, this metaphor is wrong and responsible for a lot of misunderstandings when it comes to software development.
How about the words "fully baked"? I also don't agree that "finish your program" needs to be added to the unix philosophy because a tool that does one thing and does it well is finished by definition.
Except very trivial cases, any piece of software contains bugs that need to be fixed needs to add features based on new user stories and also must to adopt to the constantly evolving hardware. Linux is a perfect example of this constantly evolving and never finished paradigm and if anything it can be used not to support but to invalidate the "finish your program" philosophy.
Re: Finish your stuff
#10What would that look like? Consider an example: You have made a little web app that beeps at certain times of the day to remind me to do something. Is it complete? Oh, you want a calendar integration. That makes sense. You add it. Is it complete? Oh, you say you want to release mobile versions? Okay, now is it complete? Sorry, but the iOS version needs to be updated to remain compatible. Now is it complete? There is…
I think the Unix philosophy would have you pipe those beeps to another program that does your calendar integration.