"The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building."
Then how is the project incomplete? If it's not a product that you're planning to sell, put your code on Github or the like and others will add any features that you're missing.
WiB is more about appreciating barebone low-level tools, like C/Unix in the posted example. These tools are crude but technically polished, otherwise no-one would bother to use them.
It depends on what you mean by "technically polished." Unix handles interrupted signal calls by returning an error code that means "I was interrupted." This technique bunts on the hard problem of rolling back OS operations. It is not "technically polished" in that it does not solve all of the hard problems in front of them. But it's still useful, and it caught on because people used it.
Gabriel's insight is not about low-level tools. It's about at what point can you bunt on the hard problems, have an ugly work-around, but still be useful enough that no one will use "the right thing" when it eventually comes about?
> No they won't, because he hadn't even started on the "make it beautiful".
At the risk of sparking a language war--the iTunes control project is written in Python so it has a certain level of consistency to start with.
> When I want to solve a new-ish problem, I can't imagine grabbing some barely working cowdung from some guy's github repo.
One developer's cowdung is another developer's works-for-me code. :)
For me part of the standard development process is the "literature review" which consists of finding all the prior art (polished or not) and evaluating it. I'd much rather someone uploaded their code in any state than not at all. YMMV. :)
Then how is the project incomplete? If it's not a product that you're planning to sell, put your code on Github or the like and others will add any features that you're missing.