4 ms·

This is a useful concept. I also thought these lines were insightful: New features mean new sales opportunities, good for the company but not good for the user

This is a useful concept. I also thought these lines were insightful: New features mean new sales opportunities, good for the company but not good for the user. The problem with adding features to MVP is that when we ship more complex products like complete operating systems that are packed with programs, the complexity of the individual programs contributes to the complexity of the whole. Not sure how to solve that particular problem though. This made me think of a blogpost linked on Hacker News when Joe passed away: https://github.com/lukego/blog/issues/32 https://github.com/lukego/blog/issues/32. This part seems relevant here: Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!

klyrs 7y ago
Neat. That's essentially how I program, too. Early history in some of my git repos has the pattern git add program ... ... #first implementation works; time to rewrite git add newprogram ... ... #second implementation works; bury the first git rm program; git mv newprogram program ... This keeps my directory relatively clean, as I only have my previous attempt and the current refactor around at any given time. It also keeps the git history clean for the living files, and keeps the diffs nice and tidy.
- newnewpdro 7y ago
  Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. It's preferable to work in branches and rewrite and refactor incrementally whenever possible, merging the new code in as things progress at convenient milestones. Then the history documents which functionalities in the old implementation became what files and lines in the new implementation. That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore.
  - klyrs 7y ago
    > Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. That's the goal of this practice. Throw it all out and rewrite from scratch. > That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore. I'm talking about writing non-releases. The entire structure of the code, algorithms, data structures, API / CLI must not be preserved. Anything that stays constant between non-releases is either (a) a good idea or (b) a stone unturned. Rename variables, split and join modules, violently reorder function arguments... nothing is off-limits. After I've been through a few rounds of this, the first release should be entirely free of inessential warts (and maintenance is typically quite easy at this stage). After the first release, I'm a stickler about backwards-compatibility and my development pattern is closer to what you're suggesting. Among folks who know me, I've got a reputation for writing clean, optimized code. It isn't because I'm good at writing clean code; it's because I'm good at throwing away ugly code and I'm very reluctant to share code that doesn't meet the bar.
    - Pamar 7y ago
      Sorry to sound cynical but... have you ever been introduced to the concept of "deadline"?
      - jodrellblank 7y ago
        I really want a way to filter out comments which boil down to a snarky “SOME people can’t do this”. Yes yes, have points, well done, but it’s a boring low effort class of comments that applies to nigh every single idea ever, and skips the interesting or important bits - in this case whether it produces better software or helps understand things - in favour of a cheap vote grab. “It’s not universally applicable” - no, nothing is. and you don’t sound cynical you sound like you’re trying to dismiss and status grab, like someone talking about the “out here in the real world”.
        Pamar 7y ago
nemaar 7y ago
I really believe this is the only way you can write good software. It's mind blowing to me that most people try to "figure out" the problems before seeing what it actually is. I always feel strange when someone is writing a "study" by reading the documentation of some API or even worse, by reading someone's feature request. The writer of a feature request usually knows even less about the whole thing and really did not think things through. We need tools and programming languages where you can create really dirty but working solutions and make it iteratively better. You need to find all the edge cases and pitfalls and for that you need to fail. Of course you need to fail fast, this method does not work if the iteration is slow and the thing is in production when you find out that it barely works.
- mike_hock 7y ago
  Where do I go to get paid to actually put in the TIME and effort required to produce something elegant and high quality?
  - nothrabannosir 7y ago
    As a contractor working on project basis, who can leverage this technique to produce code of such high quality that a commensurate price can be commanded. You’d need to find a niche that values this level of quality, but if that exists, and if the theory is true, then there’s your gold.
  - splittingTimes 7y ago
    Love to see that magical place. I come to think that the whole concept of MVP/prototype became a bane to software development when the management/business side got aware of its existence. Architecture and design sessions can be skipped because we just build a prototype. I have yet to see a prototype that did not end in production. It's "good enough software", let's move to the next feature. When you are really lucky you can revisit your prototype a year or two later and try to improve it's design now that you got some data on its actual usage, but you have to figure out again, what the heck you actually did...
