4 ms·

I believe it was Dr Robert Dewar of AdaCore fame who I first heard remark that ( paraphrased ) every time a bug gets missed at a stage of development ( compile-

by ajxs 8y ago

I believe it was Dr Robert Dewar of AdaCore fame who I first heard remark that ( paraphrased ) every time a bug gets missed at a stage of development ( compile-time to alpha, to beta, to production, etc ) the cost of it's resolution increases by an order of magnitude. I'm certainly by no means dismissing the value of concise languages for expressing ideas fluently, but brevity and expressiveness are only two factors influencing the value of a programming language in a specific domain. It's definitely an interesting paper, every time I see it I can't help but think that it's a little disingenuous to conduct an apples to oranges comparison of languages on these particular merits. It's much more difficult to weigh up the relative investment of time necessary to write code that is equally robust, maintainable and fit for purpose. Here's the video I got the Dr Dewar quote from: https://www.youtube.com/watch?v=0yXwnk8Cr0c https://www.youtube.com/watch?v=0yXwnk8Cr0c

flukus 8y ago
As far as costs go, 90% of it is in the "maintenance" phase from and usually be other developers, something this didn't address. Brevity certainly helps there but only up to a point, usually the most concise languages are the dynamic ones which can be much harder to maintain.
fulafel 8y ago
This sounds like the oft parroted but rarely fully sourced quote that turns out to be from some 60s IBM journal, with questionable applicability to the modern age. see eg https://news.ycombinator.com/item?id=15216407 https://news.ycombinator.com/item?id=15216407
- ajxs 8y ago
  I didn't really look at the quote as being a literal, canonical truth. I have my own doubts about it being _literally_ true, but I feel that the underlying idea that "the longer a bug persists through the development process the costlier it becomes to fix" is true.
- nickpsecurity 8y ago
  Most evidence I've seen supports it. This is especially true when people start integrating stuff with or building on top of a deliverable. Even more if that stuff was designed with the deliverables good and bad behavior in mind. It becomes a legacy system that sticks around. Knocking out its problems ahead of time can have considerable savings. Plus, a benefit not often mentioned is that knocking problems out at design time is easier since everything is fresh in developers' minds. They just wrote it. Now, it might not apply in an environment where everything is designed to be pluggable and easy to change without breaks. Maybe folks should run some new studies on such projects to see if there's any major benefits for up-front investments in quality. Enough to pay off that up-front investment like in the other projects.
- nickpsecurity 8y ago
  Reposting it on Lobsters, hwayne had a nice counterpoint to it: https://lobste.rs/s/6ywivn/are_delayed_issues_harder_resolve#c_1ocdkv https://lobste.rs/s/6ywivn/are_delayed_issues_harder_resolve... Anyone that studied what TSP was supposed to do would get what he was talking about. It might be supporting that TSP's up-front and lifecycle efforts make late changes in lifecycle easier rather than that non-TSP projects can easily make late changes.

by ajxs 8y ago

flukus 8y ago

As far as costs go, 90% of it is in the "maintenance" phase from and usually be other developers, something this didn't address. Brevity certainly helps there but only up to a point, usually the most concise languages are the dynamic ones which can be much harder to maintain.

fulafel 8y ago

This sounds like the oft parroted but rarely fully sourced quote that turns out to be from some 60s IBM journal, with questionable applicability to the modern age. see eg https://news.ycombinator.com/item?id=15216407 https://news.ycombinator.com/item?id=15216407

ajxs 8y ago
I didn't really look at the quote as being a literal, canonical truth. I have my own doubts about it being _literally_ true, but I feel that the underlying idea that "the longer a bug persists through the development process the costlier it becomes to fix" is true.
nickpsecurity 8y ago
Most evidence I've seen supports it. This is especially true when people start integrating stuff with or building on top of a deliverable. Even more if that stuff was designed with the deliverables good and bad behavior in mind. It becomes a legacy system that sticks around. Knocking out its problems ahead of time can have considerable savings. Plus, a benefit not often mentioned is that knocking problems out at design time is easier since everything is fresh in developers' minds. They just wrote it. Now, it might not apply in an environment where everything is designed to be pluggable and easy to change without breaks. Maybe folks should run some new studies on such projects to see if there's any major benefits for up-front investments in quality. Enough to pay off that up-front investment like in the other projects.
nickpsecurity 8y ago
Reposting it on Lobsters, hwayne had a nice counterpoint to it: https://lobste.rs/s/6ywivn/are_delayed_issues_harder_resolve#c_1ocdkv https://lobste.rs/s/6ywivn/are_delayed_issues_harder_resolve... Anyone that studied what TSP was supposed to do would get what he was talking about. It might be supporting that TSP's up-front and lifecycle efforts make late changes in lifecycle easier rather than that non-TSP projects can easily make late changes.