Live data from Hacker News

Finish your stuff

250bpm.com

101–110 of 177 posts

Re: Finish your stuff

#101
post #79

I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly. Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to t…

If it's anything you expect other people to use, then I'd consider anything that hasn't been updated in the past year "abandoned", yeah. If it's your personal projects though, I don't make that assumption.

I have several projects that haven't been updated in more than a year which are still maintained in the sense that if there are bugs, I fix them. They are rarely touched for a simple reason: They do what they're meant to, and they still work.

I wish more software took that approach. Far too often software quality drops after a while as developers keep piling on the features.

Re: Finish your stuff

#102
post #79

I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly. Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to t…

If it's anything you expect other people to use, then I'd consider anything that hasn't been updated in the past year "abandoned", yeah. If it's your personal projects though, I don't make that assumption.

Abandoned or stable? If it has no dependencies and a small feature set, it may just be done. "Stable" is a good thing.

Re: Finish your stuff

#103

Now what if your home regularly changed in such a way that your old chairs didn't sit upright anymore? There are limits to the carpentry analogy.

In which case perhaps the reasonable solution is for you to get a different type of chair, rather than trying to modify your old chairs to fit the changing requirements.

Re: Finish your stuff

#104
post #36

"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size." After 30 years of programming, you'd better be a pretty decent programmer. And maybe that's why their projects take less time to complete.

If you look at his progression, a lot of it is also about shaving down the size and complexity. E.g. the AMQP -> 0mq -> nanomsg chain which is a journey of cutting complexity.

Re: Finish your stuff

#105
post #47

Is nanomsg finished? I found its Windows support rather broken -- failing test cases. Strange lockups. https://github.com/nanomsg/nanomsg/issues I do not see Martin working much on those these days. Does anyone know how untangle those state machines besides him.

See his comment in the comments on what he thinks about how to decompose nanomsg, it's quite interesting.

Re: Finish your stuff

#106

The Zero MQ guys seem to have some pretty good wisdom to impart. Pieter Hintjens has a free book at http://cultureandempire.com which is worth a read.

The iMatix guys have been amongst my heroes since they released Libero (state machine code generator) and built Xitami on it (both mentioned by Hintjens as "finished" projects in a comment to the linked article) back in the 90's...

Re: Finish your stuff

#107
post #9

Earlier quoted context omitted.

If I ever buy a car with skateboard as a chassis, I'll be very disappointed! Sorry, just had to =)

Probably it should be build the tyre first. This is a functionally complete thing that can, along with many other functionally complete things be composed into the car.

step 1 "invent the wheel"

Re: Finish your stuff

#108
post #57
post #9

Earlier quoted context omitted.

Probably it should be build the tyre first. This is a functionally complete thing that can, along with many other functionally complete things be composed into the car.

Car built with scooter tires... Scooter built with car tires... Just not seeing it. When Java was first becoming popular, I recall emphasizing how important it was to use the standard, well-documented, well-tested java.lang.String, rather than a custom String class as had been done in C++. Application domain experts started asking about strings that didn't fit in RAM (documents). A great, tested component in one doma…

Coding is a conceptual art-form, it's not about building a car with scooter tires, it's about upgrading vehicles to get the end result in a workable fashion. Try using spark plugs and pistons to get somewhere!

Re: Finish your stuff

#109
post #79

I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly. Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to t…

Then at the top of your readme you should absolutely write [[Project feature complete and stable]], or something to that effect.

You just can't look at a repo and discern its completeness in an easy way. Also explain why you think it's complete.

Re: Finish your stuff

#110
post #6
post #2

Some very practical, down-to-earth, solid advice. Lines I found insightful: "... make it functionally complete in the first place. ... If it can't be made functionally complete it's too big. You've tried to bite off a piece that's bigger than you can swallow. Just get back to the drawing board and split off a piece that can be made functionally complete." ^_^ I really like the idea of splitting a project into phases.…

> First the skateboard, then the scooter, then the bike, the motorcycle, and finally the car. I've always found this metaphor incredibly amusing, because, to me, it actually highlights the _problems_, rather than advantages, of the iterative approach. At every step of the process, you're not only increasing complexity, you're also pivoting your product to the point where: 1. your previous clients are unlikely to stil…

It's not about incremental development, it's about passing the baton. The spirit is motion/movement/transport, and the corresponding vehicle should be a natural expression of that with your available tools. Who said that the goal should be product-oriented? If I want to reach Alaska I will gladly take whatever transportation suits me best at the time. If I were insistent that my tank was clearly the most capable vehicle, although I would eventually get there, it would not be as enjoyable, imho.
Post reply on HN