3 ms·

Keep Your Experiments Separate

30 points by zdw 4y ago

eddd-ddde 4y ago
I like the concept, but at some point, those features will have to come together. By creating completely different timelines, bringing them together gets harder as harder as each of those progress in time. By using a single timeline, where features slowly come together while not being complete, you can see how they interact together since the beginning, which might be crucial to their development. I think the ideal is a mixture of both strategies, a single timeline where working increments are added, and different timelines that exist only to work on small changes that are eventually joined (even if not complete! they just need to "work").
eternityforest 4y ago
I do exactly the opposite of this. The stuff I work on is mostly trivial except for the complexity and feature interaction involved in real apps. At most, there might be one or two interesting problems that can be isolated... but usually not. If I'm learning a new framework, all the features individually are a 10 minute google search. I'll forget how to use them, but IDE autocomplete will remind me. I'm not that interested in memorizing 1000 function signatures. I'll learn them in a year of actually using them, if I in fact actually ever use them. What I'm interested in is how you manage complexity with that framework, and I want to be sure I exercise all the features you only need in larger apps. I could see keeping experiments separate as being good if you are trying to learn how to build small software. If you plan to do microservices, or you work on a lot of interesting problems that aren't just assembling trivial things, or you just enjoy small and light things.
nelsonic 4y ago
100% the scientific method. Try to isolate variables as much as possible to test them independently then increase complexity as required.
swah 4y ago
You can also merge the code, add a feature flag system so that each feature is optional. Complexity goes up a little bit with all those checks, but almost always worth it...
- onetom 4y ago
  That is something you would do after you made your experiment. The point of the article’s advice is to avoid feature interaction.
ysavir 4y ago
Couldn't this be done using git branches? A fork seems like a way to unnecessarily complicate the process of eventually merging things. I guess if the goal is strictly learning and experimenting, forking makes sense. But that requires an expectation from the start that the project will be scrapped at some point. That each version exists as an exercise and will be discarded afterwards. And that can be a great way to learn; I don't mean to sound like I'm discouraging the idea. But if there's any intention or hope of making something bigger than the sum of its parts, utilizing it yourself in the future or intending to provide it to others, a flow where you can keep things separate but also bring them together with ease seems more optimal. But I guess learning that will be a forked experience its own right.
- ReactiveJelly 4y ago
  Yeah branching would be better. I think GitHub internally handles forks as branches anyway. I don't know the author or Eric, but I'm speculating they are hobby game devs using Unity and GitHub and they're not very experienced with Git. It may be that Eric wants the projects in separate folders without using `git checkout` to switch between them. But you can do that more easily by cloning the repo within your own system.
  - onetom 4y ago
    Both the author and Eric Evans are extremely experienced programmers. Forking is to be understood conceptually, not as a terminology of any specific version control system. As in a git branch represents a fork in the time-line of the evolution of a code-base. It just happens to be that fork also means something more specific in case of the GitHub/GitLab online services.
teknopaul 4y ago
"make one to throw away" is important to grok. Don't base code on something you are going to throw away, stems logically from actually believing that you are "making one to throw away". "make one with decent tests" is the next lesson to grok. If you are going to throw it away, you will benefit from the tests immediately.
w4ffl35 4y ago
Isn't this just describing iterative development with forks instead of branches?
- onetom 4y ago
  As I understood, fork was just meant conceptually, not as a GitHub/GitLab fork. A git branch is a fork in the timeline of a codebase. The point of the article is avoiding feature interaction. Try to implement a feature first on top of a smaller feature set first, just so you can learn about the problem domain and the solution space. After that, integrating such a feature on top of a more complete application should be significantly easier.
togaen 4y ago
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/...

30 points by zdw 4y ago

I like the concept, but at some point, those features will have to come together. By creating completely different timelines, bringing them together gets harder as harder as each of those progress in time. By using a single timeline, where features slowly come together while not being complete, you can see how they interact together since the beginning, which might be crucial to their development. I think the ideal is a mixture of both strategies, a single timeline where working increments are added, and different timelines that exist only to work on small changes that are eventually joined (even if not complete! they just need to "work").

eternityforest 4y ago

I do exactly the opposite of this. The stuff I work on is mostly trivial except for the complexity and feature interaction involved in real apps. At most, there might be one or two interesting problems that can be isolated... but usually not. If I'm learning a new framework, all the features individually are a 10 minute google search. I'll forget how to use them, but IDE autocomplete will remind me. I'm not that interested in memorizing 1000 function signatures. I'll learn them in a year of actually using them, if I in fact actually ever use them. What I'm interested in is how you manage complexity with that framework, and I want to be sure I exercise all the features you only need in larger apps. I could see keeping experiments separate as being good if you are trying to learn how to build small software. If you plan to do microservices, or you work on a lot of interesting problems that aren't just assembling trivial things, or you just enjoy small and light things.

nelsonic 4y ago

100% the scientific method. Try to isolate variables as much as possible to test them independently then increase complexity as required.

swah 4y ago

You can also merge the code, add a feature flag system so that each feature is optional. Complexity goes up a little bit with all those checks, but almost always worth it...

onetom 4y ago
That is something you would do after you made your experiment. The point of the article’s advice is to avoid feature interaction.

ysavir 4y ago

Couldn't this be done using git branches? A fork seems like a way to unnecessarily complicate the process of eventually merging things. I guess if the goal is strictly learning and experimenting, forking makes sense. But that requires an expectation from the start that the project will be scrapped at some point. That each version exists as an exercise and will be discarded afterwards. And that can be a great way to learn; I don't mean to sound like I'm discouraging the idea. But if there's any intention or hope of making something bigger than the sum of its parts, utilizing it yourself in the future or intending to provide it to others, a flow where you can keep things separate but also bring them together with ease seems more optimal. But I guess learning that will be a forked experience its own right.

ReactiveJelly 4y ago
Yeah branching would be better. I think GitHub internally handles forks as branches anyway. I don't know the author or Eric, but I'm speculating they are hobby game devs using Unity and GitHub and they're not very experienced with Git. It may be that Eric wants the projects in separate folders without using `git checkout` to switch between them. But you can do that more easily by cloning the repo within your own system.
- onetom 4y ago
  Both the author and Eric Evans are extremely experienced programmers. Forking is to be understood conceptually, not as a terminology of any specific version control system. As in a git branch represents a fork in the time-line of the evolution of a code-base. It just happens to be that fork also means something more specific in case of the GitHub/GitLab online services.

teknopaul 4y ago

"make one to throw away" is important to grok. Don't base code on something you are going to throw away, stems logically from actually believing that you are "making one to throw away". "make one with decent tests" is the next lesson to grok. If you are going to throw it away, you will benefit from the tests immediately.

w4ffl35 4y ago

Isn't this just describing iterative development with forks instead of branches?

onetom 4y ago
As I understood, fork was just meant conceptually, not as a GitHub/GitLab fork. A git branch is a fork in the timeline of a codebase. The point of the article is avoiding feature interaction. Try to implement a feature first on top of a smaller feature set first, just so you can learn about the problem domain and the solution space. After that, integrating such a feature on top of a more complete application should be significantly easier.

togaen 4y ago

https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/...