3 ms·

Well, maybe the good thing here is that at some point someone will notice that the specific gateway code can be extracted and then refactored? Idk there's proba

Well, maybe the good thing here is that at some point someone will notice that the specific gateway code can be extracted and then refactored? Idk there's probably a reason why they decided to do this, the most common answer I've gotten is, product requires feature out tomorrow. How does one reconcile this problem of competing priorities that aren't actually sized right (ie. short term feature development versus long term code health?)

Jtsummers 7y ago
You have to get management and customer support, and that's the hard part. They have to understand the idea of the capability trap [0][1]. A lack of maintenance is inviting disaster, this is true across domains. Software is cheap, though, and usually doesn't have terrible consequences (see the notable exceptions like Therac-25 or 737 Max). Who cares if your IM client is a POS, it's not going to cost lives. And even if it is junk, we can buy a new one (MS) or build a 17th one (Google). The way around this, and again you have to get management and customer support, is to bring maintenance activities into every iteration. Create systems that can detect issues and errors early (more comprehensive testing, new testing styles like fuzzing and property-based testings; moving critical portions to statically typed languages or adding type annotations; etc.). Make addressing those issues a priority, some portion of your time in each iteration should be spent addressing concerns or increasing the ability to detect issues. Over time, when I've seen this done, it's made making changes much faster, even for larger changes. But without this, even "trivial" changes can end up taking months, instead of days or weeks. [0] https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.... [1] https://www.systemdynamics.org/assets/conferences/2017/proceed/papers/P1325.pdf https://www.systemdynamics.org/assets/conferences/2017/proce...
- vikiomega9 7y ago
  Some what of a random question, how did you find [0] and [1]?
  - Jtsummers 7y ago
    I don’t recall now. I’d heard of Sterman from various other readings on business and system dynamics and a recommendation from here. I can’t recall now if I found these papers from googling his name or a recommendation from my sister. I think she’s the one that gave me the phrase “capability trap” and Google found these and other articles.
    - vikiomega9 7y ago
      Awesome thank you, I was just trying to figure what the current state of your mental model on the subject is :)
SideburnsOfDoom 7y ago
> the specific gateway code can be extracted and then refactored? I In this case it's generally an attractive nuisance for business logic, aggregation, data transformation etc, which means that after a while 1) extracting the proxying is hard and 2) you can't understand a service without reading the code in multiple layers, since some of it's business logic is in the proxy layer. Big balls of mud can be big, distributed balls of mud.

Jtsummers 7y ago

You have to get management and customer support, and that's the hard part. They have to understand the idea of the capability trap [0][1]. A lack of maintenance is inviting disaster, this is true across domains. Software is cheap, though, and usually doesn't have terrible consequences (see the notable exceptions like Therac-25 or 737 Max). Who cares if your IM client is a POS, it's not going to cost lives. And even if it is junk, we can buy a new one (MS) or build a 17th one (Google). The way around this, and again you have to get management and customer support, is to bring maintenance activities into every iteration. Create systems that can detect issues and errors early (more comprehensive testing, new testing styles like fuzzing and property-based testings; moving critical portions to statically typed languages or adding type annotations; etc.). Make addressing those issues a priority, some portion of your time in each iteration should be spent addressing concerns or increasing the ability to detect issues. Over time, when I've seen this done, it's made making changes much faster, even for larger changes. But without this, even "trivial" changes can end up taking months, instead of days or weeks. [0] https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.... [1] https://www.systemdynamics.org/assets/conferences/2017/proceed/papers/P1325.pdf https://www.systemdynamics.org/assets/conferences/2017/proce...

vikiomega9 7y ago
Some what of a random question, how did you find [0] and [1]?
- Jtsummers 7y ago
  I don’t recall now. I’d heard of Sterman from various other readings on business and system dynamics and a recommendation from here. I can’t recall now if I found these papers from googling his name or a recommendation from my sister. I think she’s the one that gave me the phrase “capability trap” and Google found these and other articles.
  - vikiomega9 7y ago
    Awesome thank you, I was just trying to figure what the current state of your mental model on the subject is :)

SideburnsOfDoom 7y ago

> the specific gateway code can be extracted and then refactored? I In this case it's generally an attractive nuisance for business logic, aggregation, data transformation etc, which means that after a while 1) extracting the proxying is hard and 2) you can't understand a service without reading the code in multiple layers, since some of it's business logic is in the proxy layer. Big balls of mud can be big, distributed balls of mud.