The biggest problem I have with this approach (and believe me, I love this approach), is that it makes it hard to finish things.
For example, over Christmas, I built a small pretend-natural-language CLI controller for iTunes. I made a working version in something like four hours, spent a few days adding in crazy half-thought-out features like speech recognition and a web interface - and then I basically stopped development.
I didn't stop development because it got boring - I stopped development because I'd solved my own problem. Not beautifully (certainly not from a coding perspective), not efficiently, but the problem I had was solved.
The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building.
(oddly, my password for my old account no longer seems to work. I was hebejebelus)
"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. :)
I think in this case the approach worked fine for you. Most of the times a hacky solution will do. Not everything needs to be cleanly architected and bug free, especially a weekend project.
Comments
The biggest problem I have with this approach (and believe me, I love this approach), is that it makes it hard to finish things.
For example, over Christmas, I built a small pretend-natural-language CLI controller for iTunes. I made a working version in something like four hours, spent a few days adding in crazy half-thought-out features like speech recognition and a web interface - and then I basically stopped development.
I didn't stop development because it got boring - I stopped development because I'd solved my own problem. Not beautifully (certainly not from a coding perspective), not efficiently, but the problem I had was solved.
The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building.
(oddly, my password for my old account no longer seems to work. I was hebejebelus)
"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.
> put your code on Github or the like and others will add any features that you're missing.
No they won't, because he hadn't even started on the "make it beautiful".
When I want to solve a new-ish problem, I can't imagine grabbing some barely working cowdung from some guy's github repo.
If he hasn't even tried to make it clean or readable, it'll take me more time to make sense of the mess than just rebuild it myself.
It depends on just how useful, and how ugly, it is. See: http://dreamsongs.com/WorseIsBetter.html
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. :)
The code is on github, here: http://github.com/CarlQLange/fit
Nathan's talking about solving recurring problems (that belong to a single problem class).
I think in this case the approach worked fine for you. Most of the times a hacky solution will do. Not everything needs to be cleanly architected and bug free, especially a weekend project.