dragonwriter 7y ago
> Not sure how to solve that particular problem though. I think it is less a problem to be solved than a fundamental trade-off that comes with the scale of systems: the more components a system is going to have, the greater the cost of not minimizing complexity of individual components.
oftenwrong 7y ago
"Plan to Throw One Away" is a classic bit of Fred Brooks advice. https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/planToThrowOneAway.html https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/plan...
olskool 7y ago
Knuth once wrote that you should plan to throw away the first version of any program because you will anyway.
- papln 7y ago
  That was Fred Brooks in The Mythical Man-Month

klyrs 7y ago

Neat. That's essentially how I program, too. Early history in some of my git repos has the pattern git add program ... ... #first implementation works; time to rewrite git add newprogram ... ... #second implementation works; bury the first git rm program; git mv newprogram program ... This keeps my directory relatively clean, as I only have my previous attempt and the current refactor around at any given time. It also keeps the git history clean for the living files, and keeps the diffs nice and tidy.

newnewpdro 7y ago
Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. It's preferable to work in branches and rewrite and refactor incrementally whenever possible, merging the new code in as things progress at convenient milestones. Then the history documents which functionalities in the old implementation became what files and lines in the new implementation. That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore.
- klyrs 7y ago
  > Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. That's the goal of this practice. Throw it all out and rewrite from scratch. > That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore. I'm talking about writing non-releases. The entire structure of the code, algorithms, data structures, API / CLI must not be preserved. Anything that stays constant between non-releases is either (a) a good idea or (b) a stone unturned. Rename variables, split and join modules, violently reorder function arguments... nothing is off-limits. After I've been through a few rounds of this, the first release should be entirely free of inessential warts (and maintenance is typically quite easy at this stage). After the first release, I'm a stickler about backwards-compatibility and my development pattern is closer to what you're suggesting. Among folks who know me, I've got a reputation for writing clean, optimized code. It isn't because I'm good at writing clean code; it's because I'm good at throwing away ugly code and I'm very reluctant to share code that doesn't meet the bar.
  - Pamar 7y ago
    Sorry to sound cynical but... have you ever been introduced to the concept of "deadline"?
    - jodrellblank 7y ago
      I really want a way to filter out comments which boil down to a snarky “SOME people can’t do this”. Yes yes, have points, well done, but it’s a boring low effort class of comments that applies to nigh every single idea ever, and skips the interesting or important bits - in this case whether it produces better software or helps understand things - in favour of a cheap vote grab. “It’s not universally applicable” - no, nothing is. and you don’t sound cynical you sound like you’re trying to dismiss and status grab, like someone talking about the “out here in the real world”.
      - Pamar 7y ago

nemaar 7y ago

I really believe this is the only way you can write good software. It's mind blowing to me that most people try to "figure out" the problems before seeing what it actually is. I always feel strange when someone is writing a "study" by reading the documentation of some API or even worse, by reading someone's feature request. The writer of a feature request usually knows even less about the whole thing and really did not think things through. We need tools and programming languages where you can create really dirty but working solutions and make it iteratively better. You need to find all the edge cases and pitfalls and for that you need to fail. Of course you need to fail fast, this method does not work if the iteration is slow and the thing is in production when you find out that it barely works.

mike_hock 7y ago
Where do I go to get paid to actually put in the TIME and effort required to produce something elegant and high quality?
- nothrabannosir 7y ago
  As a contractor working on project basis, who can leverage this technique to produce code of such high quality that a commensurate price can be commanded. You’d need to find a niche that values this level of quality, but if that exists, and if the theory is true, then there’s your gold.
- splittingTimes 7y ago
  Love to see that magical place. I come to think that the whole concept of MVP/prototype became a bane to software development when the management/business side got aware of its existence. Architecture and design sessions can be skipped because we just build a prototype. I have yet to see a prototype that did not end in production. It's "good enough software", let's move to the next feature. When you are really lucky you can revisit your prototype a year or two later and try to improve it's design now that you got some data on its actual usage, but you have to figure out again, what the heck you actually did...

dragonwriter 7y ago

> Not sure how to solve that particular problem though. I think it is less a problem to be solved than a fundamental trade-off that comes with the scale of systems: the more components a system is going to have, the greater the cost of not minimizing complexity of individual components.

oftenwrong 7y ago

"Plan to Throw One Away" is a classic bit of Fred Brooks advice. https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/planToThrowOneAway.html https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/plan...

olskool 7y ago

Knuth once wrote that you should plan to throw away the first version of any program because you will anyway.

papln 7y ago
That was Fred Brooks in The Mythical Man-Month