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

Finish your stuff

250bpm.com

Post reply on HN
Print view View original

21–30 of 177 posts

Re: Finish your stuff

#21

Post by mironathetin »

onion2k wrote: post #10

There's a great list of project management advice by Jerry Madden of NASA that gets posted here occasionally[1]. One of the points is; "Rule #30: It is mainly the incompetent that don't like to show off their work." Madden's remark is based on the specific environment he was involved in (NASA engineering); if you're surrounded by people who are good at their jobs and who know how to criticise constructively then ther…

There are other important reasons not to show things before they are done: one is the impatient group member who rather refocuses a development than to wait until it converges to something usable. It takes a lot of experience to make a realistic guess, how long software projects take. It also takes a lot of experience to put progress reports in a way that it always looks like great things are happening in order to avoid the refocus discussion.

The all important point is a constructive team that knows their job. But especially in space project related development, you may be surprised to find managers who don't know much about software.

Re: Finish your stuff

#22

Post by mironathetin »

georgerobinson wrote: post #13
melling wrote: post #5

"Real artists ship" "if you are not embarrassed by the first version of your product, you've launched too late" https://en.m.wikipedia.org/wiki/Release_early,_release_often I'm sure there are many others, but these ones keep me shipping.

If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.

"If you're embarrassed by the first version of your product (i.e. suppose it's buggy, ..."

A first release must not be buggy. But it can have a limited set of functionality. Imho, the real art of software development is to restrict the initial set of functionality and get that done, as quickly as possible (but not quicker), bug free (sic) and useful.

Re: Finish your stuff

#23

Post by z3t4 »

If you think "giving up" on a project is easy. Try "giving up" on your "dreams", those project you work on every day, even though you know you wont make it.

Re: Finish your stuff

#24

Post by gedrap »

In my own experience, I found the following 2 things being the most important:

1) Keep it fun. Sometimes you start working on something and a week later you realize it's not as great as you expected it to be. Maybe you are working on some game and you can see it won't be as fun to play as you thought, etc. It's fine, it's ok to stop working on it. Forcing yourself to work on it won't produce any good.

2) Start with well defined, small goals. Define v1.0 which would contain only the most critical features, ship it (even if it means simply tagging on git). There's something hugely motivating about completing things, no matter how simple they are.

EDIT. One more thing I'd add, when working on a side project, don't start thinking about how everyone will be using, how many thousands of github stars it will have, whatever. It doesn't even have to be actually useful, as long as you have good time and learn something on the way. I've worked on a few projects that I'd say are totally useless (such as https://github.com/GedRap/xs-vm ) but at the same time I see them as successful because a) had great time b) learned something new, even if it's some small details about a library or a language.

Re: Finish your stuff

#25

Post by gedrap »

georgerobinson wrote: post #13
melling wrote: post #5

"Real artists ship" "if you are not embarrassed by the first version of your product, you've launched too late" https://en.m.wikipedia.org/wiki/Release_early,_release_often I'm sure there are many others, but these ones keep me shipping.

If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.

I think the balance is the key. It's a very catchy phrase but yeah, one should not take it very literally.

Re: Finish your stuff

#26

Post by HappyTypist »

amelius wrote: post #8

> You bought a damned chair and you want it to remain a chair, not to find out that it's some kind of protean piece of furniture that's a chair today and partly a table tomorrow and, who knows, maybe you'll be able to humidify your cigars in it next week. This is exactly my problem with web-services (and software that auto-updates itself).

Every software is like this to some extent. The more external stuff they link, the more affected. Even if something doesn't auto update, eventually you'll have to update to the latest version because certain functionality will no longer work the way it should. Sure, you can fork it, but many software projects take more than one person to maintain.

Re: Finish your stuff

#27

Post by wainstead »

I thought the Unix philosophy embraced the idea of "small tools that do one thing really well."

> Please join me in my effort and do finish your projects.

Hear, hear. A friend and I hosted a "Finish it! Weekend" once (as opposed to a "Startup Weekend"). The idea was to get people together for one weekend and finish that last 10% or whatever of a project. Sadly we were the only two to show up. (And we both finished our projects, which suggests this might be a good kind of hackathon to host every six months or so).

Re: Finish your stuff

#29

Post by pfortuny »

Oh, come on: software is usually much more than a table or a chair. It grows, it needs care, it is more like a plant than something static.

What does it even mean to "finish" a program like 'ls' given the increasing complexity of filesystems with time?

Re: Finish your stuff

#30

Post by karlmdavis »

georgerobinson wrote: post #13
melling wrote: post #5

"Real artists ship" "if you are not embarrassed by the first version of your product, you've launched too late" https://en.m.wikipedia.org/wiki/Release_early,_release_often I'm sure there are many others, but these ones keep me shipping.

If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.

There's a set of tradeoffs here. 1) You really, really need feedback from your users as early as possible, to help keep you on-track. 2) Shipping something truly half-baked can kill your chances with most of those users.

The trick is in threading the needle on this one. In my experience "shipping" doesn't need to be a binary operation. Seek out your early adopters as soon as possible, get your product in front of them, and take their (hopefully) constructively blunt feedback to heart. Ask them what's needed to make it truly usable for the rest of your users.

Post reply on HN