I believe programming, in this regard, can learn something from writing: when writing the first core of a new system, when the original creator is still alone, isolated, able to do anything, she should pretend that this first core is her only bullet. During the genesis of the system she should rewrite this primitive kernel again and again, in order to find the best possible design. My hypothesis is that this initial design will greatly inform what will happen later: growing organically something that has a good initial structure will result in a better system, even after years of distance from the original creation, and even if the original core was just a tiny faction of the future mass the system would eventually assume.
I thought this paragraph had an interesting point. Does anyone have experience with testing this hypothesis?
I can totally relate to that. That's how I arrived at Abstraction Logic [0]: Banging my head against the wall (no, not literally), until something gave and I could suddenly see the most simple and powerful logical kernel possible.
This kind of development must be carefully balanced though so that you don't forget why you are making your system in the first place. You need to resolve the tension between your user requirements and your simple kernel, and that's hard. It is maybe even impossible for the particular project you are working on, because of economic constraints, time constraints, or because you don't know enough.
Furthermore, the comparison here with writers is very apt: Following this style of development, you are becoming an artist, and you will probably experience the need to shape your work environment accordingly.
That section stood out to me too. I ended up doing this a few months back while working on the playback system in my video editor Recut. I ended up rewriting that system at least 5 times. I was also learning Rust at the same time, and I had little knowledge of video going in. So it was a loop like: build something, get it working, realize I designed myself into a corner and couldn’t handle some important scenario, go back to the drawing board.
Stuff like dealing with the threads and queues, playing streams from multiple files in sync when they have different frame rates, and managing playback of multiple tracks that each have lots of cuts were some of the things that tripped me up and led to redesigns.
It ended up being a good learning experience and I’m glad I spent the time to rewrite instead of trying to forge ahead with broken abstractions. It’s still not perfect but it’s miles ahead of those first few iterations.
I’ve always found that starting a new project works best when I build the baseline alone, after some design discussion. If it’s too complex a problem to build that way, the fewer and more focused the team, better the baseline is. Once you start adding more and more people to a system, things start going down hill in proportion to the number of parallel work streams. Of course, this depends on how “big” a problem you’re working on and how the problem can be broken down. (i.e divided areas of responsibility in the code base with clear contracts between them). It’s way too easy to lose focus on design philosophy and structure as more people are involved in the actual development/coding.
Comments
I thought this paragraph had an interesting point. Does anyone have experience with testing this hypothesis?
I can totally relate to that. That's how I arrived at Abstraction Logic [0]: Banging my head against the wall (no, not literally), until something gave and I could suddenly see the most simple and powerful logical kernel possible.
This kind of development must be carefully balanced though so that you don't forget why you are making your system in the first place. You need to resolve the tension between your user requirements and your simple kernel, and that's hard. It is maybe even impossible for the particular project you are working on, because of economic constraints, time constraints, or because you don't know enough.
Furthermore, the comparison here with writers is very apt: Following this style of development, you are becoming an artist, and you will probably experience the need to shape your work environment accordingly.
[0]: https://obua.com/publications/philosophy-of-abstraction-logi...
That section stood out to me too. I ended up doing this a few months back while working on the playback system in my video editor Recut. I ended up rewriting that system at least 5 times. I was also learning Rust at the same time, and I had little knowledge of video going in. So it was a loop like: build something, get it working, realize I designed myself into a corner and couldn’t handle some important scenario, go back to the drawing board.
Stuff like dealing with the threads and queues, playing streams from multiple files in sync when they have different frame rates, and managing playback of multiple tracks that each have lots of cuts were some of the things that tripped me up and led to redesigns.
It ended up being a good learning experience and I’m glad I spent the time to rewrite instead of trying to forge ahead with broken abstractions. It’s still not perfect but it’s miles ahead of those first few iterations.
I’ve always found that starting a new project works best when I build the baseline alone, after some design discussion. If it’s too complex a problem to build that way, the fewer and more focused the team, better the baseline is. Once you start adding more and more people to a system, things start going down hill in proportion to the number of parallel work streams. Of course, this depends on how “big” a problem you’re working on and how the problem can be broken down. (i.e divided areas of responsibility in the code base with clear contracts between them). It’s way too easy to lose focus on design philosophy and structure as more people are involved in the actual development/coding.
This is one of the foundational tenets of Extreme Programming
https://asana.com/resources/extreme-programming-xp
When following this process you should strictly adhere to TDD and constantly be refactoring/rewriting code