3 ms·

Two things I've learned over 30 years of programming, but mostly the political landscape of software engineering in general are: 1. The code the is used to imp

Two things I've learned over 30 years of programming, but mostly the political landscape of software engineering in general are: 1. The code the is used to implement languages or the main "library" of said languages and your code to implement products don't have to and probably should NOT mirror each other. Other ways to think about it: Just because Java standard library has a generic List -> LinkedList or ArrayList etc..., doesn't mean your software related to managing Patients does NOT mean you need this complication: Human <- BillablePerson <- Patient (this is somewhat whacky). I often see developers do things like this because its "a best practice" and maybe there's a 1% of your code that will take advantage of something like that. In reality it makes a lot more sense to just generate a Bill and send it to an Patient. Whether they are a BillablePerson or not doesn't really matter. Anyone opening the user interface can see a payment screen, right? You can flip the status on a Bill to paid, right? Yes the pedants will come running. And yes if you're app is a framework for medical billing software (you're not a billing company but a company that makes billing frameworks) _maybe_ this is useful? But my answer to that is - even in that case, more and more we're outsourcing screens and concepts to other cloud systems. The concept of polymorphism is neat to iterate a LinkedList and an ArrayList, but it's not buying much for an invoice that gets paid in freshbooks and a patient managed in some EHR software. So as much as it's nice to "wrap all the things" the software we write is increasingly outsourced to yet another API call. Last two companies I worked at the config.json file was 50 lines, almost 90% of which is API tokens to various cloud SaaS vendors that take care of billing or email or storage or uploads. Wrap all the things? It's just not feasible anymore. 2. Second thing I've learned: Don't react to Everything. Have a bad deployment? Have some requirements that were lost? You can definitely implement a process or two especially for repeating issues. But don't react to everything. If you make a new policy or process or 2-step program for any frown you generate, you'll never get back to coding up the solution. You'll drag your software developers through red tape.

commandlinefan 3y ago
> does NOT mean you need this complication: > Human <- BillablePerson <- Patient (this is somewhat whacky). Whenever I see something like this I push the implementor to point me to some code that accepts a "Human" as a parameter and actually does something with it (other than casting it down to Patient). If they can't, I try to encourage them to drop the unneeded hierarchy.
- zwieback 3y ago
  Unless Human already existed and you want to inherit the functionality without retyping stuff or delegating. I think that's where the old "prefer delegation over inheritance" advice comes in but I'm not against convenience-inheritance.
  - commandlinefan 3y ago
    Right - in which case, Human must already be used (by itself) somewhere else.
zwieback 3y ago
> Other ways to think about it: Just because Java standard library has a generic List -> LinkedList or ArrayList etc..., doesn't mean your software related to > managing Patients does NOT mean you need this complication: > Human <- BillablePerson <- Patient (this is somewhat whacky). Also: class hierarchies don't have to match real-life hierarchies. Often I find it more useful to implement hierarchies that make the program flow and algorithms work more smoothly and accept hierarchies that don't mirror anything in the physical world.
- bccdee 3y ago
  Yeah I think people get far too carried away with object ontology. You shouldn't be thinking of program objects as direct analogues for real-world things. At most, they're data which describes a real-world object, and like all data, you can arrange it however is most convenient. Normalize it, denormalize it, version it and make it immutable—whatever suits your needs best.

commandlinefan 3y ago

> does NOT mean you need this complication: > Human <- BillablePerson <- Patient (this is somewhat whacky). Whenever I see something like this I push the implementor to point me to some code that accepts a "Human" as a parameter and actually does something with it (other than casting it down to Patient). If they can't, I try to encourage them to drop the unneeded hierarchy.

zwieback 3y ago
Unless Human already existed and you want to inherit the functionality without retyping stuff or delegating. I think that's where the old "prefer delegation over inheritance" advice comes in but I'm not against convenience-inheritance.
- commandlinefan 3y ago
  Right - in which case, Human must already be used (by itself) somewhere else.

zwieback 3y ago

> Other ways to think about it: Just because Java standard library has a generic List -> LinkedList or ArrayList etc..., doesn't mean your software related to > managing Patients does NOT mean you need this complication: > Human <- BillablePerson <- Patient (this is somewhat whacky). Also: class hierarchies don't have to match real-life hierarchies. Often I find it more useful to implement hierarchies that make the program flow and algorithms work more smoothly and accept hierarchies that don't mirror anything in the physical world.

bccdee 3y ago
Yeah I think people get far too carried away with object ontology. You shouldn't be thinking of program objects as direct analogues for real-world things. At most, they're data which describes a real-world object, and like all data, you can arrange it however is most convenient. Normalize it, denormalize it, version it and make it immutable—whatever suits your needs best.