3 ms·

The way in which microservices, unix programs and extensible editors in this article are compared as if they are all attempts or at least examples of how to som

by vlz 3y ago

The way in which microservices, unix programs and extensible editors in this article are compared as if they are all attempts or at least examples of how to somehow "solve software architecture" is really rubbing me the wrong way. The author is speaking as if "How to organize software" is the nail and these things are all attempting to be hammers when they are really not. Would I want to build a world wide streaming service, I would probably need some custom microservices and I will not need some kind of plugin architecture for them. Would I want to build a slick editor that non-programmers can use for knowledge organization I will not wire something together with awk and gnuplot. If I want to quickly search some log files and sort and count the errors in them I will not look for an obsidian extension nor build a microservice. The question of how to architect such software is still an open one. I was happy about the clear thesis statement in the byline of the article: > Extensible programs like Obsidian have achieved a Holy Grail of software architecture, after decades of failed attempts However, by focusing on categories like "Applets", "Unix programs" or "microservices" the article in effect did barely touch the topic of software architecture and offered no evidence to support that byline.

grumblingdev 3y ago
> "How to organize software" I have recently had the thought that this is mostly what software architecture is...at some level. It's about where we draw the boundaries around code to make it easy for humans to understand. Imagine taking an existing repo, and extracting every block of code into a function, and then moving them into their own separate file in one big folder. You could extend it to all the libraries of your code, and of those services we communicate with over the network too. This would look a bit like a debugger symbol table. It's closer to how the computer understands the program. The app still runs. It's just hard for people to understand what is going on. Software architecture is simply the grouping of these functions to some extent. It's not a foolproof analogy, because there are some decisions to be made about implementation details of things, but at some level of abstraction you would find the same operations need to be run. Just an interesting thought. > The question of how to architect such software is still an open one. I find a problem we face with architecture discussions is that its always about tradeoffs that are not immediately apparent. And it takes a lot of mental effort to remember why something is a bad idea. The way we discuss it is limited by plain text. It's hard to demonstrate a system evolving over time in a concise manner. Architecture should be evaluated by throwing a spec at it, and then changing every part of the spec (including adding perf requirements) and seeing how long it takes to make the changes, and how many bugs it has.

by vlz 3y ago

grumblingdev 3y ago

> "How to organize software" I have recently had the thought that this is mostly what software architecture is...at some level. It's about where we draw the boundaries around code to make it easy for humans to understand. Imagine taking an existing repo, and extracting every block of code into a function, and then moving them into their own separate file in one big folder. You could extend it to all the libraries of your code, and of those services we communicate with over the network too. This would look a bit like a debugger symbol table. It's closer to how the computer understands the program. The app still runs. It's just hard for people to understand what is going on. Software architecture is simply the grouping of these functions to some extent. It's not a foolproof analogy, because there are some decisions to be made about implementation details of things, but at some level of abstraction you would find the same operations need to be run. Just an interesting thought. > The question of how to architect such software is still an open one. I find a problem we face with architecture discussions is that its always about tradeoffs that are not immediately apparent. And it takes a lot of mental effort to remember why something is a bad idea. The way we discuss it is limited by plain text. It's hard to demonstrate a system evolving over time in a concise manner. Architecture should be evaluated by throwing a spec at it, and then changing every part of the spec (including adding perf requirements) and seeing how long it takes to make the changes, and how many bugs it has.