5 ms·

> Code is only hard to figure out if you don't understand the business goals. Ah right, so when an architecture astronaut picks up the GoF Design Patterns book

> Code is only hard to figure out if you don't understand the business goals. Ah right, so when an architecture astronaut picks up the GoF Design Patterns book and creates a rube goldberg architecture with an interface for every. single. class., it's not going to be understandable because folks didn't understand the business goals.

randomdata 4y ago
Agreed. It's not terribly hard to think like the person who wrote it, even if they went rube-goldbergesq, if you understand where they were coming from. If the business details have been lost, it becomes harder.
- fuckstick 4y ago
  I think who you’re replying to is being sarcastic (a clue is using a pejorative - “architecture astronaut”). FWIW, I agree with their sentiment and disagree with yours.
  - randomdata 4y ago
    Yes, exactly. Even architecture astronauts are well intentioned, and if you understand the conditions under which they worked then it is quite easy to follow what they've done. It only becomes difficult when that context is lost. So hopefully they've encoded that context in tests. Worst case, if you never learned how to read code, you can throw the implementation away and the intention will remain validatable. But if you don't have the business end of the code documented... Good luck!
    - fuckstick 4y ago
      > Yes, exactly. Even architecture astronauts are well intentioned, and if you understand the conditions under which they worked then it is quite easy to follow what they've done. It only becomes difficult when that context is lost. I posit you lack either the experience of the imagination if you think "business context" is the only factor in the development of an unmaintainable mess.
- halostatue 4y ago
  Usually, when an architecture astronaut gets involved, the business details are immediately lost in the overwhelming slop of what has been built. And usually, the people having to deal with this crap are ones who have never dealt with the system in the first place, and the business people and the technical people are both gone from the company…
bitwize 4y ago
An interface for every single class doesn't really come from GoF, it's the D in SOLID -- this idea that classes must never depend on each other but on interfaces representing other classes.
- Supermancho 4y ago
  On a tangent...a pervasive problem in programming language syntax is the confusion afforded by Class Access Modifiers (public, protected, private, et al), aka CAMs. In some languages, these are foremost used as mixin selectors (inheritance, traits, or other composition). They are commonly overloaded to describe the object's interface. I am not the only who to have seen objects inherit from other objects, with the derived class consisting of new CAMs to provide the proper interface (in lieu of some dedicated Interface class, like in Java). Then there's a third concern about testability and how to reach methods like private and protected. If language syntax supported these different concerns with different mechanisms (notably Python and Go have made some headway for enabling testability) including a formal definition of an interface outside of CAM-mixin selection, it would make developer's lives a lot easier and quell many of the conflicting opinions about implementation dogma.

randomdata 4y ago

Agreed. It's not terribly hard to think like the person who wrote it, even if they went rube-goldbergesq, if you understand where they were coming from. If the business details have been lost, it becomes harder.

fuckstick 4y ago
I think who you’re replying to is being sarcastic (a clue is using a pejorative - “architecture astronaut”). FWIW, I agree with their sentiment and disagree with yours.
- randomdata 4y ago
  Yes, exactly. Even architecture astronauts are well intentioned, and if you understand the conditions under which they worked then it is quite easy to follow what they've done. It only becomes difficult when that context is lost. So hopefully they've encoded that context in tests. Worst case, if you never learned how to read code, you can throw the implementation away and the intention will remain validatable. But if you don't have the business end of the code documented... Good luck!
  - fuckstick 4y ago
    > Yes, exactly. Even architecture astronauts are well intentioned, and if you understand the conditions under which they worked then it is quite easy to follow what they've done. It only becomes difficult when that context is lost. I posit you lack either the experience of the imagination if you think "business context" is the only factor in the development of an unmaintainable mess.
halostatue 4y ago
Usually, when an architecture astronaut gets involved, the business details are immediately lost in the overwhelming slop of what has been built. And usually, the people having to deal with this crap are ones who have never dealt with the system in the first place, and the business people and the technical people are both gone from the company…

bitwize 4y ago

An interface for every single class doesn't really come from GoF, it's the D in SOLID -- this idea that classes must never depend on each other but on interfaces representing other classes.

Supermancho 4y ago
On a tangent...a pervasive problem in programming language syntax is the confusion afforded by Class Access Modifiers (public, protected, private, et al), aka CAMs. In some languages, these are foremost used as mixin selectors (inheritance, traits, or other composition). They are commonly overloaded to describe the object's interface. I am not the only who to have seen objects inherit from other objects, with the derived class consisting of new CAMs to provide the proper interface (in lieu of some dedicated Interface class, like in Java). Then there's a third concern about testability and how to reach methods like private and protected. If language syntax supported these different concerns with different mechanisms (notably Python and Go have made some headway for enabling testability) including a formal definition of an interface outside of CAM-mixin selection, it would make developer's lives a lot easier and quell many of the conflicting opinions about implementation dogma.