4 ms·

I think "better" is ambiguous. Better for developers? Better for users? Better for speed? Better for maintenance? Better license? Better software stack? B

by m463 2y ago

I think "better" is ambiguous. Better for developers? Better for users? Better for speed? Better for maintenance? Better license? Better software stack? Better telemetry? Better revenues through subscriptions?

throwAGIway 2y ago
At a business, all of these - a good engineer/architect has to find the right balance.
- tremon 2y ago
  Different engineers can have different interpretations of "right balance" -- and many of them may be correct. Which makes "better" again ambiguous.
  - throwAGIway 2y ago
    It's not ambiguous, it's a collective decision between engineers and business stakeholders. The ambiguousness comes from engineers not having full information.
  - prerok 2y ago
    I think this is actually addressed in the article: > The key question for the designer is, “What would the system’s structure need to be so that <some feature> would be no harder to implement than necessary?” (It’s a bit surprising when designers don’t ask this question, instead simply asking, “What should the design look like?”—for what purpose?) During my career, I have been in many situations where the SW architects tried to answer the second question: as if the architectural cleanliness was the goal unto itself. Software design patterns were misused, unneeded abstractions abounded everywhere, class hierarchies were created 15+ levels deep. There it was often brought up which is better and nicer and cleaner because the metric was aestetics. Most of those arguments, however, are quickly brought to a stop, if we are actually asking the first question: how hard is it to add these new features? That said, I was frequently unable to convince coworkers in my past employments, that aestetics of the design is not the goal. They simply clung to it, to somewhat religious extent, identifying themselves with their "artwork".
    - rqtwteye 2y ago
      I have concluded that smaller is better and straightforward is better. I think it’s easier to scale up a small system than to maintain a complex system that was built for scale from the ground up but usually got some things wrong because the requirements at the time weren’t clear. But in the end there is never a clear answer. I am happy when people can explain what the positives and also the drawbacks of a design are. Pointing at “best practice” without explaining pros and cons is usually a big red flag.
      - prerok 2y ago
        Indeed, could not agree more. Also, using composition over inheritance is age old advice but that still did not prevent those architectural astronauts from creating inheritance structures 15+ levels deep. Luckily, newer languages make constructing such monstrosities harder and discouraged.
        throwAGIway 2y ago
        Just having a huge bikeshedding festival at work after I wrote this sentence into guidelines... The worst thing is how hard it is to talk about it because all the books - by authors making more money from talking about software than from writing and maintaining code - recommend it, and it's just so SOLID and Hexagonal and looks obviously intuitively correct.
        prerok 2y ago
        Can you elaborate, you have piqued my interest :) The sentence for preferring "composition over inheritance" for code reuse is in the book by the gang of four (the design patterns book). I really don't understand how we ended up in the situation, where 30 years old advice is still valid and still not followed. I lay, perhaps too much, blame on Java, which seems to have this baked into its infrastructure, but similar approaches have also been adopted in C++ with multiple inheritance making things even worse. I mean, SOLID, when used appropriately, is also valid. The problem is that the design patterns are used where a simpler solution would work just as well.
  - Aeolun 2y ago
    Ambiguous only in the sense that it doesn’t always mean exactly the same. The direction of better on a graph is always in the same direction though, even if the point isn’t at the same x,y coordinate.
- tamiral 2y ago
  I find the biggest issues in industry and organizations is so called “tech debt” and no plan for future improvement of a solution as it matures or user base scales. Planning for these is essential.
mfrankpb 2y ago
I would disagree with that. We have quality measures to assess what 'better' can mean in software engineering (e.g. maintainability, reliability, security, performance, etc.). You are right that it is not fixed what is most important. It may vary from one organization to another, but it can be conceptualized and then made measurable to some degree.
mx_03 2y ago
I dont think users care about sofwtare design. At most they might care about non funcional requirements (e.g. security and performance)

by m463 2y ago

throwAGIway 2y ago

At a business, all of these - a good engineer/architect has to find the right balance.

tremon 2y ago
Different engineers can have different interpretations of "right balance" -- and many of them may be correct. Which makes "better" again ambiguous.
- throwAGIway 2y ago
  It's not ambiguous, it's a collective decision between engineers and business stakeholders. The ambiguousness comes from engineers not having full information.
- prerok 2y ago
  I think this is actually addressed in the article: > The key question for the designer is, “What would the system’s structure need to be so that <some feature> would be no harder to implement than necessary?” (It’s a bit surprising when designers don’t ask this question, instead simply asking, “What should the design look like?”—for what purpose?) During my career, I have been in many situations where the SW architects tried to answer the second question: as if the architectural cleanliness was the goal unto itself. Software design patterns were misused, unneeded abstractions abounded everywhere, class hierarchies were created 15+ levels deep. There it was often brought up which is better and nicer and cleaner because the metric was aestetics. Most of those arguments, however, are quickly brought to a stop, if we are actually asking the first question: how hard is it to add these new features? That said, I was frequently unable to convince coworkers in my past employments, that aestetics of the design is not the goal. They simply clung to it, to somewhat religious extent, identifying themselves with their "artwork".
  - rqtwteye 2y ago
    I have concluded that smaller is better and straightforward is better. I think it’s easier to scale up a small system than to maintain a complex system that was built for scale from the ground up but usually got some things wrong because the requirements at the time weren’t clear. But in the end there is never a clear answer. I am happy when people can explain what the positives and also the drawbacks of a design are. Pointing at “best practice” without explaining pros and cons is usually a big red flag.
    - prerok 2y ago
      Indeed, could not agree more. Also, using composition over inheritance is age old advice but that still did not prevent those architectural astronauts from creating inheritance structures 15+ levels deep. Luckily, newer languages make constructing such monstrosities harder and discouraged.
      - throwAGIway 2y ago
        Just having a huge bikeshedding festival at work after I wrote this sentence into guidelines... The worst thing is how hard it is to talk about it because all the books - by authors making more money from talking about software than from writing and maintaining code - recommend it, and it's just so SOLID and Hexagonal and looks obviously intuitively correct.
        prerok 2y ago
        Can you elaborate, you have piqued my interest :) The sentence for preferring "composition over inheritance" for code reuse is in the book by the gang of four (the design patterns book). I really don't understand how we ended up in the situation, where 30 years old advice is still valid and still not followed. I lay, perhaps too much, blame on Java, which seems to have this baked into its infrastructure, but similar approaches have also been adopted in C++ with multiple inheritance making things even worse. I mean, SOLID, when used appropriately, is also valid. The problem is that the design patterns are used where a simpler solution would work just as well.
- Aeolun 2y ago
  Ambiguous only in the sense that it doesn’t always mean exactly the same. The direction of better on a graph is always in the same direction though, even if the point isn’t at the same x,y coordinate.
tamiral 2y ago
I find the biggest issues in industry and organizations is so called “tech debt” and no plan for future improvement of a solution as it matures or user base scales. Planning for these is essential.

mfrankpb 2y ago

I would disagree with that. We have quality measures to assess what 'better' can mean in software engineering (e.g. maintainability, reliability, security, performance, etc.). You are right that it is not fixed what is most important. It may vary from one organization to another, but it can be conceptualized and then made measurable to some degree.

mx_03 2y ago

I dont think users care about sofwtare design. At most they might care about non funcional requirements (e.g. security and performance)