The cost in build time has to be weighed against the costs of debugging an error at later stages. How much does it cost to find logs, check out some code you haven’t read in a while, write a test to reproduce the error that you couldn’t make unrepresentable under a typing discipline, fix the error, get the fix reviewed and finally release it to production?
Of course, to do this calculation you need to know the probability of error, which cannot be estimated, but must be determined empirically. And you have to factor in programmer time to learn how to use your type system to make such errors unrepresentable, and mistakes in attempts to do so, which can impose a large time cost.
I wish we had better data to inform these decisions. How many errors could have been statically made impossible? How much time has been spent on fancily-typed wild goose chases? Perhaps we need a shared way of collecting this data other than just our accumulated individual anecdotes.
Ideally, since it’s of most interest to project leads and managers, they’d be the ones to collect it. I feel like the opportunity to track and share data like this ought to be an integrated feature of projects management tools.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
You would need to start 2 identical projects, counting time to debug and runtime programmer mistakes found in plain js, Vs total time to build, debug and programmer mistakes in something like typescript in the strictest style. The projects would need to be simple to multiply that by lines of code to get an average payoff of a forecasted project size X. Take it further by calculating employee wage over time. Unfortunately this experiment doesn't account for programmer skill and diligence.
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Studies have been done–it's been known for a long time that errors caught later in the development lifecycle are exponentially more expensive to fix. See embedded.typepad.com/bughunter/err...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The cost in build time has to be weighed against the costs of debugging an error at later stages. How much does it cost to find logs, check out some code you haven’t read in a while, write a test to reproduce the error that you couldn’t make unrepresentable under a typing discipline, fix the error, get the fix reviewed and finally release it to production?
Of course, to do this calculation you need to know the probability of error, which cannot be estimated, but must be determined empirically. And you have to factor in programmer time to learn how to use your type system to make such errors unrepresentable, and mistakes in attempts to do so, which can impose a large time cost.
I wish we had better data to inform these decisions. How many errors could have been statically made impossible? How much time has been spent on fancily-typed wild goose chases? Perhaps we need a shared way of collecting this data other than just our accumulated individual anecdotes.
Any ideas how we could collect such data?
Ideally, since it’s of most interest to project leads and managers, they’d be the ones to collect it. I feel like the opportunity to track and share data like this ought to be an integrated feature of projects management tools.
You would need to start 2 identical projects, counting time to debug and runtime programmer mistakes found in plain js, Vs total time to build, debug and programmer mistakes in something like typescript in the strictest style. The projects would need to be simple to multiply that by lines of code to get an average payoff of a forecasted project size X. Take it further by calculating employee wage over time. Unfortunately this experiment doesn't account for programmer skill and diligence.
Studies have been done–it's been known for a long time that errors caught later in the development lifecycle are exponentially more expensive to fix. See embedded.typepad.com/bughunter/err...