4 ms·

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

by csl_ 15y ago

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)

astine 15y ago
"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.
- Deestan 15y ago
  > 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.
  - scott_s 15y ago
    It depends on just how useful, and how ugly, it is. See: http://dreamsongs.com/WorseIsBetter.html http://dreamsongs.com/WorseIsBetter.html
    - Deestan 15y ago
      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.
      - scott_s 15y ago
        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?
  - follower 15y ago
    > 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. :)
- hebejebelus 15y ago
  The code is on github, here: http://github.com/CarlQLange/fit http://github.com/CarlQLange/fit
jasonjackson 15y ago
Nathan's talking about solving recurring problems (that belong to a single problem class).
sbochins 15y ago
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.

by csl_ 15y ago

astine 15y ago

"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.

Deestan 15y ago
> 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.
- scott_s 15y ago
  It depends on just how useful, and how ugly, it is. See: http://dreamsongs.com/WorseIsBetter.html http://dreamsongs.com/WorseIsBetter.html
  - Deestan 15y ago
    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.
    - scott_s 15y ago
      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?
- follower 15y ago
  > 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. :)
hebejebelus 15y ago
The code is on github, here: http://github.com/CarlQLange/fit http://github.com/CarlQLange/fit

jasonjackson 15y ago

Nathan's talking about solving recurring problems (that belong to a single problem class).

sbochins 15y ago

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.