When being serious about Compositional Software Design (designing your code base for composability) - you will often experience these two phenomena impact your code base size: 1) Decompositional Expansion 2) Compositional Contraction First, your code base will expand because you are breaking your code base into many smaller pieces that can be composed together to form solutions. This phenomenon (phase) is what I call the "Decompositional Expansion". Later, your code base will feel like it contracts, meaning it does not grow as fast in size anymore as it did in the beginning. It feels like you can add new functionality with little code (and little effort). This phenomenon (phase) is what I call the "Compositional Contraction". During this phase you are starting to reap the benefits of all those reusable components you created during the Decompositional Expansion. Have you experienced these two phenomena in your code base size growth? ☺️ I am covering these phenomena in my upcoming video about Compositional Software Design ☺️ Seems like it will be one of my longest videos to date! 🫢 #CompositionalSoftwareDesign #CompositionalDesign #SoftwareDesign

I have started working on a video about Compositional Design - which is about breaking your codebase into smaller pieces designed to be composed together to form larger solutions to a variety of similar problems. The focus of compositional design is on how to split your units up into smaller units that are composable. While these splits may sometimes end up forming design patterns - the design pattern itself is not the goal of the split - but a natural consequence of why you make that split in the first place. This is the first video in my software design series that gets really concrete about how I like to design software internally. The previous videos have been more abstract. You can find the previous videos in this series here, by the way: youtube.com/playlist?list=PL… This video will probably be my longest video so far - because there is a lot to talk about. Thus it will take some time to finish it too. #SoftwareDesign #SoftwareDevelopment #SoftwareEngineering #CompositionalDesign #ConsciousSoftwareDesign

Just finished reading Clean Code. My immediate impression is that it is not one of the most useful books on software design I have read. The problem I have with books like Refactoring, Design Patterns and Clean Code is, that they tend to be a list of solutions for you to memorize - but what I want to learn as a developer is how to arrive at these solutions on my own. Reading such books feel like learning math by memorizing the solutions to lots of math problems, rather than learning how to solve math problems in general. In other words, I want to learn "Design Thinking" - not memorize "Design Solutions". Of course you can learn some level of design thinking by studying design solutions - but you do so retroactively. You might discover what the design thinking behind a solution was, and be able to reuse that reasoning in another situation. But - I would prefer to be taught the design thinking (reasoning) explicitly - and then discover what solutions that thinking leads to when applied. This is what I am trying to address with my ideas of Conscious Software Design and Compositional Design. Another issue with these older books is, that they tend to talk in terms of "right" and "wrong" - or "good" and "bad". It feels too much like there is always "one best solution". In practice, however, all design decisions are contextual trade-offs. No single design is always the best solution in all situations. Therefore, as a software designer I find it more useful to learn the reasoning that goes into coming up with different design solutions to the same problem in general - and to study the pros and cons of these solutions so I can make an educated judgement about what set of pros and cons best fit my current situation. #SoftwareDesign #SoftwareDevelopment #SoftwareEngineering #CleanCode #ConsciousSoftwareDesign #CompositionalDesign

Journal of the Alamire Foundation vol. 9/1 - 2017. #Motet Cycles (c. 1470-c. 1510): #CompositionalDesign, #Performance, and Cultural Context bit.ly/2kmHHoX #Music #HistoryOfMusic #Musicology @AMS_musicology