4 ms·

I've gone back and forth on fat models vs service issues myself - I've landed on a bit of both in the end, but it's made harder by DRF not really recommending t

by mands 5y ago

I've gone back and forth on fat models vs service issues myself - I've landed on a bit of both in the end, but it's made harder by DRF not really recommending the fat model approach (with respect to validation).

travisjungroth 5y ago
Isn't it amazing we're still all poking around how to best represent business logic in software when this has been the whole damn point of what we're doing for the last 30 years at least? We got pretty good at the pure computing stuff pretty quick, but like hell we can all agree on how to represent that a food purchase over $100 by a user in Wyoming needs a 5% tax added.
- Daishiman 5y ago
  The problem is that different levels of granularity imply enormous differences in representation. If you operate in a single jurisdiction and sell just a coupld of SKUs, handling tax can be a 20-line affair. On the other end you have SAP multi-million line ERPs that handle tax as far as the eye can see and you need literal specialists just for that.
- lifeisstillgood 5y ago
  Yes. That has touched on something deeply important. I wish i knew what :-) My 2c is "software literacy". We live in a literate world so we all more or less can read the sentence "food purchase over $100 by a user in Wyoming needs a 5% tax added." and understand it. But 98% of people could not scan the same in C, C++, Python etc. And 98% of those of us that could wont understand the context the code sits in (whats the variable name 'WY_TAX_PCAGE'?)
  - mdtusz 5y ago
    I think your comment emphasises the importance of good function and variable naming. I've read some incredibly clear and obvious C code and some incredibly hard to understand Python code that both do the same thing - it basically all comes down to the naming choices used. `TAX_RATE_WY` would be far easier to understand and maintain (especially when seeing other state abbreviation suffixes nearby) and has the added benefit of using the same `TAX_RATE_` prefix for _all_ similar values so is much easier to pick up on when scanning through the code. The science of reading and literacy would likely be a very valuable course to teach in CS programs.
  - kimsia 5y ago
    How many times can I upvote this about software literacy?
- mands 5y ago
  Yep, it feels like a corollary to bike-shedding, the business logic case, but I think you've described it better than me!

by mands 5y ago

travisjungroth 5y ago

Isn't it amazing we're still all poking around how to best represent business logic in software when this has been the whole damn point of what we're doing for the last 30 years at least? We got pretty good at the pure computing stuff pretty quick, but like hell we can all agree on how to represent that a food purchase over $100 by a user in Wyoming needs a 5% tax added.

Daishiman 5y ago
The problem is that different levels of granularity imply enormous differences in representation. If you operate in a single jurisdiction and sell just a coupld of SKUs, handling tax can be a 20-line affair. On the other end you have SAP multi-million line ERPs that handle tax as far as the eye can see and you need literal specialists just for that.
lifeisstillgood 5y ago
Yes. That has touched on something deeply important. I wish i knew what :-) My 2c is "software literacy". We live in a literate world so we all more or less can read the sentence "food purchase over $100 by a user in Wyoming needs a 5% tax added." and understand it. But 98% of people could not scan the same in C, C++, Python etc. And 98% of those of us that could wont understand the context the code sits in (whats the variable name 'WY_TAX_PCAGE'?)
- mdtusz 5y ago
  I think your comment emphasises the importance of good function and variable naming. I've read some incredibly clear and obvious C code and some incredibly hard to understand Python code that both do the same thing - it basically all comes down to the naming choices used. `TAX_RATE_WY` would be far easier to understand and maintain (especially when seeing other state abbreviation suffixes nearby) and has the added benefit of using the same `TAX_RATE_` prefix for _all_ similar values so is much easier to pick up on when scanning through the code. The science of reading and literacy would likely be a very valuable course to teach in CS programs.
- kimsia 5y ago
  How many times can I upvote this about software literacy?
mands 5y ago
Yep, it feels like a corollary to bike-shedding, the business logic case, but I think you've described it better than me!