4 ms·

Very good list in general, but I would disagree with one point: > Software architecture probably matters more than anything else The devil is in the details h

by skohan 6y ago

Very good list in general, but I would disagree with one point: > Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful. The architecture driven approach takes the assumption that the "correct" shape of a program should fit into a pre-defined abstraction, like MVP, MVVM (or god forbid atrocities like VIPER) etc which has been delivered to us on a golden tablet, and our job as programers is to figure out how to map our problem onto that structure. In my experience, the better approach is almost always to identify your inputs and desired outputs, and to build up abstractions as needed, on a "just-in-time" basis. The other approach almost always leads to unnecessary complexity, and fighting with abstractions. The author also mentions SOLID - like architecture patterns, I'm always a bit suspect of true-isms about what makes good software, especially when they come in the form of acronyms. I generally agree that the principals in SOLID are sensible considerations to keep in mind when making software, but for instance is the Liskov Substitution Principal really one of the five most important principals for software design, or is it in there because they needed something starting with "L"? After 10 years of programming, the biggest takeaway for me has been that the function of a program (correctness, performance) is degrees of magnitude more important than its form. "Code quality" is important to the extent that it helps you get to a better functioning program (which can be quite a bit) but that's where its utility ends. Obsessing over design patterns and chasing acronyms is great if you want to spend most of your time debating with colleages about how the source code should look, but the benefits are just not reality-based most of the time.

AnimalMuppet 6y ago
So you don't think architecture matters that much, but you've felt the pain of having one that doesn't fit forced on you? That seems... kind of unaware of you. Just-in-time architecture is a perfectly valid approach to developing an architecture. The point is to develop one that is a good match to the problem. If you don't have that, you suffer - and that's the point of what you quoted.
- skohan 6y ago
  I think this is a bit of a stretch. The assertion I took issue with is that "Software architecture probably matters more than anything else". Yes if you want to deconstruct the term to the point of absurdity, and say that whatever shape your program ends up in implies some "software architecture" then you can say architecture is always relevant, but I would consider it a stretch to say this means it's also the number-1 priority in software development. If you read my comment, you would see that I'm arguing that software results, and software development as a process matter much more than thinking about architecture. I would also argue that every time the term "architecture" came up in a professional discussion over the past several years, this was a sign we were going down the wrong path.

by skohan 6y ago

AnimalMuppet 6y ago

So you don't think architecture matters that much, but you've felt the pain of having one that doesn't fit forced on you? That seems... kind of unaware of you. Just-in-time architecture is a perfectly valid approach to developing an architecture. The point is to develop one that is a good match to the problem. If you don't have that, you suffer - and that's the point of what you quoted.

skohan 6y ago
I think this is a bit of a stretch. The assertion I took issue with is that "Software architecture probably matters more than anything else". Yes if you want to deconstruct the term to the point of absurdity, and say that whatever shape your program ends up in implies some "software architecture" then you can say architecture is always relevant, but I would consider it a stretch to say this means it's also the number-1 priority in software development. If you read my comment, you would see that I'm arguing that software results, and software development as a process matter much more than thinking about architecture. I would also argue that every time the term "architecture" came up in a professional discussion over the past several years, this was a sign we were going down the wrong path.