4 ms·

Increasingly, I suspect the real value of type systems is that they force slower, "more correct" development, allowing you to "win the argument" with Management

Increasingly, I suspect the real value of type systems is that they force slower, "more correct" development, allowing you to "win the argument" with Management over taking the time to Do Things Right. They put a floor on code quality (albeit, IMHO, a pretty low one - you can also royally fuck up a type system) - preventing the worst excesses of rushed development.

Towaway69 3y ago
If your neighbour is using a type less language and is making more profit than you, then your boss will question the choice of language. Development pace is set by the competition. Edit: and if there is no competition, the longer it takes, the longer it will take to be profitable.
- Etheryte 3y ago
  This is a common misnomer, writing more code faster doesn't mean you get more product or value faster. It can look like it at first, but you'll quickly come to find you're actually producing more bugs and vulnerable surface faster instead. More code is not good, it's the opposite of what you want.
- RangerScience 3y ago
  This. This is the argument I'm exhausted having. Rushing development works for... maybe a week. After that, every time, it takes longer overall than if it'd been done "right" the first time. Like a desk, you get one layer of crap and clutter. More than that and everything begins to teeter and fall. That said - you definitely have to ask yourself (as a developer) or your engineers (as management) "is there a simpler way?". But "simpler" is not the same as "rushed", even if both are "faster" - it's just a question of "on what timeline". Faster today? This week? This month? This quarter? This year?
  - Towaway69 3y ago
    What's the old saying - nine pregnant people won't produce a child in one month. I think that comes from the Mythical Man Month but not sure. I think "faster" has been replaced by "profit". Is there a more profitable way of doing it. Etc. Hence things such as AI/CoPilot and the rest. We as developers have lost the craftsmanship that coding once was. Crafting a good bit of code that might just be a single line but which has elegance and conciseness to get the job done just right.

Towaway69 3y ago

If your neighbour is using a type less language and is making more profit than you, then your boss will question the choice of language. Development pace is set by the competition. Edit: and if there is no competition, the longer it takes, the longer it will take to be profitable.

Etheryte 3y ago
This is a common misnomer, writing more code faster doesn't mean you get more product or value faster. It can look like it at first, but you'll quickly come to find you're actually producing more bugs and vulnerable surface faster instead. More code is not good, it's the opposite of what you want.
RangerScience 3y ago
This. This is the argument I'm exhausted having. Rushing development works for... maybe a week. After that, every time, it takes longer overall than if it'd been done "right" the first time. Like a desk, you get one layer of crap and clutter. More than that and everything begins to teeter and fall. That said - you definitely have to ask yourself (as a developer) or your engineers (as management) "is there a simpler way?". But "simpler" is not the same as "rushed", even if both are "faster" - it's just a question of "on what timeline". Faster today? This week? This month? This quarter? This year?
- Towaway69 3y ago
  What's the old saying - nine pregnant people won't produce a child in one month. I think that comes from the Mythical Man Month but not sure. I think "faster" has been replaced by "profit". Is there a more profitable way of doing it. Etc. Hence things such as AI/CoPilot and the rest. We as developers have lost the craftsmanship that coding once was. Crafting a good bit of code that might just be a single line but which has elegance and conciseness to get the job done just right.