Reusable Processes and Architecture - 2
2025. 08. 05.
I reflect on the skills I've gained while studying development. At first, I started by creating small functions. For example, implementing the addition function of a calculator in Python. The input and output are predetermined, and as long as these conditions are met, the implementation method doesn't matter. Since it only needs to work on my computer, I could focus solely on the code itself without worrying about the environment in which the code runs. But the moment I tried web service development or attempted to develop packages that could be used on other computers, I suddenly had to pay attention to the environment in which the code runs. Just because Python 3.13 is installed on my computer doesn't guarantee that other computers running this code will have the same version of Python installed. Some packages produce results that differ from the 10th decimal place between Windows and Linux environments, so code that runs without problems in a Windows environment might cause various bugs in a Linux environment when using such package functions. When encountering these problems, we realize that not only must the code run well, but we must also ensure consistency in the environment where the code runs, or implement it so that consistent results are produced even when running the code in multiple environments.
How can we maintain consistency in the environment where code runs? Tools like Python's venv or Node's npm help run code in environments where only necessary packages are installed. If we install packages one by one from scratch in a situation where no packages are installed, with versions specified, and then run the code, at least we won't encounter situations like "I developed a function using shapely version 2.1 on my computer, but another computer has shapely version 1.8 installed, so the code crashes while running." But the best approach would be to think that my code will run on a blank device with only an OS installed, after installing the necessary language first. For example, installing Python version 3.13 on a freshly formatted Windows computer, installing specific versions of packages needed to run my Python code, and then running the code I wrote. What developers call Docker roughly does this kind of work. Installing only what's necessary in a blank environment to run my code. But without formatting.
What I want to argue through this article is that a developer's capability should be viewed as encompassing not only feature development but also managing the environment in which the developed features can run. This is where the main point begins: what I'm interested in observing is why this obvious topic might seem unfamiliar to architects studying development, or computational designers. Let's say you implemented a function to create some form using Grasshopper. The following often happens afterward:
- A friend showed interest in the function I created, so I sent them the Grasshopper file I made, but something... something appears as missing and it doesn't work.
- I saved the Grasshopper file on an external hard drive and later opened it again to recreate images for my portfolio, but again it doesn't work due to some problem.
It's maddening that a function I worked hard to create only works on my computer at the exact moment I created this function. I think the following problems arise from this:
- Computational designers work without assuming that the functions they implement will be reused by someone else. If they're working while thinking that even they themselves might not be able to reuse the functions they created later, how can they have time to care about reusability?
- Since they don't care about reusability, the scope of work is limited to specific projects or specific situations. There's a tendency to avoid large-scale work like solving problems for general situations.
- Because everyone doesn't care about reusability, countless people repeatedly re-implement the same functions (reinventing the wheel). This slows down the development speed of the entire industry.
Of course, there are computational designers in this world who develop plugins, and I believe they are people who have escaped from the above problems. But not everyone develops plugins. There must be a kind of culture or tendency established in the industry due to people with the above problems, and I want to say that these elements hinder the industry's development. In other words, computational designers learning development only superficially and claiming that they "can do development" interferes with bringing and applying the essentials that have been earnestly developed in the developer's world to the industry.
On the other hand, I also think there are the following reasons why people don't feel much inconvenience despite these problems:
- Projects in architecture are usually difficult to scale. It's hard to take a function created in one place and use it as-is in another place. Unlike expecting that devices where servers will be installed will all follow similar specifications, the land where architecture is built is all different, the forms of buildings that go on the land are all different, and there's a culture in architecture that creates value by not generalizing land and building forms.
- Since scaling is difficult, there might be no need to think about scaling from the beginning. So, they create functions for one-time use from the start, apply them only to that project, and then like playing a roguelike game, they only gain experience and implement new functions for other projects later.