Comments for page "Finish your stuff"

(no title)

Fri, 10 Jul 2015 05:17:38 +0000

Split it into small components. Provide extensibility mechanisms. Build new components on the top of the old ones. The only valid reason for something to change is that it is an experiment, i.e. deliberately unstable.

(no title)

Fri, 10 Jul 2015 02:14:24 +0000

How does this apply to applications? Should an editor like Atom be initially feature complete and never change? Or, how about a browser like Chrome? The only software I can think of that's truly done are those on mediums that inhibit future iterations. Especially, videogames and firmware.

(no title)

Wed, 08 Jul 2015 15:06:57 +0000

I state this differently when talking to customers, "An app, tool, or library should do one thing and do it very well." If this is followed, the temptation to create one tool that does everything goes away. I've seen good apps and other products bloat up to un-usability for May reasons. One of those is to remain "relevant to the marketplace."

(no title)

Tue, 07 Jul 2015 05:17:11 +0000

By building new and cool software on top of them?

(no title)

Mon, 06 Jul 2015 22:33:15 +0000

I agree with the notion that small focused, finished software is better than the alternative. However, how do you find out about it? Like it or not, the usage of software seems to follow communities and communities are built around things that people can discuss over time such as features, bugs, etc. You may have built the best code, but how are people going to discover it today, let alone 5 years from now if noone is talking about it? I sometimes wonder how many really good libraries have been forgotten on Sourceforge this way.

(no title)

Mon, 06 Jul 2015 15:09:19 +0000

slist is libmill-specific, but you have a point here: If your project depends on a project that is never finished, it itself won't be ever finished.

The trick here is to pick the right dependencies, ones that don't change. POSIX, for example, is stable for a decade. So are most mainstream programming languages. Many core UNIX tools are as well.

I think that it's mostly developers of the low-level infrastructure how should reflect on finishing stuff. If they don't everybody else is screwed.

(no title)

Mon, 06 Jul 2015 14:58:50 +0000

Good advise, just wish more people would take it! Cheers

(no title)

Mon, 06 Jul 2015 14:33:08 +0000

Thanks for this. Made me think as well as look very honestly at my developer ethics.

(no title)

Mon, 06 Jul 2015 14:31:36 +0000

Libmill code looks like Redis in the sense that is has no dependencies. How do you handle your improvements to, say, slist.c, which is probably used in all your C projects?

(no title)

Mon, 06 Jul 2015 14:30:02 +0000

Libmill repo looks like Redis! :)

(no title)

Mon, 06 Jul 2015 14:17:39 +0000

That's the very point. You don't modify original project beyond recognotion. You just start a new project.

(no title)

Mon, 06 Jul 2015 13:17:08 +0000

A software project is 'done' when the last end user is in his grave. I don't agree with the 'grep' example. It may be very stable (last commit on gnu-grep is from september 2014), but there are projects which aim to make a better grep: ack-grep and ag (the silver searcher)

(no title)

Mon, 06 Jul 2015 12:19:09 +0000

Code generation. Any case that doesn't yet require a full blown compiler, but is already too hard to maintain by hand.

(no title)

Mon, 06 Jul 2015 12:09:05 +0000

greetings from india,
good advice man
rgds

(no title)

Mon, 06 Jul 2015 11:27:57 +0000

ill give you two*. one is a "security" app for taking photos from the isight camera whenever your laptop is woken up. the other is an app for reading twitter feeds from the speaker.
both are cocoa apps that was supposed to help me transition to being an ios developer.
then lion and mountain lion happened and i realized it was impossible for me to keep on supporting the software. so i abandoned it. guess what, instead of becoming an ios dev i became a ruby dev instead.

there really is no point to this story other an just go where the current takes you. :)
http://www.macupdate.com/developers/profile/7341

(no title)

Mon, 06 Jul 2015 11:27:15 +0000

Umm…Ribosome use case?

(no title)

Sun, 14 Jun 2015 18:36:27 +0000

It would be helpful if you explained why this is such an essential principle. "Finished" as compared to "always working" or "maintained" or "living", which seem much more useful than a simple "finished", which seems to include a suspicious quantity of "abandoned".

Anyhow, finished projects are not rare in the real world. I've done lots of these: Libero, GSL, SFL, SMT, ASL, PAL, OpenAMQ, even Xitami. There's no magic. You make the tool, document it fully, take it through maturity, and then stop changing it.

There are many, many finished projects out there. When they change it's for tiny, or environmental reasons, unless you consider "unmaintained" to be an essential property of finished. Even a carpenter will repair tables and chairs.

Indeed, I'd expect that the bulk of projects running on a typical Linux are "finished", though I hope as user that they are not abandoned.

libzmq is also finished, and it doesn't send email (as you know well). ZeroMQ is a community, not a project, and as such I don't think "finished" can or should apply. The community mostly invests outside the core library, as it should.

(no title)

Sun, 14 Jun 2015 08:19:15 +0000

Good luck! The more finished software out there the better. Both for using it and as an example for the others.

(no title)

Fri, 12 Jun 2015 22:07:34 +0000

Thanks for this Martin, always love your writeups!
I ran into this same problem over the years, several times.
I've also spent way too much time on compatibility layers that have largely become obsolete by languages and compilers advancing over the years.
As a consequence I'm working on aggressively downsizing my projects Rapicorn and Beast now and have a few very clear use cases that should be well covered.

(no title)

Fri, 12 Jun 2015 14:09:40 +0000

Good advices!

(no title)

Wed, 10 Jun 2015 19:03:37 +0000

1. compatibility library, e.g. apl, libuv
2. coroutine library, e.g. libtask, libmill
3. the core: messaging protocols

It may even make sense to implement individual messaging protocols as separate components.

Congratulations.....

Wed, 10 Jun 2015 10:24:31 +0000

How would you split nanomsg, then?